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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/__mailman/listinfo/gdal-dev
<http://lists.osgeo.org/mailman/listinfo/gdal-dev>
_______________________________________________
gdal-dev mailing list
[email protected]
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
