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.
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?
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.
Try googling for 'leon torres minimetria'; there are recent posts on
some apache ML with different Email address.
I also have few syslog outputter fixes for log4r that I applied locally.
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
···
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?
My changes are proceeding apace, though I've not forked a new project
yet. I'll try finding Leon's email using the method above. Also,
another developer has also sent me some code he's worked on which I'll
be reviewing, and I'll be sending him mine when I get the tests passing
again (yet another massive change put in place) ... so there are
interested devs out there!
I'd be interested to hear what people feel are preconditions for a new
log4r. My guesses are:
1. Backwards API compatability for Log4r configs done via XML or YAML,
though some of the semantics may differ (e.g., the RootLogger may log
as well)
2. Same speed as original, or better.
3. Anything that worked before (including ROMP, email outputters, etc)
should still work - though not necessarily in the alpha release
As I mentioned way back in post #2, my current implementation will
likely break any direct calls to Logger.new( ... ) in client code. My
reason for this is, as suggested in Eric Evans's Domain Driven Design,
clients should probably not directly call constructors ... this ties
clients too closely to implementation, and in the case of Log4r makes
some of the design difficult (tight coupling, global state, singletons,
etc, all the stuff that's really hard to unit test). Like Log4J, my
implementation does support Logger.getLogger( 'name' ), though it's
written using the index operator Logger[ 'name' ].
But, this is just my stuff, and I'll be sharing this and *hopefully*
combining it with the work of the other developer -- unless his is way
better!
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
···
On Wed, 2007-01-03 at 02:33 +0900, Tim Pease wrote:
Ok, let's see... I actually thought no one would be using log4r, so I
sort of let it slide into being unmaintained. The whole project was
kind of an exercise to see if I could create a Log4j type thing in ruby,
but doing it the Ruby Way (TM). It turned out to be quite useful for
the small projects I did, so I released it.
That it's still being used is a complete surprise to me and even more
surprising was finding it in the debian package system!
I'm currently bogged down as a major contributor to another open source
project (Apache Open For Business), so I can't find the time to devote
to this. I also wrote Log4r while unemployed, and it constitutes quite
a number of man hours... whew what memories.
At this point, it would probably be wise for me to pass the baton on to
another competent developer who can give log4r some time and a little
love. I'll certainly help with explaining and transition.
So first, who's interested in maintaining it?
You can reach me at leon at oss dot minimetria dot com, I'll be
following this thread too.
> 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.
···
On 1/2/07, Tom Copeland <tom@infoether.com> wrote:
On Wed, 2007-01-03 at 02:33 +0900, Tim Pease wrote:
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
···
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.
I definitely don't want to get into the middle of this, but I know
that someone has recently announced a new project (logging) meant to
replace log4r since it was (to all appearances) unmaintained. See:
You and this guy might want to coordinate on this.
···
On 1/18/07, Leon Torres <leon@oss.minimetria.com> wrote:
At this point, it would probably be wise for me to pass the baton on to
another competent developer who can give log4r some time and a little
love. I'll certainly help with explaining and transition.
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.
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.
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 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.
Also, I'm all for changing Log4r as radically or conservative as
necessary. It was pretty much developed solo, without any kind of
serious world use testing or substantial feedback.
I agree that there are certain things about it that are a bit brittle
and broken, so I propose that the next point release be a complete
refactoring based on people's use experiences. It would also be
interesting to get more of the Ruby Way into it, especially where it
would make log4r a more pragmatic tool.
We can also spin off this thread into a separate forum or mailing list.
Is there a ruby place to set one up?
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 Haines
···
On Wed, 3 Jan 2007, Tom Copeland 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...
After discussing this with David and Rich, our policy is that if you
want to pick up an apparently abandoned project, fork it. The
alternatives are just too messy. But we're happy to host those forks!
Go for it.
Yours,
Tom
···
On Wed, 2007-01-03 at 09:11 -0500, Tom Copeland 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...
Also, I'm all for changing Log4r as radically or conservative as
necessary. It was pretty much developed solo, without any kind of
serious world use testing or substantial feedback.
Leon,
Thanks for getting back to everyone on this. Log4r has certainly
gotten a lot of usage. It is included in the OneClick Installer for
Windows (and IANM, InstantRails as well.) It can be used by the
MasterView project, and probably many others.
Would you be adverse to giving another developer commit rights, if you
lack the time? Jeffz_2002 who started this project seems to have some
changes to add.
Ed
···
On 1/18/07, Leon Torres <leon@oss.minimetria.com> wrote:
I agree that there are certain things about it that are a bit brittle
and broken, so I propose that the next point release be a complete
refactoring based on people's use experiences. It would also be
interesting to get more of the Ruby Way into it, especially where it
would make log4r a more pragmatic tool.
We can also spin off this thread into a separate forum or mailing list.
Is there a ruby place to set one up?