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. Stefan
