Create add-on sdk clone for mozilla-central



Add-on SDK
5 years ago
5 years ago


(Reporter: irakli, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


Jetpack project needs it's own clone of mozilla-central with a **addon-sdk** top level directory containing git clone of [Addon-sdk repo]( `.hgignore` file should be used to make sure that git history is ignored by hg. Changes from addon-sdk repo's special **integration** branch will need to be pulled down once a week by a Jetpack team's release engineer, committed to SDK's mozilla-central clone and then merged with official mozilla-central. Changes to **integration** branch will be merged once a week from **master** using --no-ff flag to create own a merge commit. Merge from **master** to **integration** will happen day before the pull to mozilla-central.

### Reverts from mozilla central

Any change reverted from mozilla-central will also be reverted
on SDK's clone of mozilla-central. In addition associated merge commit in git will be reverted on SDK **integration** branch and merged back to **master**. This way revert will propagate back to the **master** branch. Any fixes will have to create new commits and go through the above described process to end up in the mozilla-central.
Blocks: 731779

Comment 1

5 years ago
Does this really need it's own hg repository?

More effective would be to just use mozilla-inbound, or you'll need someone to merge between mozilla-central and your repository in addition to the merges in comment 0. We'll also need to run PGO and nightlies on the new repo, which will be a bit of a waste given the merges into it will be only once a week.


5 years ago
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Ed Morley [:edmorley UTC+1] from comment #1)
> Does this really need it's own hg repository?

We just need a clone, which could live on a developer's machine, a VM or wherever. We don't need a repo on for this.


5 years ago
Priority: -- → P1
So, just to get something cleared up in my head, is this new "addon-sdk" directory truly a top-level directory as said in comment 0, or located within toolkit/ as explained here: ?
I think this bug as filed it just confusing the issue. Unless we want to request a VM to do the uplift on we can just do it on any developers machine and so we don't really need to do anything here.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.