[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