[GRASS-dev] 6.4.4 planning

Moritz Lennert mlennert at club.worldonline.be
Mon May 26 03:58:43 PDT 2014


On 25/05/14 09:32, Markus Neteler wrote:
> On Fri, May 16, 2014 at 2:38 PM, Moritz Lennert
> <mlennert at club.worldonline.be> wrote:
>> On 15/05/14 23:14, Markus Neteler wrote:
> ...
>>>> Draft announcement to be updated:
>>>> http://trac.osgeo.org/grass/wiki/Release/6.4.4RC1-News
>>>>
>>>>>>> "Important bugs concerning the next release"
>>>>>>> https://trac.osgeo.org/grass/report/13
>>>>>
>>>>> Here the full list of issues but none is a blocker:
>>>>>
>>>>> https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=status&milestone=6.4.4
>>>>
>
>>>> To test on Windows:
>>>> g.remove cannot remove vector map because of space in DB layer name
>>>> https://trac.osgeo.org/grass/ticket/1438
>>
>>
>> You note that this should be wontfix. What do you want to be tested ?
>
> Right, nothing to be tested I guess. To be closed?

Yes.

>
>>>> ---------
>>>> r.walk backport
>>>> https://trac.osgeo.org/grass/ticket/1628
>>>
>>> ... not sure what to backport.
>
> Markus Metz may have an idea.



>
>>>> v.kcv backport
>>>> https://trac.osgeo.org/grass/ticket/2035
>>>
>> See my comment in the ticket.
>
> The vector overwrite issue in other mapsets seems to be a general
> problem, see ticket.

Yes, and I think this is serious enough to solve this before release, 
even if people seem to have lived with it for a long time...

>
>>> And/or I can tag RC1 now and we do these issues later.
>>
>> I think that except for the r.walk segfault, none are really showstoppers.
>> And even that only seems to be reproducible in a very specific situation.
>
> Given the recent discussion elsewhere I am stuck here.
> Do you want me to tag RC1 or wait ...?


I think that we should try to structure the entire release process a bit 
more as we are currently dealing with two release processes in parallel 
(6 and 7) and I have the feeling that this is a bit overwhelming for our 
little team and that the lack of clear structure of the process leads to 
the frustrations seen on the list lately.

I would, therefore, propose to focus on 6.4.4 for now, getting that out 
of the door before we work on 7.0 (especially since there seem to be 
some fundamental issues to be solved before releasing anything).

I also think that we should work out a clear calendar for that release 
with official announcements of freeze policy.

I think we are not far at all from releasing, so maybe something like this:

- Real freeze of grass64_release at the end of this week. This means 
that any backports from grass6_devel should happen before that moment. 
But only non-invasive and well-tested elements should be backported.

- RC1 beginning of next week

- Bug squashing effort during the two weeks that follow.

- RC2 around June 15th.

- Another week of bug squashing, if necessary.

- Release of 6.4.4 by end of June, the latest.

That sound ok ?

Moritz




More information about the grass-dev mailing list