[webkit-qt] Question about the release process

[Ademar Reis]

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).

2. We could leave the bugs always blocking the meta-bug but add
keywords to individual bugs such as "IncludedInQtWebKit-22" and
"IncludedInQtWebKit-21" so that we could make a bugzilla query to see
what's pending inclusion (as a bonus, we would get a report of what's
included in each release via bugzilla). I think that's too intrusive
on the keyword system and other vendors may not like it... We'll have
to keep creating keywords for every of our releases. And you'll still
receive e-mails anyway when these keywords are added (probably less
e-mails).

3. [hack idea from Caio] Instead of keywords, we could have fake
emails added to the CC of cherry-picked bugs, such as
cherrypickedto22 at gmail.com. Same logic of keywords: a bugzilla query
would let us know which bugs block the release but don't have the
e-mail on the CC. Also triggers e-mails and is very hackish. :-)

4. We could come up with some filtering rules to discard e-mails that
just remove the bugs from the blocking list...

5. We could control the bugs blocking the release outside of bugzilla
(JIRA? I don't like this, controling the release outside of bugzilla
is a kind of dangerous route to follow).

Please note that the question: "which bugs have been fixed on this
particular release?" is currently answered via git-log (see my weekly
announcements). I don't plan to change that because sometimes I
cherry-pick stuff directly without involving the master bug (I watch
the trunk and cherry-pick regressions and crash fixes from other
vendors -- in these cases I just run my script that adds a comment on
the bug, thus minimally spamming the developers).

As the author of the changes, I don't receive any of these e-mails
(lucky me), so I don't know exactly which ones bother you most... How
do you think we could improve the system, given the "requirements" and
restrictions above?

Thanks,
  -  Ademar

-- 
Ademar de Souza Reis Jr. <ademar.reis at openbossa.org>
OpenBossa - Instituto Nokia de Tecnologia