Any reason *not* to merge mobile-browser into mozilla-central?
Chris Jones
haven't seen any arguments *against* merging. Briefly, the work would
be something like
- move current mobile-browser code into mozilla-central/mobile
- convert the current mobile-browser repository into a clone of
mozilla-central, like tracemonkey is a clone of mozilla-central, and
merge back/forth
Objections?
If not, I'll file a bug in which we can hammer out the details.
Cheers,
Chris
Matt Brubeck
Either way, I think we should create a tracking bug now, and maybe also some dependent bugs for the larger pieces of work required (automation changes, infrastructure setup, etc). With those details hammered out, we can probably have a more informed debate (if there is in fact any debate).
Mark Finkle
> I saw recently a mention of the "debate" going on over this, but I
> haven't seen any arguments *against* merging. Briefly, the work would
> be something like
> - move current mobile-browser code into mozilla-central/mobile
> - convert the current mobile-browser repository into a clone of
> mozilla-central, like tracemonkey is a clone of mozilla-central, and
> merge back/forth
I think we need to do this ASAP. Aki has been collecting reasons to
merge:
https://wiki.mozilla.org/User:Asasaki:MBMerge
Axel Hecht
I would chime in to this from a l10n and possibly releng point of view,
the kinda-special way of mobile with mobile-browser being mobile and
such, getting rid of that? Yeah, totally.
Axel
Chris Jones
Ted Mielczarek
> I saw recently a mention of the "debate" going on over this, but I haven't
> seen any arguments *against* merging. Briefly, the work would be something
> like
> - move current mobile-browser code into mozilla-central/mobile
> - convert the current mobile-browser repository into a clone of
> mozilla-central, like tracemonkey is a clone of mozilla-central, and merge
> back/forth
I think when mobile originally started the project branch model wasn't
well solidified, so what they were doing made sense at the time. In
addition, we had only recently removed mailnews from mozilla-central,
to give both sides of the equation a bit more freedom (Gecko code more
freedom to make changes without having to fixup mailnews consumers in
the process, and mailnews code freedom to continue working when Gecko
was in a code freeze). I think it's been a bit tougher for Mobile,
since they're exclusively shipping on platforms that desktop Firefox
doesn't, so they basically always need to take platform fixes that
Firefox isn't blocking on, but I think for them, integrating mobile
into m-c and working as a project branch makes sense nowadays.
-Ted
Philip Chee
> On Fri, Mar 18, 2011 at 4:34 PM, Chris Jones <cjo...@mozilla.com> wrote:
>> I saw recently a mention of the "debate" going on over this, but I haven't
>> seen any arguments *against* merging. Briefly, the work would be something
>> like
>> - move current mobile-browser code into mozilla-central/mobile
>> - convert the current mobile-browser repository into a clone of
>> mozilla-central, like tracemonkey is a clone of mozilla-central, and merge
>> back/forth
>
> I think when mobile originally started the project branch model wasn't
> well solidified, so what they were doing made sense at the time. In
> addition, we had only recently removed mailnews from mozilla-central,
"recently" as in as far back as the migration from cvs to hg circa Gecko
1.9.1? (what's the opposite of internet dog years? answers via email
please).
> to give both sides of the equation a bit more freedom (Gecko code more
> freedom to make changes without having to fixup mailnews consumers in
> the process, and mailnews code freedom to continue working when Gecko
> was in a code freeze). I think it's been a bit tougher for Mobile,
> since they're exclusively shipping on platforms that desktop Firefox
> doesn't, so they basically always need to take platform fixes that
> Firefox isn't blocking on, but I think for them, integrating mobile
> into m-c and working as a project branch makes sense nowadays.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Ted Mielczarek
>> I think when mobile originally started the project branch model wasn't
>> well solidified, so what they were doing made sense at the time. In
>> addition, we had only recently removed mailnews from mozilla-central,
>
> "recently" as in as far back as the migration from cvs to hg circa Gecko
> 1.9.1? (what's the opposite of internet dog years? answers via email
> please).
I said "had recently", meaning that when the mobile project started
(March 2008, judging by hg):
http://hg.mozilla.org/mobile-browser/rev/0
The migration to hg had only started about a year before that:
http://hg.mozilla.org/mozilla-central/rev/0
-Ted
Philip Chee
Ah, my bad. I thought the Fennec branch/repo started later than that.
Robert Kaiser
> I saw recently a mention of the "debate" going on over this, but I
> haven't seen any arguments *against* merging.
So the mobile team is OK with just accepting their release driving and
tree-closing is dictated by the wider Firefox team? If so, merging
should be alright, I guess.
(Even though it weakens all the arguments we have for having multi-repo
support in some tooling stuff, as now Thunderbird and SeaMonkey will be
left alone again with needing that.)
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Asa Dotzler
> Chris Jones schrieb:
>> I saw recently a mention of the "debate" going on over this, but I
>> haven't seen any arguments *against* merging.
>
> So the mobile team is OK with just accepting their release driving and
> tree-closing is dictated by the wider Firefox team? If so, merging
> should be alright, I guess.
> (Even though it weakens all the arguments we have for having multi-repo
> support in some tooling stuff, as now Thunderbird and SeaMonkey will be
> left alone again with needing that.)
>
> Robert Kaiser
>
I think what Robert was trying to say is that perhaps .mobile should be
left out of the merge.
- A
Asa Dotzler
Oops, ignore me. I got my threads crossed.
- A
Justin Wood (Callek)
My largest concerns are of the details, which I'll lay out here:
* merging in might lose history of mobile-repo checkins [solveable but a
pain]
* Checkins to m-c for mobile only files that are currently only stored
in mobile-browser will cause a full m-c rebuild for firefox. [solveable
with tooling changes]
* Will increase, the HD space requirement for mozilla-central.
[currently not solveable, but if hg changes ever come around, it may be;
also possibly a non-issue]
* With the current post 4.0 planning, doing this could mean that a
stable-firefox repo is a completely unstable fennec repo, and no easy
way for people who pull the repo to identify that. [solveable by denying
--enable-app for fennec, and/or removing mobile/ on the stable tree, etc.]
* What kairo said about other apps needing multi-repo-support in
tooling. [just means more work for the other apps, but I'd love if that
was still under consideration ;-) ]
Beyond that I have no objections/concerns.
--
~Justin Wood (Callek)
Aki Sasaki
> My largest concerns are of the details, which I'll lay out here:
>
> * merging in might lose history of mobile-repo checkins [solveable but a
> pain]
I believe this is solvable.
> * Checkins to m-c for mobile only files that are currently only stored
> in mobile-browser will cause a full m-c rebuild for firefox. [solveable
> with tooling changes]
Currently m-b checkins trigger all mobile builds across a number of
project branches. If we end up having a dozen or more project branches,
that's a lot of machine time and storage for mobile builds.
I don't foresee a large jump in build machine cycles / storage space if
we merge in.
> * Will increase, the HD space requirement for mozilla-central.
> [currently not solveable, but if hg changes ever come around, it may be;
> also possibly a non-issue]
as above.
> * With the current post 4.0 planning, doing this could mean that a
> stable-firefox repo is a completely unstable fennec repo, and no easy
> way for people who pull the repo to identify that. [solveable by denying
> --enable-app for fennec, and/or removing mobile/ on the stable tree, etc.]
The mobile team(s) will be able to have their own project repos that
merge in on their own schedules. We should also, if need be, create a
separate release branch for mobile should the two repos need to diverge.
This agile branching is *helped*, not hindered, by merging in.
> * What kairo said about other apps needing multi-repo-support in
> tooling. [just means more work for the other apps, but I'd love if that
> was still under consideration ;-) ]
This sounds like a valid concern, but it also sounds like a separate,
followup discussion.
Justin Wood (Callek)
> On 3/19/11 12:27 PM, Justin Wood (Callek) wrote:
>> My largest concerns are of the details, which I'll lay out here:
>>
>> in mobile-browser will cause a full m-c rebuild for firefox. [solveable
>> with tooling changes]
>
> Currently m-b checkins trigger all mobile builds across a number of
> project branches. If we end up having a dozen or more project branches,
> that's a lot of machine time and storage for mobile builds.
>
> I don't foresee a large jump in build machine cycles / storage space if
> we merge in.
Ahh I didn't realize every m-b change affected _all_ project branches,
ok -- withdrawn.
>> * Will increase, the HD space requirement for mozilla-central.
>> [currently not solveable, but if hg changes ever come around, it may be;
>> also possibly a non-issue]
>
> as above.
>
My concern here was not with our build machines, but local developer
machines. I had stored m-c and c-c on a 4G flash drive before, I fear
that may not be possible for much longer (especially if I want
_anything_ else on it, like mozilla-build, etc.)
My point about it being a non-issue is that HD storage is remarkably
cheap these days. But was still a point I wanted to make.
>> * With the current post 4.0 planning, doing this could mean that a
>> stable-firefox repo is a completely unstable fennec repo, and no easy
>> way for people who pull the repo to identify that. [solveable by denying
>> --enable-app for fennec, and/or removing mobile/ on the stable tree,
>> etc.]
>
> The mobile team(s) will be able to have their own project repos that
> merge in on their own schedules. We should also, if need be, create a
> separate release branch for mobile should the two repos need to diverge.
>
> This agile branching is *helped*, not hindered, by merging in.
My concern stemmed from those not intimately familiar with the project
and getting a copy of the repo locally. where they would think that
checking out/downloading Firefox code and seeing mobile/ code as part of
it, would suddenly mean they could build a useful mobile with whatever
changes they wanted to make. This will probably not be the case.
But it might also be a point we don't really care about in practice.
>> * What kairo said about other apps needing multi-repo-support in
>> tooling. [just means more work for the other apps, but I'd love if that
>> was still under consideration ;-) ]
>
> This sounds like a valid concern, but it also sounds like a separate,
> followup discussion.
Sure, I don't mind treating this as a discussion when it rouses its ugly
head, and/or after Firefox 4 is out the door. And shouldn't be the sole
block of moving Fennec to mozilla-central.
--
~Justin Wood (Callek)
Mark Finkle
> So the mobile team is OK with just accepting their release driving and
> tree-closing is dictated by the wider Firefox team? If so, merging
> should be alright, I guess.
The mobile team already has to deal with Firefox tree closings. All of
the mobile platform work still happens in m-c, so m-c closures affect
mobile. The /mobile code would now be affected by tree closures, but
otherwise would be NPOTB.
We have also discussed using a project branch for active development,
like trace-monkey, which would leave mobile unaffected by m-c closures
- for the most part. No decision has been made on the separate project
- still discussing it.
Axel Hecht
problem for contributors without great network connection. Disk may be
cheep, but bandwidth is still expensive around the globe, and choppy. So
cloning is a pain, or for some folks, just a straight blocker. Hit at
least a few localizers so far.
Axel
Jeff Muizelaar
On 21-Mar-11, at 8:38 AM, Axel Hecht wrote:
> Regarding the size of mozilla-central, that becomes more and more of
> a problem for contributors without great network connection. Disk
> may be cheep, but bandwidth is still expensive around the globe, and
> choppy. So cloning is a pain, or for some folks, just a straight
> blocker. Hit at least a few localizers so far.
The mobile repository isn't that big (10MB) so it should hurt too
much. Also, perhaps localizers could use a shallow clone of a git
mirror like (https://github.com/doublec/mozilla-central)?
-Jeff
Robert Kaiser
I mostly meant this in the light of the mobile code being merged up to
-dev, -beta, -release or in older terms, "cut for a release" at those
times that fit Firefox development. Is the mobile team OK with being
bound to those decisions? If yes, then there's no problem, of course. :)
Christian Legnitto
On Mar 21, 2011, at 8:30 AM, Robert Kaiser <ka...@kairo.at> wrote:
> Mark Finkle schrieb:
>> On Mar 19, 2:29 pm, Robert Kaiser<ka...@kairo.at> wrote:
>>
>>> So the mobile team is OK with just accepting their release driving and
>>> tree-closing is dictated by the wider Firefox team? If so, merging
>>> should be alright, I guess.
>>
>> The mobile team already has to deal with Firefox tree closings. All of
>> the mobile platform work still happens in m-c, so m-c closures affect
>> mobile. The /mobile code would now be affected by tree closures, but
>> otherwise would be NPOTB.
>>
>> We have also discussed using a project branch for active development,
>> like trace-monkey, which would leave mobile unaffected by m-c closures
>> - for the most part. No decision has been made on the separate project
>> - still discussing it.
>
> I mostly meant this in the light of the mobile code being merged up to -dev, -beta, -release or in older terms, "cut for a release" at those times that fit Firefox development. Is the mobile team OK with being bound to those decisions? If yes, then there's no problem, of course. :)
There is nothing preventing mobile from having their own shadow copies of experimental/beta/release if they need to ship on a different schedule or have different product tradeoffs. Details and options TBD.
Chris AtLee
We also generate hg bundles of mozilla-central every week, that can be
downloaded via your favourite http client of choice.
http://ftp.mozilla.org/pub/mozilla.org/firefox/bundles/
It's a good way to bootstrap yourself if you don't want to clone the
entire repo from scratch.
Cheers,
Chris
Robert Kaiser
> There is nothing preventing mobile from having their own shadow copies of experimental/beta/release if they need to ship on a different schedule or have different product tradeoffs. Details and options TBD.
If that doesn't split resources and/or cause merge concerns too much,
that also sounds like a good way.
Axel Hecht
That's only mozilla-central so far, right? Are there plans to get the
release repos up there, too?
Axel
Chris AtLee
Not that I know of. File a bug? I think it's easy to flip on on our side.