[gdal-dev] Formalizing realease procedure [was Re: GDAL/OGR 1.11.0 Release Candidate 1 available for testing]
Even Rouault
even.rouault at mines-paris.org
Thu Apr 17 14:08:44 PDT 2014
Le jeudi 17 avril 2014 17:03:50, Wolf Bergenheim a écrit :
> Hi Daniel,
>
> I agree with your idea about formalizing, and do indeed feel sorry for
> adding to Even's workload. I think it's a good thing to talk about,
> especially now, for obvious reasons. Making new GDAL releases should be
> made as easy as possible, and I think that a more formal structure, like
> the one you mentioned, could be the first step towards this. So I'm all for
> it, and would welcome discussion around this subject. :)
Yes, I agree that our release procedure per-se is not completely formalized.
I've looked a bit to our documentation, and found a few mentions to things
releated to releasing :
1) The http://svn.osgeo.org/gdal/trunk/gdal/HOWTO-RELEASE : this covers mostly
the technical points to do the release.
2) Extract from http://trac.osgeo.org/gdal/wiki/rfc1_pmc :
"""
When vote is required ?
[...] When releases should take place
"""
3) Extracts from http://trac.osgeo.org/gdal/wiki/rfc3_commiters :
"""
* Never commit new features to a stable branch without permission of the PSC
or release manager. Normally only fixes should go into stable branches.
* Only bug fixes should be committed to the code during pre-release code
freeze, without permission from the PSC or release manager.
* Do not create new branches without the approval of the PSC. Release managers
are assumed to have permission to create a branch.
"""
Thanks to Daniel for pointing to http://mapserver.org/development/rfc/ms-
rfc-34.html which could serve as a base to establish a similar RFC for GDAL.
I've a few observations on MS RFC 34 and would be interested in hearing
Daniel's feedback about how much of it is followed in practice. Rules are
good, but few rules that are really followed are better than a lot of rules
that aren't really followed.
* The release manager in MapServer has really important rights and many
duties..., and if I understand well ( "Approving or not the release of each
beta, release candidate and final release"), he can promote himself a release
to official without requiring a PSC vote ? I like the fact that GDAL releases
are approved by the whole PSC, to stress that it is a collective
responsibility.
* "regular IRC meetings" ?
* "QA/Testers team" : is there such an identified team in MapServer ?
* MapServer 6 month release cycle vs GDAL 1 year in practice : people are
usually slow on adopting new releases (and people that want to track the
latest and greatest can always use/produce daily builds). Are the benefits of a
6 month cycle worth the release procedure overhead ? Also I'm thinking about
the hypothetical 2.0 release where we might want to push quite a few breaking
changes together, and it might be difficult to guarantee even a 1 year cycle...
* The emphasis on RFCs ( "RFC freeze date" etc) in MapServer doesn't
completely translate to GDAL. Driver development in GDAL doesn't imply RFC.
RFCs are mostly justified by additions or changes in core GDAL/OGR. But we
could replace occurences "RFC" by "RFC and new drivers" and that should do
* "3-4 betas and a couple of release candidates over a 6 weeks period" : do
people actually test more betas than daily builds ? Don't they only test
releases when they are promoted official, or when they reach .1 / .2 micro
numbers ?
* I don't think it is necessary to have the same release manager for bugfixes
releases than for major releases.
* Version numbering. The current GDAL numbering scheme seems OK to me. Major
number (1 for the last 15 years ;-)) is increased when the C API changes.
Minor when they are functional or API additions. Micro for bugfixes.
Even
>
> --Wolf
>
> On Thu, Apr 17, 2014 at 4:52 PM, Daniel Morissette
> <dmorissette at mapgears.com
>
> > wrote:
> >
> > Hi Wolf,
> >
> > Once again my mail was aimed at all of us committers and not just you
> > specifically. Your contributions (like everyone else's) are much welcome
> > and I would not want to discourage anyone from contributing. FWIW I don't
> > think there was ever a formal code freeze call for GDAL, so you did not
> > miss it. There was just an email thread started by Even about trying to
> > produce a 1.11 release (which implies a feature freeze in my mind, but
> > that's just me and that was not explicit).
> >
> > My intention was mostly to make everyone realize how hard it can be for
> > Even or someone else to produce releases when commits keep coming in for
> > non trivial fixes. I have been through that with MapServer several years
> > ago and then we introduced the release process (RFC034) which helped a
> > lot, so I am just relaying that experience in the hope that we can make
> > GDAL releases easier in the future.
> >
> > Daniel
> >
> > On 14-04-17 10:28 AM, Wolf Bergenheim wrote:
> >> Yeah, I should not have tried to push this so late yesterday. For that
> >> I'm sorry, and I'm fixing it now. I can only apologize.
> >>
> >> Daniel, you bring up a good point. A more formal release process might
> >> be in order, we are maybe starting to reach critical mass in developers
> >> here, or else it's just me messing around and not following process that
> >> I should know. I think I missed the call to codefreeze, again, my bad.
> >> But it won't happen again. Code reviews would be another way to prevent
> >> accidental segfaults, but we might not have enough people with enough
> >> time for that, and some people might not want it. I personally love when
> >> someone reviews my code. So thanks Even for that!
> >>
> >> --Wolf
> >>
> >>
> >> On Thu, Apr 17, 2014 at 3:56 PM, Daniel Morissette
> >>
> >> <dmorissette at mapgears.com <mailto:dmorissette at mapgears.com>> wrote:
> >> On 14-04-17 9:01 AM, Even Rouault wrote:
> >> The problem is that at some point we must take a snapshot and
> >> say "hey, this is
> >> GDAL 1.11, the latest and greatest, use it please". I think it
> >> is OK if new
> >> drivers are still a bit experimental.
> >>
> >> Reviewing the commit, I think that it has at least one issue
> >>
> >> because
> >>
> >> SetSpatialFilter() will segfault in switch(
> >> poGeomIn->getGeometryType() ) if
> >> passed a NULL geometry, which is perfectly legal, in order to
> >> uninstall a
> >> spatial filter.
> >> Did you test the driver with the test_ogrsf utility ? (cd apps;
> >> make test_ogrsf)
> >>
> >> Note to all committers in support of Even attempting to produce a
> >> release (not pointing at Wolf specifically even if that's the way
> >> this may sound):
> >>
> >> This example (introducing a potential seg fault at the last minute)
> >> is exactly the reason why we usually have a "feature freeze" period
> >> before releasing software and only really critical *fixes* should be
> >> allowed during the feature freeze period, and these fixes should
> >> have been properly tested.
> >>
> >> This is also the reason why in projects such as MapServer the
> >> appointed release manager for a given release has unilateral power
> >> to revert any changes that he/she considers has a risk to the
> >> stability of the release or its schedule, even if that means
> >> releasing with documented known bugs. (i.e. sometimes it is safer to
> >> release with a known bug than to introduce a non trivial fix that
> >> comes with a higher risk to the stability of the software and could
> >> delay the release)
> >>
> >> The alternative if we don't do that is that releases take forever
> >> because there will always be someone who has a last minute fix to
> >> commit (with the associated risk of introducing new bugs at the same
> >> time if they are not well tested straightforward fixes). Then we get
> >> into a spiraling effect of fixes introducing bugs, whose fixes
> >> introduce bugs, and so on, hopefully you get the idea.
> >>
> >> Sorry for the rant, we've gone through that exercise for MapServer
> >> several years ago and that has helped a lot, so I'd be in favor of
> >> more rigid release rules for GDAL as well.
> >>
> >> For reference, MapServer RFC34 documents the release process:
> >> http://msgsoc.mapgears.com/__html/en/development/rfc/ms-__rfc-34.htm
> >> l<
> >>
> >> http://msgsoc.mapgears.com/html/en/development/rfc/ms-rfc-34.html>
> >>
> >> Daniel
> >> --
> >> Daniel Morissette
> >> T: +1 418-696-5056 #201 <tel:%2B1%20418-696-5056%20%23201>
> >>
> >> http://www.mapgears.com/
> >> Provider of Professional MapServer Support since 2000
> >>
> >> _________________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> >> http://lists.osgeo.org/__mailman/listinfo/gdal-dev
> >> <http://lists.osgeo.org/mailman/listinfo/gdal-dev>
> >>
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > --
> > Daniel Morissette
> > T: +1 418-696-5056 #201
> > http://www.mapgears.com/
> > Provider of Professional MapServer Support since 2000
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Geospatial professional services
http://even.rouault.free.fr/services.html
More information about the gdal-dev
mailing list