From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Tue, 19 Oct 2010 10:32:27 +0200

  On 19.10.2010 09:22, Linus Nielsen Feltzing wrote:
> On 2010-10-19 05:17, Jonathan Gordon wrote:
>> My view would be that any bugfix for a flyspray task would be a
>> candidate to go in the stable branch. Fixes which are too fiddly to
>> backport would probably miss out (or at that point we talk about a new
>> minor stable build (but 3.7.3 -> 3.8)).
>
> I think that this is a great idea. Backporting bugfixes to the stable
> branch is IMHO the way to go.

I agree.

>
>> I was really hoping to get more feedback, if no one cares about
>> talking about it there is a good chance no one will bother with the
>> work of keeping the stable branch updated and tested and working. This
>> simply wont work if only a few people look after the branch.
>

Perhaps a way to do it would be to grep the commit messages for keywords
("fix", "bug", "undo", "revert", ....). This could be done by a cronjob
which then publishes the results on some website or emails them to a
release manager.

Then once in a while a guy or two (or a bot) would ask the committers of
the commits found by grep whether they should be backported or not. Or
the grep results would be visible for anyone so every committer can look
each week or so if he forgot to backport one of his commits.

For some commits it will possibly be straight-forward so that the
release manager can do the backport alone.

For this to work we also need to separate bug fix and feature commits
more strictly.

> As I see it, the biggest problem we have today is keeping up with all
> the targets and being able to do proper (regression) testing. Most of
> us only have a few targets, and are rarely using more than one target
> on a daily basis.
>
> I think the best solution would be to have one maintainer for each
> target, who can test each release on his target before every release.
>
> Linus

Sure that would be nice but it's not realistic is it? I think we have
already more targets than active developers, and even the active ones
aren't always around when testing a case is needed.

I think we should work a lot more with RC builds to let users test on
targets for which we don't currently have a maintainer around. If an RC
build is untested then it's likely that only very few (if any) will use
the release on those targets anyway.

In general I think we deliver relatively good quality releases
considering that we can't really do batch regression testing (right
now). Maybe we worry too much?

Best regards.
Received on 2010-10-19