On Tue, Oct 21, 2008 at 5:52 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
Sounds like a good idea, but I do have a couple of concerns.
1. It would be another branch to manage. Things to indeed get messed
with all the branches we have to manage, this increases the risk of that.
The fact that we accept only critical bug fixes in RC should
minimize this.
Well its often the "little fixes" that get missed so i am not sure I
agree. But... not much we can do about it.
In the "release early release often" way of thinking little fixes
shoudl not delay a release, a new release can include them as soon as
we think it is needed. Of course, IMHO!
2. Unless we stay disciplined I think it promotes trunk like development
on a stable branch. I think we already push the envelope on what could
be considered stable development. I don't want people to start thinking
that stable branches are a playground for experimentation.
There is wild experimentation and there is stuff like my WFSV bug fixes
waiting for 1.7.x to be free, or David's KML improvements, or new
modules that do not touch the core or the main services.
We always allowed limited development on the stable branch, and moved
everything that's any heavier to trunk. As far as I'm concerned that
approach has served us well so far.
Right, i am just trying to remind that this policy does not mean people
can do whatever they want as long as its not on an RC branch.
I think that PSC and PMC should do their work, here is anyone goes
beyond the rules we shoudl stop him. However, we can't stop peopole
from working before of a release, instead we might want to try and
release more often (no too often though) :-).
3. Coordination with gt2 releases. If we adopt the same scheme for
geotools then i assume we create a "RC branch" for geotools the same
time we create one for geoserver? This would be fine if we were the only
project driving or using geotools. And how do we deal with people that
want to get a fix into a geotools point release, but that fix does not
directly fix a GeoServer bug?
We can start creating GS only releases.
Hmmm... not that I am against it but GS only released means we abondoned
the geoserver major point release against a geotools major point release.
If you think about it, 2.5.x
I am not "strategically" convinced by GS only releases, even though I
see the benefits of this on the workload perspective. I think we
should elaborate a bit more on this.
is atctually a GS only branch, as 2.4.x and 2.3.x have been as well,
so we're actually already doing that.
Not sure I agree. When we released 2.5.0 there were people that wanted
to see certain features that were not specific to GeoServer. Just going
ahead with the release would have left them out in the cold.
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://www.geo-solutions.it/simone.giannecchini
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------