The default bug view has changed. See this FAQ.

Landed in Firefox - proof of concept

RESOLVED FIXED

Status

Add-on SDK
General
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: canuckistani, Assigned: mossop)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

In order to evaluate and also socialize the impact of landing the SDK's apis in Firefox, we should do the following:

* land the apis in a branch based on m-c, either in github or hg
* create a try build incorporating these changes
* craft a version of the sdk that is capable of packaging an add-on that assumes the apis have landed in Firefox
* TEST TEST TEST existing add-ons to see if they work

Aside: we'll need to do this for builder as well.

Updated

4 years ago
OS: Mac OS X → All
Hardware: x86 → All
I just forked the git mirror of mozilla-central, if that'll be of any use: https://github.com/KWierso/releases-mozilla-central
(In reply to Wes Kocher (:KWierso) from comment #1)
> I just forked the git mirror of mozilla-central, if that'll be of any use:
> https://github.com/KWierso/releases-mozilla-central

Or do we want to try to grab one of the disposable branches for this?
Wes: Whatever is easiest, really! Can you drive this?
(In reply to Jeff Griffiths (:canuckistani) from comment #3)
> Wes: Whatever is easiest, really! Can you drive this?

I can certainly try!

From my understanding, having not really looked too much into it:
1. Using the Github fork would be easy, we should be able to add all relevant people to the committers list, or maybe we could get a branch set up on Mozilla's canonical github mirror. We wouldn't get any easy build infrastructure, but we could build locally with our own local clones of the repo.

2. If we just have someone (me, I guess, though Irakli'd be a good candidate too, since he's got all the plans for landing in Firefox) using a local checkout of mozilla-central-or-inbound as the integration point, we could push our changes to try and get the try builds for all desired platforms, but then all of the relevant changes would be on only that developer's computer (and whatever patches get posted to bugzilla), which isn't as easy for others to contribute to.

3. Getting one of the disposable branches to this work would be ideal, though it looks like all of them are currently in use.[1] Larch and Cedar are opening up soon, it seems, and we could probably get Pine if we ask nicely enough. This would give us a central point to commit things to, and I believe we can turn on automated builds upon each push to the branch, along with Nightly builds. Not sure how easy it would be to push our changes from that branch to Try; I thought I read somewhere that it can be a pain once you diverge too far from what's on mozilla-central. This requires level 2 commit access for anyone trying to commit, so we'd need to make sure everyone who needs it gets it.


[1]: https://wiki.mozilla.org/DisposableProjectBranches#BOOKING_SCHEDULE


(Ccing a few other people who should probably have a say in which way we go.)

I'd personally vote for 3, since it has the easy build infrastructure that 1 is lacking, and has more accessibility than 2.
Flags: needinfo?

Updated

4 years ago
Assignee: nobody → kwierso
(Assignee)

Comment 5

4 years ago
(In reply to Wes Kocher (:KWierso) from comment #4)
> I'd personally vote for 3, since it has the easy build infrastructure that 1
> is lacking, and has more accessibility than 2.

Yes, absolutely 3 as it is as close as we get to what landing in m-c will look like. If it is too long out to get a disposable branch we can request releng to spin up a new one.
Flags: needinfo?
(In reply to Dave Townsend (:Mossop) from comment #5)
> (In reply to Wes Kocher (:KWierso) from comment #4)
> > I'd personally vote for 3, since it has the easy build infrastructure that 1
> > is lacking, and has more accessibility than 2.
> 
> Yes, absolutely 3 as it is as close as we get to what landing in m-c will
> look like. If it is too long out to get a disposable branch we can request
> releng to spin up a new one.

I added us as next in line for Larch, as gps said his work there could wrap up as early as the end of this week (while officially ending on Dec 1). If they do finish up this week, we can get Larch wiped clean for us on Monday or Tuesday of  next week, and people should be able to start working there as soon as that happens. 
(If they don't finish this week, I'll be on PTO starting Nov 21 through the end of the month, so we could either wait for me to return or someone else can get Larch set up for us.)

Updated

4 years ago
Priority: -- → P1
Excellent :D
(Assignee)

Updated

4 years ago
Depends on: 814121
So, the Larch branch is ours now, and has a current copy of mozilla-central's code in it.
(Assignee)

Comment 9

4 years ago
To spare Wes from learning Makefile syntax I'm going to do the initial Makefile wrangling
Assignee: kwierso → dtownsend+bugmail

Updated

4 years ago
Blocks: 793925
Blocks: 793932
Dave, what's the status here?
Flags: needinfo?(dtownsend+bugmail)
(Assignee)

Comment 11

4 years ago
The status is that we have larch building Firefox including the APIs, we need Irakli (or someone) to confirm thatthey are usable. We should probably have a meeting to figure out the status and next steps of this project.
Flags: needinfo?(dtownsend+bugmail)
Based on that, I'm in favor of closing this bug as I think we've accomplished what I wanted to get out of it.

Dave: can you update with the locations of these builds for posterity and close this out?
(Assignee)

Comment 13

4 years ago
The builds are in f.e. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/larch-linux/.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
For OS X:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/larch-macosx64/

For Win32:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/larch-win32/
You need to log in before you can comment on or make changes to this bug.