Who's maintaining log4r?

Does anyone know who’s maintaining the log4r project? The website at
Sourceforge says Leon T., 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

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 T. … any ideas where he
can be reached?

Jeff

On 12/27/06, [email protected] [email protected] wrote:

  • changed all existing tests (except 1) so they are self-verifying and
    unit tests
    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 T. … any ideas where he
can be reached?

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

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

On Wed, 2007-01-03 at 02:33 +0900, Tim P. wrote:

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

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

On 1/2/07, Tom C. [email protected] wrote:

Lacking that, should we have some
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.

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

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

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

Lacking that, should we have some
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 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.

On Wed, 2007-01-03 at 13:49 +0900, pat eyler wrote:

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

On Jan 3, 2007, at 12:48 AM, Devin M. 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

On Wed, 3 Jan 2007, Tom C. wrote:

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…

There are a few considerations here that seem to be the important ones.

  1. The licensing terms on the project’s code are going to influence what
    can be done, since open source doesn’t mean public domain. One can’t go
    and take away someone’s ownership of the project.

  2. A lot of those issues can probably be bypassed in most cases by
    simply
    adding someone to the project as a developer with commit privs, leaving
    the actual ownership of the project in place.

  3. If a decision is made to allow projects that appear to have been
    abandoned, with an owner that can’t be reached, to receive new
    committers
    without the consent of the project owner, I think it would be a very
    good
    idea to put the exact procedure for making that determination into
    writing
    on Rubyforge first. It should be linked to when one creates a new
    project, so people are aware of the policy, and every single owner of an
    existing project should be emailed to let them know about the policy
    well
    ahead the time of first implementation. That way project owners will
    have
    little justification for saying that they didn’t know that the policy
    was
    there.

Just my $.03.

Kirk H.

On Wed, 2007-01-03 at 13:50 +0900, Mat S. wrote:

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

That’s what I usually suggest too…

Yours,

Tom

On 1/3/07, [email protected] [email protected] wrote:

  1. The licensing terms on the project’s code are going to influence what
    can be done, since open source doesn’t mean public domain. One can’t go
    and take away someone’s ownership of the project.

true, unless there’s an policy in place when the project is set up on
RubyForge to allow it. This won’t help cardinal or log4r, but it might
help going forward.

  1. A lot of those issues can probably be bypassed in most cases by simply
    adding someone to the project as a developer with commit privs, leaving
    the actual ownership of the project in place.

commit privs are good. what about cutting new releases, making
announcements, etc. Those will need to be taken into consideration too.

agreed.

On 1/3/07, matt [email protected] wrote:

  1. A lot of those issues can probably be bypassed in most cases by simply
    adding someone to the project as a developer with commit privs, leaving
    the actual ownership of the project in place.

We still need to consider that this is someone elses intellectual
property,

What do you mean by intellectual property? That’s a pretty meaningless
term. If you mean the code. It’s under an open source license and
while
the original code still belongs to the writer(s), it can certainly be
used
as the starting point for ongoing development under the same license.
If you mean the project name, then the situation becomes more sticky
does the name belong to the community or the admin?

I should have put a disclaimer: I’m not a legal representative!

When I was referring to IP, I was really intending copyright (I think)
to the name of the project. This is where traditional lawyers won’t
touch software copyright/IP issues, because of the grey areas. I would
know, my corporate attorney sent me out of town to use an IP
specializing attorney. But I do believe that the original author may
still retain some rights, though to what extent I don’t know, and is the
reason that I recommended RubyForge consult with there attorney before
making any decisions.
Matt

  1. A lot of those issues can probably be bypassed in most cases by simply
    adding someone to the project as a developer with commit privs, leaving
    the actual ownership of the project in place.

We still need to consider that this is someone elses intellectual
property, so we might need to be careful about this, just in case the
original owner was to come back. If other people are committing, without
his approval, it might be a violation of his IP. I think that if it is
carefully documented, the process of trying to locate the owner, over a
period of time, that it shouldn’t be a problem, but there are some
definite legalities that RubyForge should have there attorney approve
first. The other question becomes, who maintains the documents of
proving an abandoned project? I think that for existing projects, we
might be SOL, but for future projects, I think that the the policy of
abandonment will need to be agreed to upon creation of a new project.

Just adding my pennies to the wishing well

Matt

On Jan 3, 2007, at 12:05 PM, matt wrote:

We still need to consider that this is someone elses intellectual
property, so we might need to be careful about this, just in case the
original owner was to come back. If other people are committing,
without
his approval, it might be a violation of his IP. I think that if it is
carefully documented, the process of trying to locate the owner,
over a
period of time, that it shouldn’t be a problem, but there are some
definite legalities that RubyForge should have there attorney approve
first.

To pose a more concrete question:

Has anyone from the rubyforge team been in on this discusson? We’d
need buy-in from them before any of this took place.
-Mat

On 1/3/07, Mat S. [email protected] wrote:

To pose a more concrete question:

Has anyone from the rubyforge team been in on this discusson? We’d
need buy-in from them before any of this took place.

Yes, Tom has been involved (and is probably watching). He’s conferring
with the Ruby Central folks who sponsor the work (and who I think are
also
watching the thread).

On 1/3/07, Mat S. [email protected] wrote:

definite legalities that RubyForge should have there attorney approve
first.

To pose a more concrete question:

Has anyone from the rubyforge team been in on this discusson? We’d
need buy-in from them before any of this took place.
-Mat

Tom C. has piped up, and he is going to bring this up with the
Ruby Central guys (they pay for RubyForge – hardware and bandwidth).

By the way, thanks Tom :slight_smile:

Blessings,
TwP