[webkit-qt] Question about the release process

[Antonio Gomes]

Nice! Thanks

On Wed, May 25, 2011 at 10:38 AM, Ademar Reis <ademar.reis at openbossa.org>wrote:

> On Fri, May 20, 2011 at 12:19 PM, Ademar Reis <ademar.reis at openbossa.org>
> wrote:
> > On Fri, May 20, 2011 at 11:12 AM, Antonio Gomes <tonikitoo at gmail.com>
> wrote:
> >> Hi.
> >>
> >> Why bugs keep being added and removed from the meta bugs
> "blocking/depends
> >> on" list? It makes bugzilla too spammy, and does not make any sense to
> me:
> >> If it is FIXED, it will be marked (even visually) as such on the meta
> >> blocker list, so why doubling the number of bugemails we get by removing
> it
> >> from the meta bug blocking list?
> >>
> >> For all other projects I've working on (including Mozilla and QtWebKit
> in
> >> the past) the meta bugs were common, but such a practice was not
> happening.
> >> but now it is.
> >>
> >> Maybe there is a good reason of course, but if it is noising  more for
> >> everybody than helping a small group, it should be reconsidered?
> >>
> >
> > Hi Antonio.
> >
> > That's a recurrent question and an interesting discussion. I myself
> > asked this same very question on the first day Simon explained the
> > system to me. On these days, when I'm very active cherry-picking
> > stuff, these e-mails start to bother everybody and someone always
> > complains. :-)
> >
> > I'm sure there are some ways to improve the system and I'll propose a
> > couple of them at the end, but in summary:
> >
> > Please note that the question: "which bugs are currently blocking the
> > release?" is the most important question in terms of
> > release-management (not just to me, but to all developers involved,
> > managers, Q&A, etc). On traditional open source projects, that would
> > be made by querying for OPEN bugs blocking the release meta-bug.
> >
> > But on webkit we don't track bugs on QtWebKit versions, we track bugs
> > on trunk. That is: whenever a bug is FIXED, it's FIXED on trunk.
> > There's no proper way to say: "this bug has been fixed on
> > qtwebkit-2.2" and/or "this has been fixed on qtwebkit-2.1". So we need
> > a hack. The current hack is: "if the bug blocks the 2.2 meta-bug, it
> > has not been fixed there yet". Ditto for 2.1, 2.0 and for "bugs fixed
> > in some release but pending trunk inclusion" (bug #32653). Corollary:
> > there's no clean way to open a bug that affects only a particular
> > release of QtWebKit (but that's a different problem that usually
> > doesn't give us much trouble).
> >
> > So let's look at some alternatives or ways to mitigate the problem:
> > (please note that the process is fully automated these days using
> > qtwebkit-tools / webkitpy, so there will be a cost in implementing any
> > of these changes)
> >
> > 1. I think one of the problems is that the current script does two
> > actions on each blocking bug: a) add the comment about the cherry-pick
> > and b) remove the bug from the blockers list. That triggers two
> > e-mails. The script could be smarter and do both actions together (not
> > currently supported by webkitpy, AFAIK).
> >
>
> Done. :-)
>
> Now you should get one single e-mail when your bug fix is
> cherry-picked, as both changes are committed together (the comment
> addition and the bug removal from the blocking list).
>
> Naturally, if you watch the meta-bug as well, you'll get an additional
> e-mail showing that your bug has been removed from its blocking list.
> There's nothing I can do about that (it's an informative e-mail for
> everybody else, after all).
>
> Thanks,
>  - Ademar
>
> --
> Ademar de Souza Reis Jr. <ademar.reis at openbossa.org>
> Nokia Institute of Technology
>



-- 
--Antonio Gomes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20110525/0980343b/attachment.html>