<snip> > > Indeed you're right, not an easy position, I've been there before > keeping a freeze two weeks long with people complaining at me > (I had my reasons, they had theirs, and we were both right, so > it was indeed a lose/lose situation). > > The only escape route I know of if you plan to keep a freeze lasting > longer than a week is to branch off... which as its own issues as you > know, one more place to port changes to :( > > A solution? Maybe... talk. Ask people to start a freeze, if the > freeze takes more than expected or people are getting uncomfortable > with it, just branch off to insulate the freeze from other people > work. Hopefully most of the time the freeze won't affect people enough > to require a real branch, and when it does, well, you know that > you have at least tried. Well I think once the road map is in place it should help since this situation should not really occur. For one release dates are set to people know when a release is coming. It would probably be good to also add to the process something like no non-bug fix commits at least a week before release date.
But it also will prevent any commits that the community has decided should not get into the release. But yeah, until this is in place we will just have to continue to ask for a freeze and deal with situation in which people need to commit. > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
