Hi folks,
forgive me for putting on my BOFH hat, while making the following observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a release date after discussion on the dev list, and that there's a two-day (!) freeze period where only glaring bugs can be fixed after a vote (!) on the list.
The Release Manager him/herself is also only allowed to commit obvious version number changes and all that during this two-day "Sperr-zone".
During the past few releases, there was a flurry of quick fixes and commits happening just hours before Carsten made the tarball, and while I'm not immediately aware of any nasty side-effects caused by this, it sure doesn't look like there was time for any peer review on these late commits, neither did it look organized at all.
+1 Yes, we should handle the release process more restrictive.
2) We need to break from the impasse of 2.1.1 vs 2.2
I suggested yesterday night that the reshuffling of docs that Carsten started really seems more apt for a 2.2 release. Also, the switch to Fortress and Real Blocks are destined towards that 2.2 release. I understand some Avalon peeps are glad to dive in and help us with that, which is great, but we should facilitate them.
Some people want to start with a 2.2 CVS module right away, others seem more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to decide on this, since it's blocking progress.
My personal opinion is that 2.2 might warrant its own module, but we need to discuss its structure and coexistence with old-style blocks code in more depth before we ask for its creation to the infrastructure peeps.
But we should priorize all maintenance tasks first. For example the patches in Bugzilla: it will be more and more effort to patch Cocoon's code. What happens? The older Cocooon versions are as nearly as dead. See 2.0 - who cares about it? The same will happen with 2.1 if we open a 2.2 CVS module. c'est la vie? Evolution?
3) Given the breakage in the Rhino stuff, and the lack of serious testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not retracting it, though) and go for a new target release date for 2.1.2 on September 24th. That way, we can discuss at leisure what we are going to do with the docs-reshuffling, and people can spend more time on testing new stuff.
I guess the 2.1 had more and harder errors (e.g. the impossible undeployment in Tomcat), so I think it's no problem to announce this as improvement including the notice, that there is now another problem. It's ok IMO, if the 2.1.2 follows in a little while.
Joerg
-- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
