http://sites.google.com/a/chromium.org/dev/developers/webkit-changes
:DG<
On Fri, Jan 9, 2009 at 11:15 AM, Dimitri Glazkov <dglaz...@google.com> wrote:
> Dear People of Chromium,
>
> I've been thinking about the process of making changes to WebKit code
> in a logical and consistent fashion (note, that doesn't necessarily
> preclude "sane").
>
> Until we've switched to the integration model, we are still in a
> vendor branch state and thus the process of tweaking WebKit code is
> not what you call a "that-was-easy" effort. Nevertheless, we must have
> a somewhat trivialized way of doing it.
>
> Here's what I've come up so far:
>
> A. If the change is to common code (WebCore proper,
> JavaScriptCore/wtf), make it upstream -- it will be picked up by our
> daily merges.
>
> B. If the change is to our port (platform/graphics/skia|chromium,
> etc.), you can do the following:
>
> 1) make the change downstream and make sure it doesn't break anything
> 2) submit the change upstream and get it reviewed/committed
> 3) reconcile any deltas that may have occurred during review process
> -- the merge custodian will thank you.
>
> The basic difference is making sure that the changes to our port work
> before they go upstream. It would certainly be more frustrating to
> wait for the daily merge to pick up your tweaks and find out that they
> were wrong.
>
> However, let's try to avoid situations where the change is stuck in
> WebKit review limbo or abandoned, leaving forked files in our vendor
> branch. I am not sure whether we need any special rules for these,
> aside from the occasional stark glare from the merge people.
>
> What do you think? Good rules, bad rules? Comments? Questions? Quirky
> and entertaining remarks?
>
> :DG<
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
