<div class="gmail_quote">On Fri, May 27, 2011 at 1:12 PM, Antonio Gomes <span dir="ltr"><<a href="mailto:tonikitoo@gmail.com">tonikitoo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Use-case: years from now someone finds a particular bug report on<br></div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
bugzilla. It's useful for them to know that it was fixed in<br>
QtWebKit-2.2.<br>
<br></blockquote></div><div><br>Well, comment could go to the meta bug? Or maybe your cherry-pick reports would be google'able, as you said below.<br></div></div></blockquote><div><br>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).<br>
<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
To know the list of bug(fix) included in a particular version of<br>
QtWebKit, I parse git-log and generate weekly reports, which are sent<br>
to the announcement mailing list and published on the wiki when a<br>
final release is made. See<br>
<a href="http://lists.qt.nokia.com/pipermail/qtwebkit-announce/2011-May/000003.html" target="_blank">http://lists.qt.nokia.com/pipermail/qtwebkit-announce/2011-May/000003.html</a><br>
and <a href="http://trac.webkit.org/wiki/QtWebKitRelease21" target="_blank">http://trac.webkit.org/wiki/QtWebKitRelease21</a> for example.<br>
<br></div><div class="im">
I review commits from the trunk looking for critical fixes and<br>
cherry-pick them directly to our stable branch(es), avoiding the<br>
block/unblock of our meta-bugs (otherwise you would get one more<br>
e-mail) :-)<br>
<br clear="all"></div></blockquote></div><br>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: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=563548" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=563548</a> ... WebKit is different and definitively would need a different approach.<br>
</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>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?<br>
</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>Well, as I said, it is not an easy problem :).<br></blockquote></div><br>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.<br>
<br>An important question: besides the notification e-mails, does the rest of our release process bothers someone?<br><br>Thanks,<br> - Ademar<br><br>-- <br>Ademar de Souza Reis Jr. <<a href="mailto:ademar.reis@openbossa.org" target="_blank">ademar.reis@openbossa.org</a>><br>
Nokia Institute of Technology<br>