[gdal-dev] GDAL/OGR 1.11.0 Release Candidate 1 available for testing

Wolf Bergenheim wolf+grass at bergenheim.net
Thu Apr 17 08:03:50 PDT 2014


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. :)

--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.html<
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140417/bb1fd9a0/attachment.html>


More information about the gdal-dev mailing list