<div dir="ltr">Hi Daniel,<div><br></div><div><div class="gmail_extra">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. :)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">--Wolf<br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 4:52 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">Hi Wolf,<br>
<br>
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).<br>
<br>
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.<br>
<br>
Daniel<div><br>
<br>
<br>
<br>
On 14-04-17 10:28 AM, Wolf Bergenheim wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Yeah, I should not have tried to push this so late yesterday. For that<br>
I'm sorry, and I'm fixing it now. I can only apologize.<br>
<br>
Daniel, you bring up a good point. A more formal release process might<br>
be in order, we are maybe starting to reach critical mass in developers<br>
here, or else it's just me messing around and not following process that<br>
I should know. I think I missed the call to codefreeze, again, my bad.<br>
But it won't happen again. Code reviews would be another way to prevent<br>
accidental segfaults, but we might not have enough people with enough<br>
time for that, and some people might not want it. I personally love when<br>
someone reviews my code. So thanks Even for that!<br>
<br>
--Wolf<br>
<br>
<br>
On Thu, Apr 17, 2014 at 3:56 PM, Daniel Morissette<br></div><div><div>
<<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a> <mailto:<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.<u></u>com</a>>> wrote:<br>
<br>
On 14-04-17 9:01 AM, Even Rouault wrote:<br>
<br>
<br>
The problem is that at some point we must take a snapshot and<br>
say "hey, this is<br>
GDAL 1.11, the latest and greatest, use it please". I think it<br>
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(<br>
poGeomIn->getGeometryType() ) if<br>
passed a NULL geometry, which is perfectly legal, in order to<br>
uninstall a<br>
spatial filter.<br>
Did you test the driver with the test_ogrsf utility ? (cd apps;<br>
make test_ogrsf)<br>
<br>
<br>
Note to all committers in support of Even attempting to produce a<br>
release (not pointing at Wolf specifically even if that's the way<br>
this may sound):<br>
<br>
This example (introducing a potential seg fault at the last minute)<br>
is exactly the reason why we usually have a "feature freeze" period<br>
before releasing software and only really critical *fixes* should be<br>
allowed during the feature freeze period, and these fixes should<br>
have been properly tested.<br>
<br>
This is also the reason why in projects such as MapServer the<br>
appointed release manager for a given release has unilateral power<br>
to revert any changes that he/she considers has a risk to the<br>
stability of the release or its schedule, even if that means<br>
releasing with documented known bugs. (i.e. sometimes it is safer to<br>
release with a known bug than to introduce a non trivial fix that<br>
comes with a higher risk to the stability of the software and could<br>
delay the release)<br>
<br>
The alternative if we don't do that is that releases take forever<br>
because there will always be someone who has a last minute fix to<br>
commit (with the associated risk of introducing new bugs at the same<br>
time if they are not well tested straightforward fixes). Then we get<br>
into a spiraling effect of fixes introducing bugs, whose fixes<br>
introduce bugs, and so on, hopefully you get the idea.<br>
<br>
Sorry for the rant, we've gone through that exercise for MapServer<br>
several years ago and that has helped a lot, so I'd be in favor of<br>
more rigid release rules for GDAL as well.<br>
<br>
For reference, MapServer RFC34 documents the release process:<br></div></div>
<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> <<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>><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> <tel:%2B1%20418-696-5056%20%<u></u>23201><div><br>
<a href="http://www.mapgears.com/" target="_blank">http://www.mapgears.com/</a><br>
Provider of Professional MapServer Support since 2000<br>
<br></div>
______________________________<u></u>___________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a> <mailto:<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.<u></u>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>
<<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/gdal-dev</a>><div><br>
<br>
<br>
<br>
<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>
<br>
</div></blockquote><div><div>
<br>
<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<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></div>