Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Mon, Jun 6, 2011 at 11:13 AM, Ademar Reis  wrote:
> On Sun, Jun 5, 2011 at 2:03 AM, Eric Carlson  wrote:
>>
>> On Jun 3, 2011, at 2:30 PM, Adam Barth wrote:
>>
>> Either (1) or (2) is fine.  Please pick one and do it.  The status quo
>> is very annoying.
>>
>>   Yes, please!
>
> I'll post these comments only on [Qt] bugs until we implement a solution.
>

One exception: I'll also add the comment to security bugs for now,
just to make our lives easier. Since the inflow of security-fixes is
very low, the noise should be minimal.

Thanks,
   - Ademar

-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Sun, Jun 5, 2011 at 2:03 AM, Eric Carlson  wrote:
>
> On Jun 3, 2011, at 2:30 PM, Adam Barth wrote:
>
> Either (1) or (2) is fine.  Please pick one and do it.  The status quo
> is very annoying.
>
>   Yes, please!

I'll post these comments only on [Qt] bugs until we implement a solution.

Sorry for the noise.
  - Ademar



-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Eric Carlson]

On Jun 3, 2011, at 2:30 PM, Adam Barth wrote:

> Either (1) or (2) is fine.  Please pick one and do it.  The status quo
> is very annoying.
> 
  Yes, please!

eric


> 
> 
> On Tue, May 31, 2011 at 6:58 AM, Ademar Reis  
> wrote:
>> On Thu, May 26, 2011 at 7:54 PM, Eric Seidel  wrote:
>>> I get a lot of these:
>>> Revision r86028 cherry-picked into qtwebkit-2.2 with 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.)
>> 
>> Hi again.
>> 
>> Just so that this thread doesn't die. I think we have two good
>> proposals on the table:
>> 
>> 1. Track cherry-pick info on an external server and add an iframe
>> inside bugzilla, the same way EWS bots do.
>> Pros: scalable, any vendor could add their own trackers (would it be
>> interesting to add rdar:// comments using this same mechanism?)
>> 
>> 2. Configure/hack bugzilla to allow the addition of comments without
>> trigerring e-mails.
>> Pros: small change, appears to be easy to implement - specially on my side 
>> ;-)
>> 
>> Eric: how do we proceed from now?
>> 
>> In the meanwhile, please be patient with the cherry-pick e-mails... As
>> usual there will be a few of them this week (in average, something
>> like 20-30 cherry-picks per week).
>> 
>> Thanks,
>>  - Ademar
>> 
>> --
>> Ademar de Souza Reis Jr. 
>> Nokia Institute of Technology
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Adam Barth]

Either (1) or (2) is fine.  Please pick one and do it.  The status quo
is very annoying.

Adam


On Tue, May 31, 2011 at 6:58 AM, Ademar Reis  wrote:
> On Thu, May 26, 2011 at 7:54 PM, Eric Seidel  wrote:
>> I get a lot of these:
>> Revision r86028 cherry-picked into qtwebkit-2.2 with 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.)
>
> Hi again.
>
> Just so that this thread doesn't die. I think we have two good
> proposals on the table:
>
> 1. Track cherry-pick info on an external server and add an iframe
> inside bugzilla, the same way EWS bots do.
> Pros: scalable, any vendor could add their own trackers (would it be
> interesting to add rdar:// comments using this same mechanism?)
>
> 2. Configure/hack bugzilla to allow the addition of comments without
> trigerring e-mails.
> Pros: small change, appears to be easy to implement - specially on my side ;-)
>
> Eric: how do we proceed from now?
>
> In the meanwhile, please be patient with the cherry-pick e-mails... As
> usual there will be a few of them this week (in average, something
> like 20-30 cherry-picks per week).
>
> Thanks,
>  - Ademar
>
> --
> Ademar de Souza Reis Jr. 
> Nokia Institute of Technology
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Thu, May 26, 2011 at 7:54 PM, Eric Seidel  wrote:
> I get a lot of these:
> Revision r86028 cherry-picked into qtwebkit-2.2 with 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.)

Hi again.

Just so that this thread doesn't die. I think we have two good
proposals on the table:

1. Track cherry-pick info on an external server and add an iframe
inside bugzilla, the same way EWS bots do.
Pros: scalable, any vendor could add their own trackers (would it be
interesting to add rdar:// comments using this same mechanism?)

2. Configure/hack bugzilla to allow the addition of comments without
trigerring e-mails.
Pros: small change, appears to be easy to implement - specially on my side ;-)

Eric: how do we proceed from now?

In the meanwhile, please be patient with the cherry-pick e-mails... As
usual there will be a few of them this week (in average, something
like 20-30 cherry-picks per week).

Thanks,
  - Ademar

-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ojan Vafai]

On Mon, May 30, 2011 at 6:07 AM, Ademar Reis wrote:

> On Sun, May 29, 2011 at 8:38 PM, Ojan Vafai  wrote:
> > I think we should be able to make everyone happy if we handle these the
> same
> > way we handle the EWS and style bots.
> > The data lives on another server (appengine in this case) and is brought
> > into the bugzilla page via an iframe. We could have an iframe for the Qt
> > release that is empty by default, but shows a link to the release when
> that
> > patch has been integrated into a branch.
>
> Hi Ojan.
>
> I'm not sure I understand what you mean... Could you give me an example?
>

Take a look at https://bugs.webkit.org/show_bug.cgi?id=61727. Under "Review
Patch  |
Details 
| Formatted
Diff  |
Diff ", there
is an iframe that contains the results from the various queues that patch
has been run through. We could similarly have an iframe dedicated to the qt
release process.

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Fri, May 27, 2011 at 6:29 PM, James Robinson  wrote:
> I find these cherry-pick bug comments annoying and hope that you will stop
> generating them.  There are many ports that make releases based off of
> WebKit trunk, and all of them have some notion of release branches that
> contain cherry-picked revisions, reverts, etc.  As a developer it's nearly
> always irrelevant to me whether a given patch is cherry-picked into a given
> Qt release or not, just as it would be to know if that revision was
> cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch.
>  When I do need to know the status of a specific branch, I look in the
> port-specific location of the branch to see what happened.  For example, to
> see what's in a given chromium release I look in the appropriate
> subdirectory of http://trac.webkit.org/browser/branches/chromium.  For the
> Safari 534
> branch, http://trac.webkit.org/browser/branches/safari-534-branch etc.
> I would recommend that the people who work on QtWebKit figure out a way to
> track revisions in their release branches in a way that does not involve
> spamming non-Qt bugs on bugs.webkit.org or developers who aren't working
> directly on Qt.

Hi James.

Does the fact that the comment appears in the bug annoys you, or the
fact that you receive an e-mail notification?
(because one of the potential solutions is to add the comment without
triggering an e-mail)

Thanks,
  - Ademar

> On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes  wrote:
>>
>>> An important question: besides the notification e-mails, does the rest of
>>> our release process bothers someone?
>>>
>> Not me. It works fine and is very transparent.
>>
>>
>> --
>> --Antonio Gomes
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>



-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Sun, May 29, 2011 at 8:38 PM, Ojan Vafai  wrote:
> I think we should be able to make everyone happy if we handle these the same
> way we handle the EWS and style bots.
> The data lives on another server (appengine in this case) and is brought
> into the bugzilla page via an iframe. We could have an iframe for the Qt
> release that is empty by default, but shows a link to the release when that
> patch has been integrated into a branch.

Hi Ojan.

I'm not sure I understand what you mean... Could you give me an example?

Thanks,
  - Ademar


>
> On Fri, May 27, 2011 at 2:29 PM, James Robinson  wrote:
>>
>> I find these cherry-pick bug comments annoying and hope that you will stop
>> generating them.  There are many ports that make releases based off of
>> WebKit trunk, and all of them have some notion of release branches that
>> contain cherry-picked revisions, reverts, etc.  As a developer it's nearly
>> always irrelevant to me whether a given patch is cherry-picked into a given
>> Qt release or not, just as it would be to know if that revision was
>> cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch.
>>  When I do need to know the status of a specific branch, I look in the
>> port-specific location of the branch to see what happened.  For example, to
>> see what's in a given chromium release I look in the appropriate
>> subdirectory of http://trac.webkit.org/browser/branches/chromium.  For the
>> Safari 534
>> branch, http://trac.webkit.org/browser/branches/safari-534-branch etc.
>> I would recommend that the people who work on QtWebKit figure out a way to
>> track revisions in their release branches in a way that does not involve
>> spamming non-Qt bugs on bugs.webkit.org or developers who aren't working
>> directly on Qt.
>> - James
>>
>> On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes 
>> wrote:
>>>
 An important question: besides the notification e-mails, does the rest
 of our release process bothers someone?

>>> Not me. It works fine and is very transparent.
>>>
>>>
>>> --
>>> --Antonio Gomes
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ojan Vafai]

I think we should be able to make everyone happy if we handle these the same
way we handle the EWS and style bots.

The data lives on another server (appengine in this case) and is brought
into the bugzilla page via an iframe. We could have an iframe for the Qt
release that is empty by default, but shows a link to the release when that
patch has been integrated into a branch.

Ojan

On Fri, May 27, 2011 at 2:29 PM, James Robinson  wrote:

> I find these cherry-pick bug comments annoying and hope that you will stop
> generating them.  There are many ports that make releases based off of
> WebKit trunk, and all of them have some notion of release branches that
> contain cherry-picked revisions, reverts, etc.  As a developer it's nearly
> always irrelevant to me whether a given patch is cherry-picked into a given
> Qt release or not, just as it would be to know if that revision was
> cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch.
>  When I do need to know the status of a specific branch, I look in the
> port-specific location of the branch to see what happened.  For example, to
> see what's in a given chromium release I look in the appropriate
> subdirectory of http://trac.webkit.org/browser/branches/chromium.  For the
> Safari 534 branch,
> http://trac.webkit.org/browser/branches/safari-534-branch etc.
>
> I would recommend that the people who work on QtWebKit figure out a way to
> track revisions in their release branches in a way that does not involve
> spamming non-Qt bugs on bugs.webkit.org or developers who aren't working
> directly on Qt.
>
> - James
>
> On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes wrote:
>
>>
>> An important question: besides the notification e-mails, does the rest of
>>> our release process bothers someone?
>>>
>>> Not me. It works fine and is very transparent.
>>
>>
>> --
>> --Antonio Gomes
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[James Robinson]

I find these cherry-pick bug comments annoying and hope that you will stop
generating them.  There are many ports that make releases based off of
WebKit trunk, and all of them have some notion of release branches that
contain cherry-picked revisions, reverts, etc.  As a developer it's nearly
always irrelevant to me whether a given patch is cherry-picked into a given
Qt release or not, just as it would be to know if that revision was
cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch.
 When I do need to know the status of a specific branch, I look in the
port-specific location of the branch to see what happened.  For example, to
see what's in a given chromium release I look in the appropriate
subdirectory of http://trac.webkit.org/browser/branches/chromium.  For the
Safari 534 branch, http://trac.webkit.org/browser/branches/safari-534-branch
 etc.

I would recommend that the people who work on QtWebKit figure out a way to
track revisions in their release branches in a way that does not involve
spamming non-Qt bugs on bugs.webkit.org or developers who aren't working
directly on Qt.

- James

On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes  wrote:

>
> An important question: besides the notification e-mails, does the rest of
>> our release process bothers someone?
>>
>> Not me. It works fine and is very transparent.
>
>
> --
> --Antonio Gomes
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

> An important question: besides the notification e-mails, does the rest of
> our release process bothers someone?
>
> Not me. It works fine and is very transparent.


-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Fri, May 27, 2011 at 1:12 PM, Antonio Gomes  wrote:

> 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.
>>
>>
> Well, comment could go to the meta bug? Or maybe your cherry-pick reports
> would be google'able, as you said below.
>

It's a possible approach, although less useful IMO. I really see value in
the comment added to individual bugs (and I'm sure others as well, as some
people reply to these cherry-pick comments).



>  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/03.html
>> and http://trac.webkit.org/wiki/QtWebKitRelease21 for example.
>>
>> 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) :-)
>>
>>
> The real problem is that bugzilla is not made for less-simple release
> processes like this. Well, at least not the bugzilla webkit uses now. I know
> Mozilla's bugzilla has a bunch of "block-release-xx -, +, ?" fields, or
> 'whiteboard' field so that people add useful general information to the bug,
> and they make it much less noisy. However, it is one product, one company,
> and on interest (in general), which it Firefox. See this one, for example:
> https://bugzilla.mozilla.org/show_bug.cgi?id=563548 ... WebKit is
> different and definitively would need a different approach.
>

> Good that we all agree that it is really not ideal as it is now. Not sure
> how Apple's internal bugtracking work on that matter, but  there is the
> 'InRandar' keyword. Maybe Qt could get something similar and JIRA could be
> used for tracking progresses on QtWebKit releases?
>

Our experience moving the release control out of bugzilla in the past was
not positive. I see a lot of value in having the release process as
transparent and public as possible and "forcing" developers to focus always
on bugzilla (instead of having to decide where to report issues or how to
keep them in sync) has worked well so far.


>
> Well, as I said, it is not an easy problem :).
>

Definetly not, specially if we try to scale it to all vendors (imagine if
all vendors decide to control their releases via bugzilla). We also don't
have a proper way of reporting bugs that don't affect trunk and if we start
having a large influx of such reports, we'll have to opt for an external bug
database or request changes in webkit's bugzilla.

An important question: besides the notification e-mails, does the rest of
our release process bothers someone?

Thanks,
   - Ademar

-- 
Ademar de Souza Reis Jr. 
Nokia Institute of Technology
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

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.
>
>
Well, comment could go to the meta bug? Or maybe your cherry-pick reports
would be google'able, as you said below.


> 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/03.html
> and http://trac.webkit.org/wiki/QtWebKitRelease21 for example.
>
> 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) :-)
>
>
The real problem is that bugzilla is not made for less-simple release
processes like this. Well, at least not the bugzilla webkit uses now. I know
Mozilla's bugzilla has a bunch of "block-release-xx -, +, ?" fields, or
'whiteboard' field so that people add useful general information to the bug,
and they make it much less noisy. However, it is one product, one company,
and on interest (in general), which it Firefox. See this one, for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=563548 ... WebKit is different
and definitively would need a different approach.

Good that we all agree that it is really not ideal as it is now. Not sure
how Apple's internal bugtracking work on that matter, but  there is the
'InRandar' keyword. Maybe Qt could get something similar and JIRA could be
used for tracking progresses on QtWebKit releases?

Well, as I said, it is not an easy problem :).

-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

Hi Eric.

On Fri, May 27, 2011 at 1:37 AM, Eric Seidel  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/03.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  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  wrote:
>>>
>>> On Thu, May 26, 2011 at 3:54 PM, Eric Seidel  wrote:
>>> > I get a lot of these:
>>> > Revision r86028 cherry-picked into qtwebkit-2.2 with 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 a

Re: [webkit-dev] Cherry-Pick Bug Comments

[Eric Seidel]

It seems that whole discussion resolves around the same problem of
cherry-picking causing too much bug noise. :)

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?

-eric

On Fri, May 27, 2011 at 4:28 AM, Antonio Gomes  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  wrote:
>
>> On Thu, May 26, 2011 at 3:54 PM, Eric Seidel  wrote:
>> > I get a lot of these:
>> > Revision r86028 cherry-picked into qtwebkit-2.2 with 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@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> --Antonio Gomes
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

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  wrote:

> On Thu, May 26, 2011 at 3:54 PM, Eric Seidel  wrote:
> > I get a lot of these:
> > Revision r86028 cherry-picked into qtwebkit-2.2 with 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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Evan Martin]

On Thu, May 26, 2011 at 3:54 PM, Eric Seidel  wrote:
> I get a lot of these:
> Revision r86028 cherry-picked into qtwebkit-2.2 with 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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev