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
-~----------~----~----~----~------~----~------~--~---
