[webkit-dev] Comment on the bug & email author/reviewer before reverting a patch
mjs at apple.com
Wed Jul 9 19:25:19 PDT 2014
> On Jul 9, 2014, at 4:45 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Wednesday, July 9, 2014, Brady Eidson <beidson at apple.com> wrote:
>> On Jul 9, 2014, at 4:15 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> Again, im not requesting anything new here. The consensus on webkit-dev has been to ping the author/reviewer on IRC or via email and comment in the original bug PRIOR to using webkitbot to start reverting the patch.
> I went through the first handful of emails on that thread. The original request that wasn’t meeting a lot of opposition before I stopped digging through the thread was:
> “Please contact the author/reviewer and give them a reasonable amount of time before rolling out their patch.”
> I did not reach the message where the consensus was “contact the author and reviewer manually, do not use webkitbot”
> I believe that using webkitbot:
> 1 - Comments in a new bugzilla created specifically because there’s an issue
> 2 - Comments in the original bugzilla notifying of an issue
> It doesn't. The bot only files a new bug, make it a blocker of the original bug, and then reopen the bug.
> It doesn't copy over any comments made in the new bug for example.
> Assuming my webkitbot command contains a description of the reason this patch is suspect, including a URL to the failure, can you further explain why using webkitbot is unreasonable?
> I'm not saying that using webkitbot is unreasonable. I'm saying that the person trying to revert a patch should first inform the author/reviewer first BEFORE start reverting the patch.
> Since webkitbot doesn't automatically post the details as to what failures the patch caused, and one line description is almost never adequate (e.g. needs a hyperlink to buildbot page, test failure diff or error log, et c...), I don't see how using webkitbot in its current state could ever be adequate.
> Of course, I'm not saying that webkitbot could never be improved to do these things.
What things need to be done in addition to using 'webkitbot rollout’ to meet a sufficient standard of notification? I assume based on your comments that it should:
(1) Add a comment to the original bug that caused the regression (maybe something like “this caused regression bug XXX” where XXX is the rollout bug).
(2) Add links to diagnostic information about the problem (e.g. buildbot results page showing the failure, or website URL illustrating a regression). They should probably go in the bug reporting the regression, not the original bug.
Anything else? It seems like (1) and (2) could be done manually while also using ‘webkitbot rollout’, and (1) could in principle be done by the bot. Would you object if someone used ‘webkitbot rollout’ and then did (1) and (2)?
Is there anything it does that it should not do? I assume reopening the original bug before the rollout lands is a case of this but it’s not clear to me that this is a showstopper.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev