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