<div dir="ltr">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.<div><br></div><div>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!</div>

<div><br></div><div>--Wolf</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 3:56 PM, Daniel Morissette <span dir="ltr"><<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 14-04-17 9:01 AM, Even Rouault wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The problem is that at some point we must take a snapshot and say "hey, this is<br>
GDAL 1.11, the latest and greatest, use it please". I think it is OK if new<br>
drivers are still a bit experimental.<br>
<br>
Reviewing the commit, I think that it has at least one issue because<br>
SetSpatialFilter() will segfault in switch( poGeomIn->getGeometryType() ) if<br>
passed a NULL geometry, which is perfectly legal, in order to uninstall a<br>
spatial filter.<br>
Did you test the driver with the test_ogrsf utility ? (cd apps; make test_ogrsf)<br>
<br>
</blockquote>
<br></div>
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):<br>
<br>
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.<br>



<br>
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)<br>



<br>
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.<br>



<br>
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.<br>
<br>
For reference, MapServer RFC34 documents the release process:<br>
<a href="http://msgsoc.mapgears.com/html/en/development/rfc/ms-rfc-34.html" target="_blank">http://msgsoc.mapgears.com/<u></u>html/en/development/rfc/ms-<u></u>rfc-34.html</a><span><font color="#888888"><br>

<br>
Daniel<br>
-- <br>
Daniel Morissette<br>
T: <a href="tel:%2B1%20418-696-5056%20%23201" value="+14186965056" target="_blank">+1 418-696-5056 #201</a><br>
<a href="http://www.mapgears.com/" target="_blank">http://www.mapgears.com/</a><br>
Provider of Professional MapServer Support since 2000</font></span><div><div><br>
______________________________<u></u>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br></div></div>