logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Moving forward with updates, builds and versions
Date Mon, 15 Aug 2011 13:18:04 GMT
On 2011-08-15, Dominik Psenner wrote:

> On 08/15/2011 11:39 AM, Stefan Bodewig wrote:
>> If we get back on track with regular releases the occasional trunk
>> breakage will be OK as people won't be forced to use arbitrary trunk
>> revisions.

> No, it is not OK at all. IMHO every recorded history should be a
> monolithic working library. Only if you do that you make sure that every
> release is just fine because if you don't, people will make errors and
> people will forget some thing or the other.

Here we'll have to agree that we disagree.  I will make errors, trunk
will occasionally be broken.  We have a mailing list that receives
notifications of all changes that went into svn and my fellow committers
review my changes.  We have a CI system (well, not really in the case of
log4net, this will be fixed sooner or later) that will call me off it I
break things in a way it can detect.  We do all we can to ensure trunk
works as well as possible but it is bleeding edge code.

Not that we'd guarentee our releases work any better.

The real solution is to have more releases to get bugfixes out quicker.

> "Ok, I'm done with it, for now I commit it and tomorrow I'll fix the
> special case".

This is rare, and if it happens I leave a comment in source code and
likely even a failing but skipped unit test.  YMMV.

> If patches don't get revised, it results exactly in the situation we
> have in log4net right now:

I never said patches wouldn't be revised, at least I hope I never said
so.  They must just get revised after I have committed them  The "commit
then review" model is working well among many projects.

Only very few ASF project follow the alternative "review then commit"
model - Tomcat and httpd do so for their "stable" branches.  For this we
do have tools like reviewboad at the ASF but I've never used it.

> 101 revisions since the last release and nobody knows whether those
> "fixes" do really fix the issues or those revisions are safe to include
> in the next release because there are no unit tests. I don't think
> that's funny.

No it isn't, fortunately it isn't all that bad as many changes comes
with unit tests or are directly connected to JIRA tickets and most
changes are pretty small - this is from my cursory look, you may have
looked closer than myeself.

If anything it points out that we may want to diff currennt trunk
against the latest released code just to be sure we actually know what
type of changes we are pushing out.

The reason that "nobody knows" is neither svn nor JIRA nor the way you
or I or anybody else who is willing to help the project now wants to
work, though.


View raw message