[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/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?

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

-- 
--Antonio Gomes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110527/9dd7039a/attachment.html>