[GRASS-dev] Re: testing in 6.5 before backporting to 6.4

[Martin Landa]

Hi,

2011/6/14 Markus Metz <markus.metz.giswork at googlemail.com>:
> A number of changes to 6.5 and 7.0 went in untested, which is IMHO not
> a good idea, but being development branches, maybe sometimes
> excusable. Any changes to the release branch should however be tested
> before submitted. For most changes, the kind of test is pretty much
> straightforward, and, if omitted and the change introduces a bug,
> places a burden on users and other developers to figure out what went
> wrong and why, wasting other people's time and leaving a not so good
> impression of a releasebranch.

I agree, the real problem is the manpower which we have, or better to
say we don't have. Taking special care about three branches - trunk
(development), devbr6 (test-bed) and relbr64 (only tested commits) is
too much for us. With current manpower and our requirements, we could
end up with frozen relbr64 for years. Other issue is G7, when it could
be released? One year, two years? At the end the situation forces us
to keep relbr64 alive, not only bugfixes. One example is progressive
wxGUI. In the case we would just backport bugfixes the wxGUI would
remain three more years without improvements (counting 6.4.0 and
7.0.0). Almost impossible to maintain (two different code bases).
After that most of the users start to use 7.0 (since 6.5 shouldn't be
far away from 6.4 branch). Your point is very good, but unfortunately
the number of people actively contributing to the project (GRASS) is
so low that it is going to be unrealistic. Nice to be a solid rock,
also think about releasing policy. To have old-solid release is nice,
at the end the most of user starts to use dev versions. Probably that
could be a reason, why such solid stable releases haven't so many
reported bugs ;-)


Martin

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa