Hi Martin, > From my perspective one reason for the high amount of regression is the > high amount of integrated child workspaces short before a feature > freeze. In the moment the ITeam (the QA representative) does the > nomination before feature freeze. As an immediate action (for the > upcoming 3.2 release) from my side I will limit this freedom until 4 > weeks before feature freeze, in the last 4 weeks before feature freeze,
In my opinion, it's strictly necessary then to have parallel development branches earlier than we have today. That is, if there are a lot of CWSes coming in, but not approved/nominated for the next release, then we should *not* pile them, but instead have a different branch to integrate them into. Else, the quality problems will be shifted to post-release only. An yes, extending the various phases we have - feature implementation, bug fixing, release canditates -, as suggested by Ingrid, would help, too. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
