[webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes
rniwa at webkit.org
Thu May 23 10:52:19 PDT 2013
I always post patches as my patch saying I'm merging some patch with a
chromium.googlesource.com URL as in:
In a lot of cases, I find myself fixing the patch or rewriting the patch
because either the patch is wrong, doesn't conform to the WebKit style, or
it can be improved.
- R. Niwa
On Thu, May 23, 2013 at 9:49 AM, Andreas Kling <akling at apple.com> wrote:
> On May 23, 2013, at 6:26 PM, Darin Adler <darin at apple.com> wrote:
> On May 23, 2013, at 8:42 AM, Sergio Villar Senin <svillar at igalia.com>
> There is an interesting question about merging fixes from Blink. Should we
> keep the original author in the ChangeLog appending the name of the merger
> Generally speaking, the person committing to WebKit is responsible for the
> content of the patch. I prefer not to think of that person as the “merger”.
> Their name should still be on the patch.
> And yes, I think it’s handy to cite the name of the author of the Blink
> patch in the change log.
> That’s along the lines of the approach I’ve been taking.
> For patches that meet both of these criteria:
> - Either trivial, or in my area of expertise.
> - Merges cleanly without much/any modification
> ...I put on my reviewer hat and pretend it’s a WebKit patch, review it and
> land it.
> Example: <http://trac.webkit.org/changeset/149734>
> For patches I’m less comfortable with, or that just need more work to fit
> into WebKit, I put on my committer hat, wrap it into a new patch, and add
> it to the review queue.
> Example: <http://trac.webkit.org/changeset/149110>
> In both cases, I credit the Blink author and provide a URL to the Blink
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev