...1) We suck at freezing and stabilizing the codebase prior to releases.
Yes.
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.
Sounds good - and during this two-day period everybody should be frantically testing stuff (and docs) to make sure we put out decent releases. Not pointing any fingers here but there should be systematic (if not automatic) testing before releases.
Did I say I will do it? Yes, unless this two-day period comes at at time where X projects are competing for my overstuffed agenda (like right now ;-)
...2) We need to break from the impasse of 2.1.1 vs 2.2...
...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...
Yes - I didn't follow previous discussions about CVS modules vs. branches, but there must be an agreement soon on this.
As 2.2 seems to change a lot of internal things and thus might need some time before a release, it *must*be possible to fix things in 2.1.x and make interim releases easily before 2.2 is released.
I'd do it with branches but again if there were good reasons to go for separate repositories, why not.
...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.
Sounds good, but I won't be able to help with the docs - overstuffed agenda out here.
-Bertrand
