[webkit-dev] Cherry-Pick Bug Comments

[Ademar Reis]

On Fri, May 27, 2011 at 1:12 PM, Antonio Gomes <tonikitoo at gmail.com> 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/000003.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. <ademar.reis at openbossa.org>
Nokia Institute of Technology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110527/d68af738/attachment.html>