[webkit-dev] Cherry-Pick Bug Comments

Fri May 27 06:43:43 PDT 2011

Hi Eric.

On Fri, May 27, 2011 at 1:37 AM, Eric Seidel <eric at webkit.org> wrote:
> It seems that whole discussion resolves around the same problem of
> cherry-picking causing too much bug noise. :)

With the recent spike in my cherry-picking activity, it was just a
matter of time until someone would complain. :-)

But that's an interesting discussion. I've been trying to improve the
process and reduce the noise and I'm sure we can always improve it.
See below.

> It would be very easy to store the "is this on the branch" bit off on a
> separate server.  If someone could describe in greater detail the Qt release
> process, I suspect we could easily design a separate store for this data
> (and tools to manipulate it).  The current system you all are using has no
> way to do multi-bug queries it seems.  You can't answer the question "how
> many bugs aren't merged", or?  And to check if a bug is merged you have to
> load the whole bug and look for the special comment?

The motivation behind this comment is not to allow bugzilla queries,
but to actually inform the bug reporter, people on the CC and others
that this particular bugfix has been included in that particular
version of QtWebKit. I consider this information useful and think the
best place to keep it is Bugzilla (although the exact way this is
stored not that important).

Use-case: years from now someone finds a particular bug report on
bugzilla. It's useful for them to know that it was fixed in
QtWebKit-2.2.

To know the list of bug(fix) included in a particular version of
QtWebKit, I parse git-log and generate weekly reports, which are sent
to the announcement mailing list and published on the wiki when a
final release is made. See
http://lists.qt.nokia.com/pipermail/qtwebkit-announce/2011-May/000003.html
and http://trac.webkit.org/wiki/QtWebKitRelease21 for example.

To know which bugs are blocking the release (pending inclusion), we
use meta-bugs, see my summary on the qtwebkit ml a while ago:
https://lists.webkit.org/pipermail/webkit-qt/2011-May/001560.html
(that discussion was similar to this one, but triggered by a different
kind of e-mails people get: block/unblock notifications).

I review commits from the trunk looking for critical fixes and
cherry-pick them directly to our stable branch(es), avoiding the
block/unblock of our meta-bugs (otherwise you would get one more
e-mail) :-)

It would be nice to use keywords instead of these comments to allow
bugzilla queries. The problem is that ideally we would need one
keyword for each release (ex: "IncludedInQtWebKit21",
"IncludedInQtWebKit211", "IncludedInQtWebKit22", etc). Since keywords
are not free tags, the system will not scale.

If someone is interested in the scripts I use (warning: they're a bit
hackish), they're stored in gitorious:
https://gitorious.org/qtwebkit/tools/commits/master

I'm totally biased to propose solutions, but I think the best one
would be a filter on the client side. I say that because the
notification e-mail with the comment is indeed useful to some people.

But....

Maybe it bugs more people than it helps, so we should find a
compromise solution. I like Evan's suggestion: it would be awesome if
I could change bugs without triggering e-mails. I could send e-mails
only when it's a Qt bug and, more importantly, I could manipulate the
blocking list without bothering anyone with tons of notifications. :-)

Is it feasible to change bugzilla this way? Any other proposals?

Thanks,
  - Ademar

> -eric
>
> On Fri, May 27, 2011 at 4:28 AM, Antonio Gomes <tonikitoo at gmail.com> wrote:
>>
>> We had this exactly discussion in qtwebkit mailing list days ago:
>> https://lists.webkit.org/pipermail/webkit-qt/2011-May/001555.html . It is
>> worth reading through if you are interested in this topic!
>>
>> We would really like to reduce the noise of "management bugmails", but
>> without a clear good solution for now yet. The "silent" comments suggested
>> by Evan would be a great alternative to the problem if bugzilla could get
>> expanded to support it, imo...
>>
>>
>> On Thu, May 26, 2011 at 7:05 PM, Evan Martin <evan at chromium.org> wrote:
>>>
>>> On Thu, May 26, 2011 at 3:54 PM, Eric Seidel <eric at webkit.org> wrote:
>>> > I get a lot of these:
>>> > Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab1
>>> > <http://gitorious.org/webkit/qtwebkit/commit/7e1bab1>
>>> > as bug mail.  Probably because I'm CC'd on a zillion bugs (and actually
>>> > read
>>> > my bug mail).
>>> >
>>> > This is probably the pot calling the kettle black, since I wrote many
>>> > of the
>>> > bots which comment daily on bugs...
>>> > ...but, I'm wondering if we can do better?
>>> > Would it better serve the cherry-picker's needs if we instead had a
>>> > separate
>>> > server to track revision -> cherry-picks?  Or bug ids -> cherry-picks?
>>> > (Like
>>> > how the EWS bots store their status on queues.webkit.org and display it
>>> > in
>>> > little bubbles on bugs.webkit.org w/o commenting on the bugs.)
>>> >
>>> > I'm strongly supportive of all clients of webkit storing all of their
>>> > bug-related data in bugs.webkit.org.  It's better than the alternative
>>> > (lots
>>> > of data buried in old Radars, or Chromium bugs, etc.)
>>> > But perhaps someone has a good idea how to reduce unnecessary bugmail?
>>>
>>> I've seen some bug trackers reduce email by allowing you to comment
>>> without sending email.  In effect you're just attaching metadata to
>>> the bug without notifying everyone about it.
>>>
>>> However, the comments left by the EWS are intended for the bug authors
>>> and so they probably should continue sending mail.
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> --
>> --Antonio Gomes
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

-- 
Ademar de Souza Reis Jr. <ademar.reis at openbossa.org>
Nokia Institute of Technology