-
Notifications
You must be signed in to change notification settings - Fork 0
Rebasing Strategy
Cameo will adopt the same process as Chromium. A DEPS file will be used to point to the right branch and revision in the Cameo downstream repo (aka fork) of Chromium (https://github.com/otcshare/chromium-cameo).
Before the first public release, chromium-cameo will always track the beta channel of Chromium. It is the responsibility of the Cameo team to update chromium-cameo to reflect the updates of the beta channel in chromium. The site http://omahaproxy.appspot.com/ is a good pointer to track the correct revisions.
The update will happen every week and every six weeks a major version will hit the beta channel which will be the time a potential rebase work will happen as we need to rebase our patches on top of Chromium.
Every DEPS major roll (the 6 weeks one) will be announced on the dev mailing list so that people will be aware of the upcoming changes. How often Cameo will be released is yet to be determined; right now we aim towards a 1.0 release.
- Branch the Cameo source code into a release branch inside the cameo repository (e.g. v1.0)
- Make sure that the DEPS file in that newly created Cameo branch stay attach to the same major version that was used in trunk and wait the beta channel used up until branching time to be promoted stable. Trunk can then move freely forward and rebase/update on a new major revision.
- Roll the QA work in that branch; bug fixing and testing.
When Cameo trunk branches for release, chromium-cameo does the same. Every week for trunk, we should: Branch current chromium-cameo trunk to a unique named branch. This new created branch will not evolve anymore, it's just for history recovery since rebase will force-update trunk. Do rebase for chromium-cameo trunk branch. Rebase it to latest upstream beta and force update chromium-cameo trunk branch. Update DEPS in cameo trunk to integrate the new rebased chromium.
A major upgrade every six weeks, and patch update for others. Chromium is versioned major.minor.build.patch
Every week for release, we should: Branch current chromium-cameo release to a unique named branch. Similar to what we need to do for trunk. Do rebase for chromium-cameo release branch. Rebase it to latest upstream branch and force update chromium-cameo release branch. (upstream branch means for example, rebase from 28.0.1500.50 to 28.0.1500.80) Update DEPS in cameo release branch to integrate the new rebased chromium.
After the branching no new features will be added in release branches, only bug fixes and security fixes will go in both in cameo and chromium-cameo. This will reduce potential regressions.
A few days after branching we will release as-is the branch as part of the beta offer even with major bugs opened so we can get early feedback.
Final releases will happen only if no major bugs are open on that given release branch.
It is the responsibility of the Cameo team and the release management to update each stable branches of chromium-cameo tracked by cameo releases so that old cameo releases receive security and bug fixes from upstream chromium.
Fixes in cameo will be landed in trunk always and backported in appropriate release branches.
Fixes in our custom patches in Chromium will always be backported in the current “trunk” (the tracked beta channel) and backported to appropriate release branches.
Bug fixes and security fixes aimed for a cameo release but inside Chromium or Blink will be landed upstream and we will wait Google to backport them in the stable channel we’re tracking.
Up until July and the first release it’s safe for the QA to focus on trunk and provide feedback about it.
When we will create the first 1.0 release branch of Cameo, QA should focus on the release branch to make sure the quality is good while doing a soft testing on trunk.
In the future ideally we want to make sure QA is focusing more on upcoming release branches.
We try to aim upstream as first. If this option is not possible then chromium-cameo is the place to land the patch. It will be carefully reviewed and will land there. We need to remember that any patch in there as a high cost of maintenance.
In really rare cases our work depends on something we landed upstream in Chromium or Blink and that is required to move forward in Cameo without paying the high cost of maintaining changes in chromium-cameo. In the meantime we will allow cameo-trunk to track another channel than beta.
This should be communicated to the mailing list and agreed with the community.
Before the first release, it will be fine to rely on two persons for updating chromium-cameo and rolling the DEPS inside cameo repository. This is a few hours work for one engineer once a week. They can alternate.
After the first release we that it will start to be a dedicated role for a person. Managing the releases branches, backporting, and roll should be done by a given person dedicated doing so.