Hi, 2011/12/23 Martin Landa <[email protected]>: >>> Apparently this issue is far from resolved, therefore I >>> would opt for releasing rc3 asap and fix that in 6.4.3. >> >> fine with me.. > > note that we have still two blockers [1]. > > Martin > > [1] > http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
recently I have fixed newly added blocker [1], so we have still 2 blocker remaining. Personally I am not satisfied with our release policy. It happed many times that RC stage was too long (not weeks but months). When looking at release policy of GDAL, RC stage takes few weeks, not few mouth as in our case. Currently Release/6.4.2RC2-News (15 Nov 2011) Release/6.4.2RC1-News (10 October 2011) In the beginning of December Hamish asked for RC3 (at least for me with no clear reason, but that's not the point). Since this time nothing happened (no RC3), besides that 2 more blockers have been reported (both accidentally by Hamish). If we manage to get RC3 in one week, we could get final 6.4.2 in the end of January, in the best case 3 months for RC stage. And then finally go ahead. It would be nice if all active developers would do everything for releasing and not trying to avoid every attempt to release. We should keep some realistic level. * our developers team is quite small, man power is low * assuming two releases for year, we cannot have RC stage for 3 or more months -> it's very time-consuming task especially for release manager, in other words we would be in RC stage most of the time (funny idea) * -> please mark blockers with *real* care * if blocker is marked by core developer, he/she should try to fix it and to postponing final release for month or two * the longer RC stage the more bugs are reported during this time, the higher probability for blockers, the higher probability for new and new RCs * bugs will reported in any case We need to decide 1) release often (let's say 2x by year with max RC2 for each release and release final within *one* month from RC1) 2) release once (by year/two years) have RC for months I would vote for 1) ideally RC1 in two weeks RC2 with one month final We should follow some rules and making our release policy smooth. I would like to thank release manager (Markus N) for incredible patience. He can sometimes get impression that he is only one from the developer team who like to release GRASS, putting new and new RC on his shoulders. Unfortunately I haven't his patience, I would like to open discussion about our releasing policy and make it reasonable. Martin [1] http://trac.osgeo.org/grass/ticket/1526 -- Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
