[GRASS-PSC] GRASS6.4.4 release [was: Re: [GRASS-dev] GRASS 7 release planning]
On 23/06/14 17:35, Martin Landa wrote: Hi, 2014-06-23 10:56 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: But, even though, I know you are in a hurry to get a grass7 release out of the door, don't you think that we should finish 6.4.4 first ? To be honest I think we will have to accept shipping OSGEOLive with 6.4.4... Right, as far as I know Markus is off-line since 27/6. So let's start with idea to mark RC2 as a final and release it _this_week_! I don't know about any blockers. Any opinion? If you know about blockers let us know about that ASAP! I launched a new thread with an evaluation of current bugs and last call for fixes. Two tickets seem to warrant a backport, but I'm not familiar enough with them to judge. Maybe we should just go ahead and backport, then release RC2, test that with a special focus on these two backports, and then release by the end of the week ? Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS6.4.4 release [was: Re: [GRASS-dev] GRASS 7 release planning]
Hi, To be honest I think we will have to accept shipping OSGEOLive with 6.4.4... The focus there is a split between being a showcase for new features and super-stable introduction for new users. (power users might see past small transient bugs, but if a new user finds rough edges in the first 5-15 minutes, or before they get past the initial learning curve, the window of opportunity is lost and they'll give up) So far the balance on the disc has been to more favour stable over new. Feature freeze is in just a couple weeks, QGIS plugin would need to be 100% ready and rebuilt, and we'd not have a sample dataset included, would need to have a GRASS_BATCH_FILE import script to set one up from the data already on the disc. fyi I plan to write a script which will be on the disc which will automatically add the appropriate ppa repos and download+install the latest grass7 snapshot and sample data. What version does the foss4g workshop want to use? Note the NC dataset only ships in geotiff+shapefile form so it can be used by all the other projects too, due to disc space limitations the workshop setup will have to download that too. (spearfish is small enough to include for G6 though) There is a link on the live disc desktop to this URL: http://trac.osgeo.org/osgeo/wiki/Live_GIS_Workshop_Install fwiw I will also be writing a G6 script for pre-installing some G6 addon modules. If you have any you want included, place your orders in a osgeo trac ticket please (LiveDVD component), cc 'hamish'. Right, as far as I know Markus is off-line since 27/6. So let's start with idea to mark RC2 as a final and release it _this_week_! I don't know about any blockers. Any opinion? If you know about blockers let us know about that ASAP! I have been very busy with work recently, and will be for the next weeks too. In the past I've been able to review all commits to the stable branch, right now I am rather behind in that task. So if it goes out now just be warned that I might be asking for a small-change 6.4.5 release after a month as some sort of 6.4.4.1, since there are always some bugs to find. :-) I would also be a bit slow on the Debian packaging this time and not sure if I could write the release announcement. Work and GSoC has all my time right now, sorry. fwiw the debian rule for packages being accepted into the stable branch is not that they are perfect, only that they are less buggy than the old version. For the spatialite export bug I think that's fair advice to follow: it is not fixed, but no more broken than the previous release. Since v.out.ogr is such a critical module, and the fix requires the module to be improved with a bunch of 2D vs 3D export logic, my vote would be to release 6.4.4 without it, but then try hard soon after release to get it fixed, so maximum pre-release testing time. -- Even though it's pretty crazy/embarrassing that GRASS isn't supporting export to Spatialite currently. My thoughts on r.li are very similar, chances are that the big backport still has some maturing to do, but the earlier version was wrong so perhaps-problems-but-improving beats known-bad. best regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] [GRASS-dev] GRASS6.4.4 release [was: Re: GRASS 7 release planning]
Hi, 2014-06-24 11:06 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: Two tickets seem to warrant a backport, but I'm not familiar enough with could you write us which tickets you have in mind? Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] [GRASS-dev] GRASS 7 release planning
Just noting, that I like Martin's analogy to GRASS 5.0 versus 5.1 some time ago. History is repeating. 2014-06-23 17:35 GMT+02:00 Martin Landa landa.mar...@gmail.com: Hi, 2014-06-23 10:56 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: ... so, getting out 7.0 seems to be endless... A radical solution might be to change trunk into GRASS GIS 8. Then we do not need to wait in 7 for API stabilization and can release it as is and go ahead with the planned massive improvements. I think that there is no need for GRASS 8 at this moment, it's not related to GRASS 7 release management. The real problem is that we don't have clear list of desired features for GRASS 7. Once we start with RC stage we need to be sure that we are close to the final release - to avoid RC for months or even several months like happen in the past. We should also vote about RFC4 before we start with RC stage. Personally I would start with GRASS 8 when there will be a clear reason for that. This sound ok to me. So, ideally, at all times we should have one release branch and one development branch. Releases can then just be tagged from the release branch which gets only selected, well-tested, not to invasive backports from the dev branch. That is also reason why I would keep trunk as 7.1 before we start with tagging 7.0.0RC1. Once we decide that the dev branch is sufficiently different from release that backports become unfeasible, and sufficiently stabilised that we can branch a release branch out of it, we declare the previous release branch a legacy maintenance branch (with only limited bug fixing from that point on), and branch a new release branch. I would prefer to create just release branches. E.g. * We start with tagging 7.0.0RC1. * We create releasebranch_7_1 from trunk * Trunk becomes 7.2 or GRASS 8 * We continue with backports only in releasebranch_7_0 towards final release * Development will continue in trunk and releasebranch_7_1 * After some period we freeze releasebranch_7_1 and create releasebrach_7_2 from trunk/releasebranch_7_1. * We start RC stage in releasebranch_7_1 * Development will continue in trunk a releasebranch_7_2. [...] But, even though, I know you are in a hurry to get a grass7 release out of the door, don't you think that we should finish 6.4.4 first ? To be honest I think we will have to accept shipping OSGEOLive with 6.4.4... Right, as far as I know Markus is off-line since 27/6. So let's start with idea to mark RC2 as a final and release it _this_week_! I don't know about any blockers. Any opinion? If you know about blockers let us know about that ASAP! Martin ___ grass-dev mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
