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

[Markus Metz]

On Tue, Jun 14, 2011 at 5:35 PM, Martin Landa <landa.martin at gmail.com> wrote:
> 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 ;-)
>
>
I'm not against new features, I have myself introduced a number of new
features from 6.4.0 to 6.4.2. What I wanted to say is that I fully
agree with Helena and Hamish about the need for testing, that we may
need to think about a way to highly encourage testing before
backporting to 6.4, and that testing before submitting changes is IMHO
generally a good idea.

If you say that taking special care about three different branches is
too much for us, that means that changes really need to be tested for
7 as as well before submitting. As I said, in most cases testing can
be quickly done by the person introducing the changes, because that
person should know best what to test for.

Markus M