[GRASS-dev] GRASS 6.4.2 (was: GRASS extensions/addons mismatch)

GRASS GIS GRASS GIS developer
,
1

Hi,

2011/12/23 Martin Landa <landa.martin@gmail.com>:

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

2

1) release often (let's say 2x by year with max RC2 for each release and

release final within *one* month from RC1)

R, ubuntu and some other open source projects have a release-cycle twice a
year.

Martin's proposal sounds fine.

Helmut

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/GRASS-6-4-2-was-GRASS-extensions-addons-mismatch-tp7150208p7155993.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

3

On Thu, Jan 5, 2012 at 9:16 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

1) release often (let's say 2x by year with max RC2 for each release and

release final within *one* month from RC1)

R, ubuntu and some other open source projects have a release-cycle twice a
year.

Martin's proposal sounds fine.

Fine to me, too.

Markus

4

On 04/01/12 13:27, Martin Landa wrote:

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.

I don't think anyone is trying to "avoid every attempt to release". I think that it is more a debate about the level of quality and stability a release should have and about the criteria for that level.

* our developers team is quite small, man power is low

[...]

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

I'm very far from being involved enough to have any say on this, but I would just like to point out that if you add to the equation the fact that GRASS has a tradition of stability that you can trust, and if we want to honor that tradition, frequent releases imply quite a lot of man power in order to get things stable.

It's the old Debian vs Ubuntu debate and although I see some of the merits of Ubuntu, I do value Debian's release when ready philosophy (although I know this is evolving) and think that Ubuntu's fixed release schedule creates lot's of issues.

So, I think before deciding on a specific release frequency, it might be more important to decide on a clear release procedure, i.e. issues such as (just brainstorming here):

- who / what decides whether something is a blocker ?
- can anyone overrule that decision ?
- possibly: once a release candidate has been tagged, have any commit go through a control process in order to avoid to many unecessary and disturbing commits
- etc.

Even though this might need more man power in the short run, it could ease the work load in the long run.

I also do not think that the alternative between 1) and 2) is the only one. I.e. you could have less frequent releases, but still short RC periods. Those two issues are not necessarily linked.

Just my 2 c and now going back to preparing GIS and Remote sensing exams for my students using GRASS...

Moritz