Nice! Thanks On Wed, May 25, 2011 at 10:38 AM, Ademar Reis <[email protected]>wrote:
> On Fri, May 20, 2011 at 12:19 PM, Ademar Reis <[email protected]> > wrote: > > On Fri, May 20, 2011 at 11:12 AM, Antonio Gomes <[email protected]> > wrote: > >> Hi. > >> > >> Why bugs keep being added and removed from the meta bugs > "blocking/depends > >> on" list? It makes bugzilla too spammy, and does not make any sense to > me: > >> If it is FIXED, it will be marked (even visually) as such on the meta > >> blocker list, so why doubling the number of bugemails we get by removing > it > >> from the meta bug blocking list? > >> > >> For all other projects I've working on (including Mozilla and QtWebKit > in > >> the past) the meta bugs were common, but such a practice was not > happening. > >> but now it is. > >> > >> Maybe there is a good reason of course, but if it is noising more for > >> everybody than helping a small group, it should be reconsidered? > >> > > > > Hi Antonio. > > > > That's a recurrent question and an interesting discussion. I myself > > asked this same very question on the first day Simon explained the > > system to me. On these days, when I'm very active cherry-picking > > stuff, these e-mails start to bother everybody and someone always > > complains. :-) > > > > I'm sure there are some ways to improve the system and I'll propose a > > couple of them at the end, but in summary: > > > > Please note that the question: "which bugs are currently blocking the > > release?" is the most important question in terms of > > release-management (not just to me, but to all developers involved, > > managers, Q&A, etc). On traditional open source projects, that would > > be made by querying for OPEN bugs blocking the release meta-bug. > > > > But on webkit we don't track bugs on QtWebKit versions, we track bugs > > on trunk. That is: whenever a bug is FIXED, it's FIXED on trunk. > > There's no proper way to say: "this bug has been fixed on > > qtwebkit-2.2" and/or "this has been fixed on qtwebkit-2.1". So we need > > a hack. The current hack is: "if the bug blocks the 2.2 meta-bug, it > > has not been fixed there yet". Ditto for 2.1, 2.0 and for "bugs fixed > > in some release but pending trunk inclusion" (bug #32653). Corollary: > > there's no clean way to open a bug that affects only a particular > > release of QtWebKit (but that's a different problem that usually > > doesn't give us much trouble). > > > > So let's look at some alternatives or ways to mitigate the problem: > > (please note that the process is fully automated these days using > > qtwebkit-tools / webkitpy, so there will be a cost in implementing any > > of these changes) > > > > 1. I think one of the problems is that the current script does two > > actions on each blocking bug: a) add the comment about the cherry-pick > > and b) remove the bug from the blockers list. That triggers two > > e-mails. The script could be smarter and do both actions together (not > > currently supported by webkitpy, AFAIK). > > > > Done. :-) > > Now you should get one single e-mail when your bug fix is > cherry-picked, as both changes are committed together (the comment > addition and the bug removal from the blocking list). > > Naturally, if you watch the meta-bug as well, you'll get an additional > e-mail showing that your bug has been removed from its blocking list. > There's nothing I can do about that (it's an informative e-mail for > everybody else, after all). > > Thanks, > - Ademar > > -- > Ademar de Souza Reis Jr. <[email protected]> > Nokia Institute of Technology > -- --Antonio Gomes
_______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
