[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Who's maintaining log4r?

jeffz_2002

12/20/2006 10:01:00 PM

Does anyone know who's maintaining the log4r project? The website at
Sourceforge says Leon Torres, but his email's bouncing.

The reason I ask: I have recently begun looking into log4r and would
like to suggest some minor fixes to the installation instructions (for
noobs like me) and to the code base itself. Also, the unit tests for
the project (as it stands when installed as a gem) raise a whack of
errors and warnings. I'm not sure how to contribute.

Jeff
35 Answers

jeffz_2002

12/28/2006 1:38:00 AM

0

Hello again folks (if anyone read the last post - busy time of year),

I've completed some work on Log4r, and would like to share it soon with
the Ruby community, after I've done the rest. I don't have access to
the Log4r code repository ... any hints on getting in contact with
project owner(s) would be great.

Accomplished in initial round of Log4r refactoring:

- converting the tests over to Test::Unit
- changed all existing tests (except 1) so they are self-verifying and
can be run at any point as a complete test suite (previous tests had to
be verified visually)
- added new tests to the suite to help guide my refactoring, which
clarify the intent of the code
- various refactorings large and small

Remaining to do's:

- continue refactoring
- reduce coupling/global state of program to simplify code, clarify
unit tests
- introduce some Log4J-type behaviour which I miss (I know that Log4R
didn't slavishly follow Log4J, but J does have some nice features)

I'm doing this for my own benefit and for my work, but would like to
share with the community. I believe that my work is useful -- even if
only for me.

Warning: I think I might have to change the Logger.initialize() method,
which means that existing code that creates loggers like Logger.new(
'a', WARN, etc) would break ... but code using XML or YAML
configuration would still work. If this is hugely problematic, I'd be
open to discussion.

Lastly, I still can't get a hold of Leon Torres ... any ideas where he
can be reached?

Jeff

Tim Pease

1/2/2007 5:33:00 PM

0

On 12/27/06, jeffz_2002@yahoo.com <jeffz_2002@yahoo.com> wrote:
> Hello again folks (if anyone read the last post - busy time of year),
>
> I've completed some work on Log4r, and would like to share it soon with
> the Ruby community, after I've done the rest. I don't have access to
> the Log4r code repository ... any hints on getting in contact with
> project owner(s) would be great.
>
> Accomplished in initial round of Log4r refactoring:
>
> - converting the tests over to Test::Unit
> - changed all existing tests (except 1) so they are self-verifying and
> can be run at any point as a complete test suite (previous tests had to
> be verified visually)
> - added new tests to the suite to help guide my refactoring, which
> clarify the intent of the code
> - various refactorings large and small
>
> Remaining to do's:
>
> - continue refactoring
> - reduce coupling/global state of program to simplify code, clarify
> unit tests
> - introduce some Log4J-type behaviour which I miss (I know that Log4R
> didn't slavishly follow Log4J, but J does have some nice features)
>
> I'm doing this for my own benefit and for my work, but would like to
> share with the community. I believe that my work is useful -- even if
> only for me.
>
> Warning: I think I might have to change the Logger.initialize() method,
> which means that existing code that creates loggers like Logger.new(
> 'a', WARN, etc) would break ... but code using XML or YAML
> configuration would still work. If this is hugely problematic, I'd be
> open to discussion.
>
> Lastly, I still can't get a hold of Leon Torres ... any ideas where he
> can be reached?
>

I, too, have tried contacting Leon but with no luck :(

This does raise the issue of what to do with abandoned projects on
RubyForge -- especially ones like Log4r that are widely used. The
best situation would be one where the author could be contacted and
project ownership transferred. Lacking that, should we have some
probate process where an abandoned project can be transferred after
the current own fails to respond for some period of time?

Any thoughts out there on this one? RubyForge Team?

Blessings,
TwP

Tom Copeland

1/3/2007 4:34:00 AM

0

On Wed, 2007-01-03 at 02:33 +0900, Tim Pease wrote:
> I, too, have tried contacting Leon but with no luck :(
>
> This does raise the issue of what to do with abandoned projects on
> RubyForge -- especially ones like Log4r that are widely used. The
> best situation would be one where the author could be contacted and
> project ownership transferred.

Right on.

> Lacking that, should we have some
> probate process where an abandoned project can be transferred after
> the current own fails to respond for some period of time?
>
> Any thoughts out there on this one? RubyForge Team?

I'd say if you can't contact the maintainer, then after a reasonable
amount of time just fork it. We'd certainly approve a log4r2, or
something like that.

But I really, really don't like to pull a project out from under an
admin, even if the project is popular and that admin seems to have
disappeared.

Yours,

Tom

pat eyler

1/3/2007 4:49:00 AM

0

On 1/2/07, Tom Copeland <tom@infoether.com> wrote:
> On Wed, 2007-01-03 at 02:33 +0900, Tim Pease wrote:
> > I, too, have tried contacting Leon but with no luck :(
> >
> > This does raise the issue of what to do with abandoned projects on
> > RubyForge -- especially ones like Log4r that are widely used. The
> > best situation would be one where the author could be contacted and
> > project ownership transferred.
>
> Right on.
>
> > Lacking that, should we have some
> > probate process where an abandoned project can be transferred after
> > the current own fails to respond for some period of time?
> >
> > Any thoughts out there on this one? RubyForge Team?
>
> I'd say if you can't contact the maintainer, then after a reasonable
> amount of time just fork it. We'd certainly approve a log4r2, or
> something like that.
>
> But I really, really don't like to pull a project out from under an
> admin, even if the project is popular and that admin seems to have
> disappeared.

Respectfully, I disagree. I think there should be a policy describing
how a project can be changed given an unresponsive admin. Forks
should be caused by a difference in opinion about how the project
is running or the direction it's going.

If a popular project stalls for a long period of time and the maintainer
is no longer available, forking it just leads to confusion for everyone
involved. How many people will continue to point at log4r even though
it's not progressing, just because it looks more official than log4r2.

>
> Yours,
>
> Tom
>
>
>
>


--
thanks,
-pate
-------------------------
http://on-ruby.bl...

Mat Schaffer

1/3/2007 4:51:00 AM

0


On Jan 2, 2007, at 11:34 PM, Tom Copeland wrote:

> On Wed, 2007-01-03 at 02:33 +0900, Tim Pease wrote:
>> I, too, have tried contacting Leon but with no luck :(
>>
>> This does raise the issue of what to do with abandoned projects on
>> RubyForge -- especially ones like Log4r that are widely used. The
>> best situation would be one where the author could be contacted and
>> project ownership transferred.
>
> Right on.
>
>> Lacking that, should we have some
>> probate process where an abandoned project can be transferred after
>> the current own fails to respond for some period of time?
>>
>> Any thoughts out there on this one? RubyForge Team?
>
> I'd say if you can't contact the maintainer, then after a reasonable
> amount of time just fork it. We'd certainly approve a log4r2, or
> something like that.
>
> But I really, really don't like to pull a project out from under an
> admin, even if the project is popular and that admin seems to have
> disappeared.

It's definitely a shame to pull a project completely out from under
someone, but I think it'd be reasonable just to forcibly add another
user to the list of commiters. Unless of course the license stated
anything against it. The original copyrights would have to be
maintained and the original admin would still have access and write
permissions and could step in if they saw fit.

I'd worry about something like log4r2. PHP has a lot of that '2'
mess and it leads to big headaches when upgrading. Like the recent
change from DB to MDB2, or PHPUnit2 (class prefix: PHPUnit2) to
PHPUnit3 (class prefix: PHPUnit, which now conflicts with the defunct
original phpunit).

If anything just come up with a different name and drop the number.
Lest we end up with a versioning nightmare of J2SE proportions.

-Mat

matt

1/3/2007 5:00:00 AM

0

I agree with Pat, it could be confusing for users that didn't know there
was a fork

How do some of the other open source project farms handle it, like
Sourceforge and the like? Maybe one of them has encountered this and
found a reasonable solution that we can use. Maybe when an account is
created, part of the terms would be to agree to let someone take over
the project if the project is abandoned and the maintainer can't be
contacted. ??

Just a thought.

Matt








>
> Respectfully, I disagree. I think there should be a policy describing
> how a project can be changed given an unresponsive admin. Forks
> should be caused by a difference in opinion about how the project
> is running or the direction it's going.
>
> If a popular project stalls for a long period of time and the maintainer
> is no longer available, forking it just leads to confusion for everyone
> involved. How many people will continue to point at log4r even though
> it's not progressing, just because it looks more official than log4r2.
>
> >
> > Yours,
> >
> > Tom
> >
> >
> >
> >
>
>


jeffz_2002

1/3/2007 5:43:00 AM

0

> It's definitely a shame to pull a project completely out from under
> someone, but I think it'd be reasonable just to forcibly add another
> user to the list of committers.

(Assuming that I'll be allowed to put my code forward as a candidate
for review and possible adoption) - the difficulties I see are:

- there have been substantial revisions to the code base (the revisions
are in SVN), so merging may be difficult. That said, I'd vote for
keeping it as "Log4r", not a new name, since the code is clearly based
on the original Log4r.

- the changes may not be fully backward compatible (though I intend to
keep the XML and YAML configurations working as-is, so people who use
log4r with file configurations won't be interrupted). Perhaps others
with greater expertise would be able to find some happy mediums for the
code that would ensure previous users are not affected

Anyway, I'm happy to put my code out there for public review/ridicule.

Jeff

Devin Mullins

1/3/2007 5:49:00 AM

0

matt wrote:
> How do some of the other open source project farms handle it, like
> Sourceforge and the like?
SourceForge doesn't handle it. 99% of SourceForge projects are abandoned
/ codeless shells.* Boo, namespace pollution.

Devin
* This stat courtesy mon derrière.

Mat Schaffer

1/3/2007 12:10:00 PM

0


On Jan 3, 2007, at 12:48 AM, Devin Mullins wrote:

> matt wrote:
>> How do some of the other open source project farms handle it, like
>> Sourceforge and the like?
> SourceForge doesn't handle it. 99% of SourceForge projects are
> abandoned / codeless shells.* Boo, namespace pollution.
>
> Devin
> * This stat courtesy mon derrière.

I thought for sure there was some sort of petition process, but maybe
not. Even if they had it, there'd probably be still a lot of shells
because people aren't often interested in taking other people's
projects.

I'll look around sf.net at work today and post anything interesting I
find.
-Mat

Tom Copeland

1/3/2007 2:12:00 PM

0

On Wed, 2007-01-03 at 13:49 +0900, pat eyler wrote:
> > But I really, really don't like to pull a project out from under an
> > admin, even if the project is popular and that admin seems to have
> > disappeared.
>
> Respectfully, I disagree. I think there should be a policy describing
> how a project can be changed given an unresponsive admin. Forks
> should be caused by a difference in opinion about how the project
> is running or the direction it's going.
>
> If a popular project stalls for a long period of time and the maintainer
> is no longer available, forking it just leads to confusion for everyone
> involved. How many people will continue to point at log4r even though
> it's not progressing, just because it looks more official than log4r2.

Hm. I hear ya. Maybe I've got the wrong end of the stick on this one.
I'll chat with the RubyCentral guys (Rich/David/Chad) and see what they
think. RubyForge is owned by RubyCentral (they pay for hardware and
bandwidth) so they've got the final say on any policy decision like
this...

Thanks for the comments,

Yours,

Tom