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