I should have said "forking gecko-dev is indeed a possibility." And
whether or not we can use Ehsan's script there presumably depends on
whether it works on git or hg.
Dan
On 2/27/14, 8:23 PM, Dan Mosedale wrote:
To be clear, this whole thing is very much an interim proposal, where
at least some of the pieces are almost certain to change. I.e.
there's no proposal for a long-term fork on the table here.
The idea of landing the Firefox stuff directly in comm-central was a
starting point earlier in the week. However, based on a couple of
conversations, and some of my gut feelings having watched
module-ownership stuff happen for quite a while, Maire, Adam, and I
came to the conclusion that mid-next-week for landing anything stuff
in mozilla-central was a best-case, and it's unpredictable enough that
it might be significantly longer that. So we wanted something that would
allow everyone to collaborate on code ASAP while not being too hard to
uplift. Any of myself, Adam, or Maire can give you even more context
here, if you wish.
W.r.t. to the hg stuff, I think the number of people likely to be
touching that stuff is very tiny (i.e. I can imagine Mark and me
working on it, not sure if anyone else is likely to sign up for
touching gecko build and test integration bits), and it's intended to
be short-lived, as above.
Cloning gecko-dev is indeed a possibility, and the auto-merge script
Ehsan suggests would make that easier than I realized. I've updated
the Etherpad to make that clear. Given its giant size, it would make
inclusion of the standalone client code into loop-server via submodule
awkward for people having to pull that repo (and possibly any Heroku
deployment as well).
Dan
On 2/27/14, 2:18 PM, Eric Rescorla wrote:
Comments below:
1. WRT to the client code, why not simply git clone gecko-dev and
make a branch? Git is good for this stuff.
2. I don't think we want a fork as a long-term prospect. Just for the
next week or so while we work out the right thing.
3. I very much do not want to use a versioned hg series. That's very
git-unfriendly. I would prefer not to have a branch. Let's solve the
logistical problem and land right on m-c.
-Ekr
On Thu, Feb 27, 2014 at 8:54 PM, Dan Mosedale <[email protected]
<mailto:[email protected]>> wrote:
Loop already has a server in github, which is off to a fine
start. Figuring out how to structure our code for mozilla-central
has turned out to be a bit complex. In order to remove that as a
roadblock from more of the MLP technical work, and get the
technical work moving faster ASAP, here's a proposal for where to
put the various pieces of Loop work in the interim now as the
rest gets sorted out.
At the very least, we need to find an interim home for the
browser-side front-end and the standalone conversation window
before Sunday, when a number of folks will be working on standing
stuff up in London.
Here's the proposal, on which I'd love feedback:
https://webrtc.etherpad.mozilla.org/loop-temp-process
If I don't hear significant objections by the end of business
tomorrow (Friday, Pacific time), I'll go ahead with creating the
loop-client repo as proposed in the Etherpad.
I expect that it'll take a day or two next week before we can
nail the rest, in part because I very much want Standard8's input
there, and he's out of the office today.
Thanks,
Dan
_______________________________________________
dev-media mailing list
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
