Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Proposal: Move Thunderbird and SeaMonkey to mozilla-central

385 views
Skip to first unread message

Mark Banner

unread,
Apr 3, 2014, 6:13:00 AM4/3/14
to
[follow-ups to mozilla.dev.planning]

tl;dr We're proposing to move Thunderbird and SeaMonkey into
mozilla-central to reduce maintenance complexities for build systems,
and for releng. Multiple-app handling in the same repository has
improved greatly, and the general rules would remain the same.

Feedback and discussion is most welcome - we have generally discussed
this within some individuals, but not widely.


Proposal
--------

We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
of comm-central) into mozilla-central.

Schedule:

We're looking to complete this in the Gecko 31 cycle, as then we'd be
able to pick it up in the next ESR cycle.

We already have this in preview mode running on the Alder twig.

Reasons:

There are several primary pain points that make things more complicated
for Thunderbird development, and its support for releases from releng.
The overarching reason is that this merge would reduce the amount of
work required to keep Thunderbird building to support security releases
and community development, and allow more focus on other areas.

They reasons we'd like to do this are:

- Requiring that comm-central pulls mozilla-central duplicates the build
system in weird and wonderful ways.

Maintaining the duplicate build system obviously duplicates much of the
work that is already being done in mozilla-central.

- Additionally, it would simplify pieces of m-c build config logic which
are accommodating c-c.


- Due to pulling different repositories, the workarounds for releng are
complex. It requires an almost totally-separate project configuration,
and when build configurations change, these must be manually ported to
the Thunderbird project configuration.

With a similar configuration to Firefox, we could base on the same
configuration with only a few changes to project name, and specific
files etc.


- Additionally, some benefits from search&replace patches are lost as
the code is in a separate repository.

Impacts
-------

History:

The merge will include the full c-c history.

Rules:

We'd obviously keep the same rules - changes that break
Thunderbird/SeaMonkey are not required to be fixed by the Gecko change
that breaks them.

We may relax some of the existing comm-central rules, e.g. Gecko build
system review could apply to the Thunderbird parts for search & replace
patches, rather than requesting separate reviews. Obviously, we'd
confirm with the appropriate areas before this happens.

Build:

Now that bug 787449 [1] is fixed, we can easily exclude
Thunderbird/SeaMonkey pushes from triggering gecko builds.

Tree:

We envision that the existing Thunderbird-Trunk would be kept separate
to the Mozilla-Central one, however, we could consider merging these at
a later date if it makes sense.

Directories:

The additional directories would currently be approximately:

mozilla-central/mail
mozilla-central/mailnews
mozilla-central/calendar
mozilla-central/chat
mozilla-central/im
mozilla-central/suite
mozilla-central/editor/ui
mozilla-central/db/mork
mozilla-central/other-licenses/branding/thunderbird
mozilla-central/ldap (also statically importing the ldap c-sdk).

However, we would be willing to restructure/group those if they are too
much/complex.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=787449

Ed Morley

unread,
Apr 3, 2014, 6:36:29 AM4/3/14
to Mark Banner, dev-pl...@lists.mozilla.org
On 3 April 2014 11:13:00 BST, Mark Banner <mba...@mozilla.com> wrote:
>The merge will include the full c-c history.

What increase will this mean for the size of the gzipped mozilla-central hg bundle and time for a fresh hg pull of mozilla-central? Will you be using hg convert with a filemap (vs hg remove) to avoid adding the history of other parts of c-c to mozilla-central's hg store? (Just thinking of new contributors who have limited bandwidth)

That said, think it will make it a lot easier for tree-wide changes to not break Thunderbird/SeaMonkey, so I see there are potential wins here :-)

Cheers,

Ed

Benjamin Smedberg

unread,
Apr 3, 2014, 9:07:50 AM4/3/14
to Mark Banner, mozilla.dev.planning group
On 4/3/2014 6:13 AM, Mark Banner wrote:
>
> Proposal
> --------
>
> We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
> of comm-central) into mozilla-central.

I oppose this plan.

I think it's fine to reconsider the decision we made in 2008 not to
include tbird/seamonkey in mozilla-central, but I don't think the
arguments here are compelling or that the benefits are worth the costs.

Reason #1: confusion about what code belongs to what projects

Currently when hacking on Firefox, it's roughly clear that all the code
in mozilla-central belongs to Firefox in some way, and we have been
effectively removing most of the code that isn't part of Firefox. When
searching through the codebase (either locally or using the online dools
like DXR/MXR) the addition of code which belongs to different products
will significantly harm developer understanding.

Reason #2: Pull/tree size

There is a non-trivial amount of code involved in this change. In terms
of both downloading the source repo as well as the size of a local
checkout, I don't think we should include unnecessary code in the
Firefox tree.

Reason #3: It's unnecessary

It is not necessary to alter mozilla-central to put all of Thunderbird
in one repository. You can do the merge you are proposing, but keep it
as a separate Thunderbird tree and regularly merge changes from
mozilla-central into your combined tree.

--BDS

Henri Sivonen

unread,
Apr 3, 2014, 9:28:24 AM4/3/14
to Benjamin Smedberg, Mark Banner, mozilla.dev.planning group
On Thu, Apr 3, 2014 at 4:07 PM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the code in
> mozilla-central belongs to Firefox in some way, and we have been effectively
> removing most of the code that isn't part of Firefox. When searching through
> the codebase (either locally or using the online dools like DXR/MXR) the
> addition of code which belongs to different products will significantly harm
> developer understanding.

I agree that the confusion about what code belongs to Firefox is a
problem and merging c-c into m-c *could* make the confusion worse.
However:
1) the current situation is worse than what you wrote suggests. Way
too often, I encounter pre-Firefox-era legacy cruft in m-c that
appears to be dead code but turns out to be in use by c-c.
2) the confusion could be addressed by requiring
Thunderbird/SeaMonkey-only code to live in a certain directory (or a
small set of directiories).
3) due to issue #1, searches for code deadness need to be done on c-c
MXR anyway.

(On that topic: I'm still looking for a volunteer for
https://bugzilla.mozilla.org/show_bug.cgi?id=937056 . At some point I
will have whined about this so much that it would have been more
efficient to just do the move myself even though I'm not supposed to
use time for Thunderbird development...)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

Bobby Holley

unread,
Apr 3, 2014, 9:28:04 AM4/3/14
to Benjamin Smedberg, Mark Banner, mozilla.dev.planning group
On Thu, Apr 3, 2014 at 10:07 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> On 4/3/2014 6:13 AM, Mark Banner wrote:
>
>>
>> Proposal
>> --------
>>
>> We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
>> of comm-central) into mozilla-central.
>>
>
> I oppose this plan.
>

I strongly second benjamin's points.

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 9:41:01 AM4/3/14
to
On 4/3/2014 5:36 AM, Ed Morley wrote:
> On 3 April 2014 11:13:00 BST, Mark Banner <mba...@mozilla.com> wrote:
>> The merge will include the full c-c history.
> What increase will this mean for the size of the gzipped mozilla-central hg bundle and time for a fresh hg pull of mozilla-central? Will you be using hg convert with a filemap (vs hg remove) to avoid adding the history of other parts of c-c to mozilla-central's hg store? (Just thinking of new contributors who have limited bandwidth)

A full hg bundle of mozilla-central is 637MB. That of the new repository
would be 692MB. In general, comm-central is roughly 10% the size of
mozilla-central at present in terms of both history and file contents. I
believe this extra size would be roughly equivalent to the size of
mozilla-central a year from now if comm-central were not merged, but my
repository growth curves are hazy.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 10:01:44 AM4/3/14
to
On 4/3/2014 8:07 AM, Benjamin Smedberg wrote:
> On 4/3/2014 6:13 AM, Mark Banner wrote:
>>
>> Proposal
>> --------
>>
>> We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
>> of comm-central) into mozilla-central.
>
> I oppose this plan.
>
> I think it's fine to reconsider the decision we made in 2008 not to
> include tbird/seamonkey in mozilla-central, but I don't think the
> arguments here are compelling or that the benefits are worth the costs.
>
> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the
> code in mozilla-central belongs to Firefox in some way, and we have
> been effectively removing most of the code that isn't part of Firefox.
> When searching through the codebase (either locally or using the
> online dools like DXR/MXR) the addition of code which belongs to
> different products will significantly harm developer understanding.

It's not technically challenging to move all of the newly-added code to
a comm/ subdirectory instead of doing a flat import. That would
centralize most of the obviously-not-in-Firefox code into one directory.

That said, to reiterate Henri's point, there is a surprising amount of
code in mozilla-central that doesn't end up being used in Firefox.
Having filed several bugs for mozilla-central test failures found only
in comm-central, there are definitely cases where the failure is "oh, we
don't use <insert toolkit component here> in Firefox" (a recent example
is the toolkit's downloader). There are also cases where there is
dynamically-dead code in Firefox that is not dynamically dead in
Thunderbird: I think for a time, Thunderbird was the only one using
certain legacy HTML parser APIs.
>
> Reason #2: Pull/tree size
>
> There is a non-trivial amount of code involved in this change. In
> terms of both downloading the source repo as well as the size of a
> local checkout, I don't think we should include unnecessary code in
> the Firefox tree.

As I mentioned earlier, the size is roughly 50-60MB of extra data in the
bundle. The on-disk is 67MB not including the .hg directory and ~200MB
including the .hg directory. All of these numbers are about 10% or less
of the current mozilla-central size (637MB, 922MB, 2.5GB, respectively).
The tree with comm-central included would be roughly the same size as
the tree without comm-central a year from now, based on my prior
recollections of repository growth curves.
>
> Reason #3: It's unnecessary
>
> It is not necessary to alter mozilla-central to put all of Thunderbird
> in one repository. You can do the merge you are proposing, but keep it
> as a separate Thunderbird tree and regularly merge changes from
> mozilla-central into your combined tree.

That works much less well than you'd expect. In such a repository, it is
impossible to merge changes from comm-central back into mozilla-central
without introducing c-c's history or rather complicated changeset
manipulation. It also produces a comm-central repository that has the
illusion of atomic changesets: there is no way to make a commit that
does an across-both-trees change such as the atomic refcounting changes
or gps's DIRS introduction.

clo...@gmail.com

unread,
Apr 3, 2014, 10:31:55 AM4/3/14
to
On Thursday, April 3, 2014 6:13:00 AM UTC-4, Mark Banner wrote:
> [follow-ups to mozilla.dev.planning]
>
> tl;dr We're proposing to move Thunderbird and SeaMonkey into
> mozilla-central to reduce maintenance complexities for build systems,
> and for releng. Multiple-app handling in the same repository has
> improved greatly, and the general rules would remain the same.

This sounds great!

This will make it significantly easier to get new Thunderbird contributors set up and hopefully reduce some of the build bustages TB currently suffers. (And also save me a few GB on my hard drive...which is a nice plus.)

Can't wait to put up patches that touch both toolkit and TB things without having to do separate patches and ensuring they land in the right order!

Thanks for working on this Joshua and Mark!

--Patrick

Mark Banner

unread,
Apr 3, 2014, 11:15:46 AM4/3/14
to
On 03/04/2014 14:07, Benjamin Smedberg wrote:
> I think it's fine to reconsider the decision we made in 2008 not to
> include tbird/seamonkey in mozilla-central, but I don't think the
> arguments here are compelling or that the benefits are worth the costs.

I probably wasn't explicit, but I think the main benefits of this
proposal are going to be to the Thunderbird/SeaMonkey communities. I can
understand that this isn't so compelling to Firefox developers. So let
me explain a bit more:

Ever since we separated the repositories, we have spent significant
amounts of time porting build configuration patches, fire-fighting
bustage when something lands in m-c and needs porting to c-c (including
sometimes regression range finding & bisecting). Obviously fire-fighting
is a larger pain as it distracts us from whatever we were working on.

Although with recent improvements we've now vastly reduced build
configuration porting time, the fire-fighting aspects still take up
large amounts of time which we could spend elsewhere - especially if we
were able to take benefits of search & replace/repository-wide updates
(where developers are willing to include us because we're in the same
repo rather than a separate one). It wouldn't reduce everything, but it
would likely mean we could be down to a bustage every now and again.

> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the code
> in mozilla-central belongs to Firefox in some way, and we have been
> effectively removing most of the code that isn't part of Firefox. When
> searching through the codebase (either locally or using the online dools
> like DXR/MXR) the addition of code which belongs to different products
> will significantly harm developer understanding.

I don't see this being a big issue. We've dealt with this for
comm-central ever since 2008, and its easy to see where code lies in
suite/ mail/ or mozilla/browser and realise it is specific to that product.

If we need to put everything under comm/ as Joshua suggests (or some
other directory), that would be fine by me. Generally it feels like the
significant cost here would be first-time users, who we could educate by
means of adequate documentation.

> Reason #3: It's unnecessary
>
> It is not necessary to alter mozilla-central to put all of Thunderbird
> in one repository. You can do the merge you are proposing, but keep it
> as a separate Thunderbird tree and regularly merge changes from
> mozilla-central into your combined tree.

One thing I think this does mean is increased storage size for hmo. We'd
effectively be doubling up the m-* repositories. With IT/releng
currently concerned about the size, that probably isn't good. There may
be resolution on the way, so this might become mute.

It also doubles the repository sizes for developers who do want to work
on FF and/or TB/SM. There may not be many of them, but there are a few -
admittedly I don't know for how many disk/download size is an issue.

Mark.

Nick Alexander

unread,
Apr 3, 2014, 11:20:45 AM4/3/14
to dev-pl...@lists.mozilla.org
On 2014-04-03, 6:07 AM, Benjamin Smedberg wrote:
> On 4/3/2014 6:13 AM, Mark Banner wrote:
>>
>> Proposal
>> --------
>>
>> We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
>> of comm-central) into mozilla-central.
>
> I oppose this plan.
>
> I think it's fine to reconsider the decision we made in 2008 not to
> include tbird/seamonkey in mozilla-central, but I don't think the
> arguments here are compelling or that the benefits are worth the costs.
>
> Reason #1: confusion about what code belongs to what projects
>
> Reason #2: Pull/tree size
>
> Reason #3: It's unnecessary

I'd like to add that there exist other apps built on top of Gecko, and
in future there will be more, and that merging every such app into m-c
is not feasible.

I recognize that Thunderbird and SeaMonkey are special, for technical
and historical reasons, but this sets a bad precedent.

Nick

Ben Hearsum

unread,
Apr 3, 2014, 11:22:11 AM4/3/14
to
On 04/03/14 11:15 AM, Mark Banner wrote:
> Ever since we separated the repositories, we have spent significant
> amounts of time porting build configuration patches, fire-fighting
> bustage when something lands in m-c and needs porting to c-c (including
> sometimes regression range finding & bisecting). Obviously fire-fighting
> is a larger pain as it distracts us from whatever we were working on.

Perhaps we should move Firefox/B2G/Android to another repo instead, then
we'd all be living in the same world.

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 11:53:46 AM4/3/14
to
On 4/3/2014 10:20 AM, Nick Alexander wrote:
> I'd like to add that there exist other apps built on top of Gecko, and
> in future there will be more, and that merging every such app into m-c
> is not feasible.
>
> I recognize that Thunderbird and SeaMonkey are special, for technical
> and historical reasons, but this sets a bad precedent.

I don't think this sets a precedent. If anything, the precedent was set
on April 6, 2011 when the Fennec repository was merged with
mozilla-central. As I recall, the main argument for merging those two
repositories together amounted to a complaint that having the source
code for a product be in two different repositories was too difficult to
maintain. Comm-central is closer in scope to the former mobile-browser
repository than other, external projects in that Mozilla has maintained
comm-central itself and continuing support for comm-central has been a
goal for several classes of mozilla-central developers, particularly for
the build system, although other parts of the codebase have been
influenced by comm-central needs (legacy HTML parser APIs and charset
support comes to mind).

The factors that have compelled us to propose this merge are not
generally applicable to most products that use Gecko.

Nick Alexander

unread,
Apr 3, 2014, 12:21:29 PM4/3/14
to dev-pl...@lists.mozilla.org
On 2014-04-03, 8:53 AM, Joshua Cranmer 🐧 wrote:
> On 4/3/2014 10:20 AM, Nick Alexander wrote:
>> I'd like to add that there exist other apps built on top of Gecko, and
>> in future there will be more, and that merging every such app into m-c
>> is not feasible.
>>
>> I recognize that Thunderbird and SeaMonkey are special, for technical
>> and historical reasons, but this sets a bad precedent.
>
> I don't think this sets a precedent. If anything, the precedent was set
> on April 6, 2011 when the Fennec repository was merged with
> mozilla-central.

I didn't know that Fennec was once separate, so thanks for the history
lesson!

As I recall, the main argument for merging those two
> repositories together amounted to a complaint that having the source
> code for a product be in two different repositories was too difficult to
> maintain. Comm-central is closer in scope to the former mobile-browser
> repository than other, external projects in that Mozilla has maintained
> comm-central itself and continuing support for comm-central has been a
> goal for several classes of mozilla-central developers, particularly for
> the build system, although other parts of the codebase have been
> influenced by comm-central needs (legacy HTML parser APIs and charset
> support comes to mind).

Agreed. Part of my motivation for not tying a product (Fennec,
Thunderbird, SeaMonkey) directly to m-c is that the Fennec team is now
trying to extract a core library for other consumers to embed Fennec.
If Fennec had been maintained as a separate repository, that would have
happened naturally. (At a huge cost in development time and pain. I'm
not saying the decision was incorrect; I didn't even know about it until
minutes ago.)

> The factors that have compelled us to propose this merge are not
> generally applicable to most products that use Gecko.

Can you elaborate on this point? I'd like to understand this difference
more fully.

Thanks,
Nick

Justin Dolske

unread,
Apr 3, 2014, 1:01:23 PM4/3/14
to
On 4/3/14 3:13 AM, Mark Banner wrote:

> tl;dr We're proposing to move Thunderbird and SeaMonkey into
> mozilla-central to reduce maintenance complexities for build systems,
> and for releng.

Well, let me stir the pot _and_ ask about the elephant in the room -- if
SeaMonkey and Thunderbird are a burden on releng, why is Mozilla
continuing to support them? Other community forks of Firefox (Tor
Browser, PaleMoon, WaterFox, etc) successfully exist entirely
independently of Mozilla. SM and TB have both had a long time to succeed
on their own terms as community projects, and it's not clear to me that
either are significantly contributing to Mozilla's mission.

Even Mozilla's core products (Firefox for desktop and Android) are in
resource contention with Firefox OS, so I think it's a fair question to
consider these days.

FWIW, I'd also note that Firefox OS is spread across multiple repos. Or
is there a proposal to merge FFOS into m-c as well?

Justin

Mark Banner

unread,
Apr 3, 2014, 1:14:44 PM4/3/14
to
On 03/04/2014 18:01, Justin Dolske wrote:
> On 4/3/14 3:13 AM, Mark Banner wrote:
>
>> tl;dr We're proposing to move Thunderbird and SeaMonkey into
>> mozilla-central to reduce maintenance complexities for build systems,
>> and for releng.
>
> Well, let me stir the pot _and_ ask about the elephant in the room -- if
> SeaMonkey and Thunderbird are a burden on releng, why is Mozilla
> continuing to support them?

So to clarify, SeaMonkey is not any burden on releng. They have their
own systems maintained by their own members (although as a side note,
they have trouble keeping up with releng).

> Other community forks of Firefox (Tor
> Browser, PaleMoon, WaterFox, etc) successfully exist entirely
> independently of Mozilla. SM and TB have both had a long time to succeed
> on their own terms as community projects, and it's not clear to me that
> either are significantly contributing to Mozilla's mission.

When Mozilla stopped actively developing Thunderbird, it was agreed with
the community that Mozilla Corp would put in resources to maintain
security and stability releases.

IMO the burden has been a small fraction of the work that releng does,
though I can't give you any figures. I know there is some additional
complexity in the releng systems that have to cope with the special
cases of split repos for c-c.

> FWIW, I'd also note that Firefox OS is spread across multiple repos. Or
> is there a proposal to merge FFOS into m-c as well?

I don't know much about how FFOS is built, but I believe it is
significantly different - it has the core libraries, aka gecko, plus a
lot of applications around the outside. That's effectively two build
processes - one for the core gecko build, one for the applications. IMO
that's easier to deal with in a multiple repo setup.

For Thunderbird, we are building gecko directly into the app - just like
Firefox - so this is one build step rather than two.

Mark.

Kyle Huey

unread,
Apr 3, 2014, 1:23:36 PM4/3/14
to Ben Hearsum, dev. planning
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

The difference is that desktop/Android/B2G are products that are
important enough to our priorities to invest anywhere from dozens to
hundreds of full time engineering staff in. Thunderbird and Seamonkey
are not.

- Kyle

Philipp Kewisch

unread,
Apr 3, 2014, 4:49:40 PM4/3/14
to
On 4/3/14, 3:07 PM, Benjamin Smedberg wrote:
> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the code
> in mozilla-central belongs to Firefox in some way, and we have been
> effectively removing most of the code that isn't part of Firefox. When
> searching through the codebase (either locally or using the online dools
> like DXR/MXR) the addition of code which belongs to different products
> will significantly harm developer understanding.

I really think this is not always clear, or lets say its much too easy
to forget. While Firefox/Android/B2G is in the focus, its easy to forget
that the Mozilla Platform should be independent of the concept of a
browser. If you search for things like gBrowser, selectedTab, or
chrome://browser in directories like toolkit/ there are always a small
number of hits outside of tests.

Now importing c-c into m-c won't fix this, but it does make an argument
for separating Firefox/Android/B2G from the Mozilla Platform. For the
same reasons its troublesome for Thunderbird to be separate from m-c, I
don't think it would be smart for Firefox to be separate of it.

On the other hand, importing c-c into m-c helps to make
Firefox/Android/B2G developers more aware of this separation: doing an
mxr search for something in toolkit that is also used in Thunderbird
will passively let the developer know, that the component he is changing
is not only used in a browser environment and should be modified in a
way that is compatible to other consumers of the Mozilla Platform.

For mxr searches it would be nice if they could be ordered in a
different way though: browser products - comm products - platform
directories. I don't see a sensible way of doing this though. We could
give the comm/ folder a name that starts with a later letter of the
alphabet, but thats a bit fickle.

Philipp

Philipp Kewisch

unread,
Apr 3, 2014, 5:07:06 PM4/3/14
to
On 4/3/14, 7:01 PM, Justin Dolske wrote:
> FWIW, I'd also note that Firefox OS is spread across multiple repos. Or
> is there a proposal to merge FFOS into m-c as well?

IIRC then Firefox OS is split into quite a few repositories, containing
various aspects from apps to user space libraries and kernels. Pulling
everyting for a Geeksphone Peak device was well over 12GB, with about
18GB of compiled data.

Indeed, not all of this should be dumped into m-c, but if the
multi-repository model works for B2G, wouldn't it be consequent to do
the same for Firefox and Android? If I just want to hack on B2G, why do
I need all of Firefox Desktop?

It looks to me that the multi-repository system that B2G uses does not
make it trivial to create nightly builds for different devices from a
releng standpoint, on the other hand this might just be a partnering issue.

What I am saying, if the multi-repository system works out great for
B2G, then maybe this concept should be extended so it works the same for
Firefox Desktop and for that matter also Thunderbird. On the other hand,
the downsides mentioned in other messages still apply and would then
also apply to Firefox Desktop.

Philipp

Justin Wood (Callek)

unread,
Apr 3, 2014, 5:09:52 PM4/3/14
to
On 4/3/2014 1:01 PM, Justin Dolske wrote:
> On 4/3/14 3:13 AM, Mark Banner wrote:
>
>> tl;dr We're proposing to move Thunderbird and SeaMonkey into
>> mozilla-central to reduce maintenance complexities for build systems,
>> and for releng.
>
> Well, let me stir the pot _and_ ask about the elephant in the room -- if
> SeaMonkey and Thunderbird are a burden on releng, why is Mozilla
> continuing to support them? Other community forks of Firefox (Tor
> Browser, PaleMoon, WaterFox, etc) successfully exist entirely
> independently of Mozilla. SM and TB have both had a long time to succeed
> on their own terms as community projects, and it's not clear to me that
> either are significantly contributing to Mozilla's mission.

So let me address this,

SeaMonkey is not a burden on Mozilla Releng. It is a burden on SeaMonkey
Releng.

Thunderbird has been agreed to be a supported (building/machines/etc.)
thing when its day-to-day devs were disconnected from it as a Mozilla
Product. That said it is a burden in terms of priority bumping for
Mozilla Releng.

I personally am an Employee of Mozilla in the Releng Role, and care
heavily about this issue as I am the Lead SeaMonkey Releng human as well
(my work on SeaMonkey is purely my volunteer time).

To drive the point home, I've also devoted some pain/time into fixing
some Releng Bugs for Thunderbird as part of my volunteer time, to make
sure that Thunderbird could stay viable for us.

Prior to my work/role in Releng I was also an active/avid comm-central
build system peer, and that was before there was drastic changes in the
mozilla-central build system that were incompatible with what came before.

Let me state, for the record, that keeping up with changes even PRIOR to
the current cadence is VERY hard. this work in merging the two repos
will allow m-c build system changes to emmediately take affect in
comm-apps without need to port anything, and will keep timings intact.

The releng-specific burden/work that this would have prevented lots of
human hours on, for example includes things like a few months ago, a
releng manager, myself, and a few others (including mark) had to debug
buildbot+thunderbird+comm-central+build-system interactions that
completely broke l10n builds, iirc TB beta is still broken, but we had
to do the work back then to also support ESR. The work took more than a
week and was multiple humans interacting on paid time.

Simply having TB as part of m-c would have simplified a lot of our
releng logic around TB builds and made much of the work a non-issue, and
for the little bit that touched c-c makefiles, would have made them more
likely to be noticed when the m-c Makefiles had to change. There is also
occassionally weird bustage due to m-c build system changes when
$topsrcdir != $mozillasrcdir (specifically because m-c is in
$topsrcdir/mozilla)

I as both community and MoCo releng are FULLY in support of this move,
albeit I gave light to my biases above.

~Justin Wood (Callek)
p.s. If you're curious in truth on why I feel these two products, even
in current form, bolster Mozilla's Mission, feel free to reach out, I'm
happy to skype/vidyo with anyone on that subject.

Benjamin Smedberg

unread,
Apr 3, 2014, 5:34:57 PM4/3/14
to Philipp Kewisch, dev-pl...@lists.mozilla.org
On 4/3/2014 4:49 PM, Philipp Kewisch wrote:
> I really think this is not always clear, or lets say its much too easy
> to forget. While Firefox/Android/B2G is in the focus, its easy to forget
> that the Mozilla Platform should be independent of the concept of a
> browser.
As a project we're spread thin, and having "a platform" separate from
actual projects is mainly a dream that distracts us from what's
important. The thing that gives our platform its importance is the
products that use it, and we need to redouble our focus.

It is true that for technical reasons we try to keep a separation
between our platform code and the user-facing code on top of it: but
that is necessary for sane engineering, not because we have theoretical
platform purity to uphold.

So overall I disagree with you: the Mozilla platform should not be
thought of separately from the products based on it.

> On the other hand, importing c-c into m-c helps to make
> Firefox/Android/B2G developers more aware of this separation: doing an
> mxr search for something in toolkit that is also used in Thunderbird
> will passively let the developer know, that the component he is changing
> is not only used in a browser environment and should be modified in a
> way that is compatible to other consumers of the Mozilla Platform.
This highlights the core decision we need to make. Should developers be
more or less aware of comm-central when developing out platform.

Our clear priority as a project is not comm-central, and so I don't
think we should be including this code.

--BDS

Benjamin Smedberg

unread,
Apr 3, 2014, 5:39:18 PM4/3/14
to Joshua Cranmer 🐧, dev-pl...@lists.mozilla.org
On 4/3/2014 10:01 AM, Joshua Cranmer 🐧 wrote:
>
>
> That said, to reiterate Henri's point, there is a surprising amount of
> code in mozilla-central that doesn't end up being used in Firefox.
> Having filed several bugs for mozilla-central test failures found only
> in comm-central, there are definitely cases where the failure is "oh,
> we don't use <insert toolkit component here> in Firefox" (a recent
> example is the toolkit's downloader). There are also cases where there
> is dynamically-dead code in Firefox that is not dynamically dead in
> Thunderbird: I think for a time, Thunderbird was the only one using
> certain legacy HTML parser APIs.

We should remove that code from mozilla-central/libxul. Our technical
debt is substantial and one of the easiest ways to reduce it is by
removing unneeded code.

>
>>
>> Reason #3: It's unnecessary
>>
>> It is not necessary to alter mozilla-central to put all of
>> Thunderbird in one repository. You can do the merge you are
>> proposing, but keep it as a separate Thunderbird tree and regularly
>> merge changes from mozilla-central into your combined tree.
>
> That works much less well than you'd expect. In such a repository, it
> is impossible to merge changes from comm-central back into
> mozilla-central without introducing c-c's history or rather
> complicated changeset manipulation. It also produces a comm-central
> repository that has the illusion of atomic changesets: there is no way
> to make a commit that does an across-both-trees change such as the
> atomic refcounting changes or gps's DIRS introduction
It is possible with mercurial queues to easily split patches up across
multiple trees. You can also make atomic commits to comm-central by
making the mozilla-central change and avoid merging that until you've
committed the equivalent comm-central changes.

--BDS

Neil

unread,
Apr 3, 2014, 6:15:09 PM4/3/14
to
Henri Sivonen wrote:
> I'm still looking for a volunteer for
> https://bugzilla.mozilla.org/show_bug.cgi?id=937056
Wouldn't this be an example of something that would be much easier to
achieve with a unfied repo?

--
Warning: May contain traces of nuts.

Gregory Szorc

unread,
Apr 3, 2014, 6:19:41 PM4/3/14
to Ben Hearsum, dev-pl...@lists.mozilla.org
Fragmenting repositories is not the answer and only creates more problems.

Unified repositories are a good thing:

1. You have a single commit identifier that identifies the state of the
entire world
2. You can make large changes across multiple projects atomically
3. The tooling doesn't suck (all solutions for subrepos or multi
repository management are significantly worse than single repo experiment).

Many companies that have encountered this problem have made the
determination that having all code live in one repository and thus
available to everyone all the time is a far greater benefit than to have
people constantly agonizing with the downsides of fragmented repositories.

These companies like the benefits so much that they use scalable version
control systems (like Perforce and Mercurial) that can handle tens or
hundreds of thousands of files and gigabytes of data. (Git doesn't scale
well into this territory. Search "Facebook Git scaling" on Google if you
doubt me - you shouldn't doubt Facebook's engineering team.)

While I concede that Mozilla's needs are slightly different from that of
a large corporation with a repository behind a firewall, the benefits of
unified repositories remain. The drawbacks (large clone times) can
largely be mitigated through extensions (with Mercurial at least).

To use a Mozilla example to support claim #2, I'll use mozbase. mozbase
is a suite of Python packages. It's effectively the "Mozilla standard
library." It used to live in GitHub and was merged to mozilla-central
periodically. People working on Python in the tree would often need or
want to make changes to mozbase. They had to commit to Git, wait for a
merge to m-c, then commit whatever changes were depending on it. The
process was brutally agonizing. Often days would go by between mozbase
merges. Stop energy was everywhere. Now, mozbase lives inside
mozilla-central. In one atomic commit I can update mozbase *and* change
all in-tree consumers in one go. It's faster for everybody and makes
everyone more productive. It keeps Mozilla fast and nimble.

If we split Firefox, Android, etc into separate repositories, I think it
would add way too much overhead and pitfalls for everyone involved and
we'd all be screaming to go back to the old world.

Gregory Szorc

unread,
Apr 3, 2014, 6:27:18 PM4/3/14
to Benjamin Smedberg, Mark Banner, mozilla.dev.planning group
On 4/3/14, 6:07 AM, Benjamin Smedberg wrote:
> On 4/3/2014 6:13 AM, Mark Banner wrote:
>>
>> Proposal
>> --------
>>
>> We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
>> of comm-central) into mozilla-central.
>
> I oppose this plan.
>
> I think it's fine to reconsider the decision we made in 2008 not to
> include tbird/seamonkey in mozilla-central, but I don't think the
> arguments here are compelling or that the benefits are worth the costs.
>
> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the code
> in mozilla-central belongs to Firefox in some way, and we have been
> effectively removing most of the code that isn't part of Firefox. When
> searching through the codebase (either locally or using the online dools
> like DXR/MXR) the addition of code which belongs to different products
> will significantly harm developer understanding.
>
> Reason #2: Pull/tree size
>
> There is a non-trivial amount of code involved in this change. In terms
> of both downloading the source repo as well as the size of a local
> checkout, I don't think we should include unnecessary code in the
> Firefox tree.

I believe this reason should be ignored on the basis that it's a
solvable and inevitable problem.

If Mozilla deployed the remotefilelog Mercurial extension on
hg.mozilla.org, people could clone mozilla-central *without* having to
pull the full repository data. A fresh clone of mozilla-central would be
several hundred MB of wire transfer less than today.

We could also write a Mercurial extension that distributed a shallow
bundle. We could probably also write an extension that did partial
bundles, pulls, and checkouts.

These are all solvable problems (with Mercurial at least - Git isn't as
flexible). They just require someone to implement. If we wait long
enough, Facebook may be our savior (they wrote remotefilelog). But they
don't care too much about Windows and non-SSH access. Furthermore, there
aren't that many entities scaling version control to the limits we are.
I fear that fixing these problems will need to come out of Mozilla's
budget sooner or later.

The tree size argument also ignores the harsh reality that the tree will
continue to grow over time. We'll be hitting scaling pains with or
without comm-central. By some accounts, we're already there.

> Reason #3: It's unnecessary
>
> It is not necessary to alter mozilla-central to put all of Thunderbird
> in one repository. You can do the merge you are proposing, but keep it
> as a separate Thunderbird tree and regularly merge changes from
> mozilla-central into your combined tree.

Merging mozilla-central into comm-central periodically does seem
somewhat reasonable to me. That would get rid of most of the special
attention needs that comm-central has inflicted upon mozilla-central's
build system. (I would love to excise those.) But the "atomic commit"
issues remain.

Justin Dolske

unread,
Apr 3, 2014, 6:59:25 PM4/3/14
to
On 4/3/14 3:15 PM, Neil wrote:
> Henri Sivonen wrote:
>> I'm still looking for a volunteer for
>> https://bugzilla.mozilla.org/show_bug.cgi?id=937056
> Wouldn't this be an example of something that would be much easier to
> achieve with a unfied repo?

Not clear to me, but I'd say it definitely is an example of the costs
carried by our core-focus products due to the quasi-supported state of
SM+TB. To stir the pot again, the simplest thing to do here would be to
remove the code, and let SM+TB be responsible for adding it back to a
place if they need to keep using it. Yes, I know that sucks for SM/TB
developers.

Justin

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 7:13:59 PM4/3/14
to
On 4/3/2014 4:39 PM, Benjamin Smedberg wrote:
> On 4/3/2014 10:01 AM, Joshua Cranmer 🐧 wrote:
>>
>>
>> That said, to reiterate Henri's point, there is a surprising amount
>> of code in mozilla-central that doesn't end up being used in Firefox.
>> Having filed several bugs for mozilla-central test failures found
>> only in comm-central, there are definitely cases where the failure is
>> "oh, we don't use <insert toolkit component here> in Firefox" (a
>> recent example is the toolkit's downloader). There are also cases
>> where there is dynamically-dead code in Firefox that is not
>> dynamically dead in Thunderbird: I think for a time, Thunderbird was
>> the only one using certain legacy HTML parser APIs.
>
> We should remove that code from mozilla-central/libxul. Our technical
> debt is substantial and one of the easiest ways to reduce it is by
> removing unneeded code.

My point is that the current situation of separate repositories ends up
being a poor guide already to the true Firefox/Fennec/B2G versus
not-those code repositories, and no one has (to my knowledge) complained
that this is the problem. Moving comm-central into mozilla-central is
not in any way, shape, or form changing the rules that commits to
mozilla-central are not required to keep Thunderbird et al functioning;
therefore, it does not affect technical debt at all. Indeed, if
anything, the solution as proposed may help reduce technical debt by
letting people afraid to remove APIs that have use in Thunderbird remove
them more easily (one person has already suggested he might do this over
IRC).
>
>>
>>>
>>> Reason #3: It's unnecessary
>>>
>>> It is not necessary to alter mozilla-central to put all of
>>> Thunderbird in one repository. You can do the merge you are
>>> proposing, but keep it as a separate Thunderbird tree and regularly
>>> merge changes from mozilla-central into your combined tree.
>>
>> That works much less well than you'd expect. In such a repository, it
>> is impossible to merge changes from comm-central back into
>> mozilla-central without introducing c-c's history or rather
>> complicated changeset manipulation. It also produces a comm-central
>> repository that has the illusion of atomic changesets: there is no
>> way to make a commit that does an across-both-trees change such as
>> the atomic refcounting changes or gps's DIRS introduction
> It is possible with mercurial queues to easily split patches up across
> multiple trees. You can also make atomic commits to comm-central by
> making the mozilla-central change and avoid merging that until you've
> committed the equivalent comm-central changes.

That sounds like the words of someone who has never had to deal with
developing a repository in this kind of situation. A normal comm-central
developer would generally be using the comm-central side of the merge
and would need to remember to update to the mozilla-central side before
pushing. It takes just one person being forgetful to end up with the
comm-central side pushed to mozilla-central. It's a recipe for disaster
in other ways too: patches that affect both non-c-c and c-c code would
still apply equally, and you're relying on all the contributors
remembering to split them up.

It also makes the maintenance burden much more complicated: it would no
longer be possible to bisect the mozilla-central changes to find the
causes of bugs that break Thunderbird code. (Note that such bugs can
also be broken Firefox code that are masqueraded by the way tests are
run--I can think of two or three times that has happened). One of the
goals of the merge is to reduce the maintenance burden to continue the
Thunderbird support to which Mozilla is committed while requiring less
Mozilla resources to maintain that support.

Mike Hommey

unread,
Apr 3, 2014, 7:30:56 PM4/3/14
to Gregory Szorc, Mark Banner, mozilla.dev.planning group, Benjamin Smedberg
remotefilelog only works when you have low latency access to the cache
server.

> We could also write a Mercurial extension that distributed a shallow bundle.
> We could probably also write an extension that did partial bundles, pulls,
> and checkouts.
>
> These are all solvable problems (with Mercurial at least - Git isn't as
> flexible).

Git has shallow clones, so it has the problem solved already.

> They just require someone to implement. If we wait long enough,
> Facebook may be our savior (they wrote remotefilelog). But they don't care
> too much about Windows and non-SSH access. Furthermore, there aren't that
> many entities scaling version control to the limits we are. I fear that
> fixing these problems will need to come out of Mozilla's budget sooner or
> later.
>
> The tree size argument also ignores the harsh reality that the tree will
> continue to grow over time. We'll be hitting scaling pains with or without
> comm-central. By some accounts, we're already there.
>
> >Reason #3: It's unnecessary
> >
> >It is not necessary to alter mozilla-central to put all of Thunderbird
> >in one repository. You can do the merge you are proposing, but keep it
> >as a separate Thunderbird tree and regularly merge changes from
> >mozilla-central into your combined tree.
>
> Merging mozilla-central into comm-central periodically does seem somewhat
> reasonable to me. That would get rid of most of the special attention needs
> that comm-central has inflicted upon mozilla-central's build system. (I
> would love to excise those.) But the "atomic commit" issues remain.

The "atomic commit" issue will likely remain whether TB and SM files are
in mozilla-central or not. Albeit probably less often.

Mike

Mike Hommey

unread,
Apr 3, 2014, 7:38:37 PM4/3/14
to Gregory Szorc, Ben Hearsum, dev-pl...@lists.mozilla.org
On Thu, Apr 03, 2014 at 03:19:41PM -0700, Gregory Szorc wrote:
> On 4/3/14, 8:22 AM, Ben Hearsum wrote:
> Fragmenting repositories is not the answer and only creates more problems.
>
> Unified repositories are a good thing:
>
> 1. You have a single commit identifier that identifies the state of the
> entire world

Which you also have if you use submodules/subrepositories

> 2. You can make large changes across multiple projects atomically

which you also can if you use submodules/subrepositories

> 3. The tooling doesn't suck (all solutions for subrepos or multi repository
> management are significantly worse than single repo experiment).

True. But it seems to me the problem is noone actively seeked fixing
those problems and just went the "easy" way by putting everything in the
same basket. And suffering as a consequence. Which leads to what you're
writing next.

> Many companies that have encountered this problem have made the
> determination that having all code live in one repository and thus available
> to everyone all the time is a far greater benefit than to have people
> constantly agonizing with the downsides of fragmented repositories.
>
> These companies like the benefits so much that they use scalable version
> control systems (like Perforce and Mercurial) that can handle tens or
> hundreds of thousands of files and gigabytes of data. (Git doesn't scale
> well into this territory. Search "Facebook Git scaling" on Google if you
> doubt me - you shouldn't doubt Facebook's engineering team.)

Arguably, they had problems with mercurial too. They just ended up
working on fixing them, which they could equally have done in git except
it's not written in python.

The fact is, they either had to fix those performance issues, or suffer
having to break down their stuff in pieces and improve the workflow with
submodules/subrepositories. The latter is likely more work, especially
the "break it down" part.

> While I concede that Mozilla's needs are slightly different from that of a
> large corporation with a repository behind a firewall, the benefits of
> unified repositories remain. The drawbacks (large clone times) can largely
> be mitigated through extensions (with Mercurial at least).
>
> To use a Mozilla example to support claim #2, I'll use mozbase. mozbase is a
> suite of Python packages. It's effectively the "Mozilla standard library."
> It used to live in GitHub and was merged to mozilla-central periodically.
> People working on Python in the tree would often need or want to make
> changes to mozbase. They had to commit to Git, wait for a merge to m-c, then
> commit whatever changes were depending on it. The process was brutally
> agonizing. Often days would go by between mozbase merges. Stop energy was
> everywhere. Now, mozbase lives inside mozilla-central. In one atomic commit
> I can update mozbase *and* change all in-tree consumers in one go. It's
> faster for everybody and makes everyone more productive. It keeps Mozilla
> fast and nimble.

Except now, it's the other users of mozbase that aren't in m-c that suffer.

Mike

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 7:54:45 PM4/3/14
to
1. The mailnews code was originally fully integrated into the Mozilla
build system since before even the public CVS repository was created.
2. Mailnews code more or less requires being linked into libxul. As a
result, this means that Thunderbird can't extricate itself from the
mozilla-central build system.
3. Mozilla-central has historically had to made accommodations
specifically for comm-central, most notably in the build system. Moving
comm-central into mozilla-central would allow us to remove those
accommodations. I don't think such accommodations have been extended to
4. Mozilla has agreed to continue supporting Thunderbird for the
foreseeable future.
5. Mozilla's source tree has historically not been mozilla-central but
the combination of mozilla-central and comm-central, at least as far as
some things like "is this used in the tree" or "tree-wide mass rewrites"
have been concerned.

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 10:35:10 PM4/3/14
to
On 4/3/2014 5:27 PM, Gregory Szorc wrote:
> The tree size argument also ignores the harsh reality that the tree
> will continue to grow over time. We'll be hitting scaling pains with
> or without comm-central. By some accounts, we're already there.

I did a little experiment to get a sense of the growth rate of
mozilla-central. I selected roughly monthly revisions from
mozilla-central, made a new repository, and pulled those revisions in
one by one, measuring the size of the .hg directory at each point. The
resulting graph is here:
<https://docs.google.com/spreadsheets/d/1ZXu1-5ILH5r87cZ7G2DOVl00UWpXbsZHePSqPcN_KNw/edit?pli=1#gid=298395604>.
Also annotated not as dates are the size of the repository with the
other heads of mozilla-central included as well as the size of the
mozilla-central as it would be were comm-central included.

It turns out I was wrong. The ~140MB of extra .hg space that
comm-central would take up is not a year's worth of checkins, but 4
months' worth.

> Merging mozilla-central into comm-central periodically does seem
> somewhat reasonable to me. That would get rid of most of the special
> attention needs that comm-central has inflicted upon mozilla-central's
> build system. (I would love to excise those.) But the "atomic commit"
> issues remain.

I think the benefits of having atomic commits are rather underrated,
having been forced to deal with non-atomic commit situations not only in
comm-central but my research group's repositories.

Joshua Cranmer 🐧

unread,
Apr 3, 2014, 10:38:24 PM4/3/14
to
On 4/3/2014 6:30 PM, Mike Hommey wrote:
> The "atomic commit" issue will likely remain whether TB and SM files
> are in mozilla-central or not. Albeit probably less often.

The "atomic commit" issue is the inability to make a change that
simultaneously touches both comm-central and mozilla-central code. That
would go away if comm-central were merged in mozilla-central. The
related issue of not all changesets being able to produce a working
Thunderbird build would not go away, although it would hopefully be
reduced in situations such as "I need to add touch all package
manifests" or "I renamed this API globally."

ishikawa

unread,
Apr 4, 2014, 12:56:47 AM4/4/14
to
I think the merge would help reduce the load of build system support
once the merge happens and underlying support scripts become stable.

That would also make the newcomer to TB development to
help community-driven support because
- today, the build support is very fragile: mach command does not
work very well (without scary warning, for example) for C-C tree.
- already mentioned in the thread, but for C-C developres,
-- keeping track of TWO hg repositories is a pain when one
uses tryserver: the scarce documentation does not make sense until
you face a strange failure and then the complex underlying framework
dawns on you :-(
-- meaning that simply creating a working development system on local PC
takes time.

It is a really difficult situation. On one hand, tryserver use is rather
complex until
you get the hang of creating contrived patch sets to reflect the local
change to M-C portion of
copy under C-C (residing C-C/mozilla), and tryserver itself suffered a lot
of build breakage
spring and early summer last year probably to the difficulty of
maintaining complex underlying framework (tryserver did not work very well
in the first half of 2013,
to the point, I have not used it lately.)

If merging C-C to M-C alleviates even a small portion of the support issues,
I think
it is a win to mozilla community as a whole.
Also, the reduced threshold for novice developers to set up
local development environment or the better ease of using tryserver (I hope)
may invite more homebrew develoers of a sort. (Maybe I am pipe-dreaming?)

Yes, there is demand and life behind TB.
Just the other day, a friend of mine talked of helping someone converting
from outlook (because of the platform change, I think), and he says the only
choice he could think of was TB.
Fixing outstanding issues in TB is a very important goal of user community
of TB and
anything that makes it easy is a win.
(Yes, I use TB for work and want it to be a "rock-solid mail client (tm)"
that is available on cross-platform fashion.)

I support this move.

TIA

Mike Hommey

unread,
Apr 4, 2014, 1:32:56 AM4/4/14
to Joshua Cranmer ?, dev-pl...@lists.mozilla.org
On Thu, Apr 03, 2014 at 09:35:10PM -0500, Joshua Cranmer ? wrote:
> On 4/3/2014 5:27 PM, Gregory Szorc wrote:
> >The tree size argument also ignores the harsh reality that the tree will
> >continue to grow over time. We'll be hitting scaling pains with or without
> >comm-central. By some accounts, we're already there.
>
> I did a little experiment to get a sense of the growth rate of
> mozilla-central. I selected roughly monthly revisions from mozilla-central,
> made a new repository, and pulled those revisions in one by one, measuring
> the size of the .hg directory at each point. The resulting graph is here: <https://docs.google.com/spreadsheets/d/1ZXu1-5ILH5r87cZ7G2DOVl00UWpXbsZHePSqPcN_KNw/edit?pli=1#gid=298395604>.
> Also annotated not as dates are the size of the repository with the other
> heads of mozilla-central included as well as the size of the mozilla-central
> as it would be were comm-central included.
>
> It turns out I was wrong. The ~140MB of extra .hg space that comm-central
> would take up is not a year's worth of checkins, but 4 months' worth.

Out of curiosity, what is the apparent size difference in .hg space? (as
in du --apparent-size difference, because on my m-c checkout, the
difference between du and du --apparent-size is 25%, which is 434M (!))

Mike

Nicholas Nethercote

unread,
Apr 4, 2014, 1:44:25 AM4/4/14
to Mark Banner, dev. planning
On Thu, Apr 3, 2014 at 9:13 PM, Mark Banner <mba...@mozilla.com> wrote:
> [follow-ups to mozilla.dev.planning]
>
> tl;dr We're proposing to move Thunderbird and SeaMonkey into
> mozilla-central to reduce maintenance complexities for build systems,
> and for releng.

Unsurprisingly, one's reaction to this proposal mirrors one's answer
to the question "do I care at all about TB/SM?"

I can see this change would make life a *lot* easier for TB/SM
developers, and it would make life slightly more difficult for Firefox
developers. But there are a lot more Firefox developers and Firefox is
a more important product. So who wins?

I'm not expressing an opinion one way or the other about the proposal,
but just trying to clarify the contours of the discussion.

Nick

Philip Chee

unread,
Apr 4, 2014, 3:01:23 AM4/4/14
to
On 03/04/2014 21:28, Henri Sivonen wrote:

> (On that topic: I'm still looking for a volunteer for
> https://bugzilla.mozilla.org/show_bug.cgi?id=937056 . At some point I
> will have whined about this so much that it would have been more
> efficient to just do the move myself even though I'm not supposed to
> use time for Thunderbird development...)

Well yes, but if c-c gets merged then this will simplify the bug as then
we could just do a hg mv followed by a hg rename. Which is why I was
waiting for a decision to merge or not to merge C-C.

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.

Philip Chee

unread,
Apr 4, 2014, 3:08:09 AM4/4/14
to
On 04/04/2014 00:21, Nick Alexander wrote:
> On 2014-04-03, 8:53 AM, Joshua Cranmer 🐧 wrote:
>> On 4/3/2014 10:20 AM, Nick Alexander wrote:
>>> I'd like to add that there exist other apps built on top of Gecko, and
>>> in future there will be more, and that merging every such app into m-c
>>> is not feasible.
>>>
>>> I recognize that Thunderbird and SeaMonkey are special, for technical
>>> and historical reasons, but this sets a bad precedent.
>>
>> I don't think this sets a precedent. If anything, the precedent was set
>> on April 6, 2011 when the Fennec repository was merged with
>> mozilla-central.
>
> I didn't know that Fennec was once separate, so thanks for the history
> lesson!

Also more recently MetroFx was landed on m-c in one large blob.

ishikawa

unread,
Apr 4, 2014, 3:30:44 AM4/4/14
to
Well said.

I think we also explicitly think about the infrastructure support
(which may be missing when one speaks of "developers" as people writing the
source code.).
IMHO, this burden on the infrastructure support in current situation is NOT
SMALL at all, and
that is why the original proposal came about.

TIA

ishikawa

unread,
Apr 4, 2014, 5:34:01 AM4/4/14
to
On (2014年04月04日 16:30), ishikawa wrote:
> I think we also explicitly think about the infrastructure support
I meant to say "we also NEED TO explicitly ..."

TIA

Florian Quèze

unread,
Apr 4, 2014, 6:42:27 AM4/4/14
to Nicholas Nethercote, Mark Banner, dev. planning
On Fri, Apr 4, 2014 at 7:44 AM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> On Thu, Apr 3, 2014 at 9:13 PM, Mark Banner <mba...@mozilla.com> wrote:
>> [follow-ups to mozilla.dev.planning]
>>
>> tl;dr We're proposing to move Thunderbird and SeaMonkey into
>> mozilla-central to reduce maintenance complexities for build systems,
>> and for releng.
>
> Unsurprisingly, one's reaction to this proposal mirrors one's answer
> to the question "do I care at all about TB/SM?"

This is also the way I perceived the answers here.

> I can see this change would make life a *lot* easier for TB/SM
> developers,

Indeed! As someone who's doing Thunderbird work as a volunteer, I'm
really looking forward to this merge.

> and it would make life slightly more difficult for Firefox
> developers.

I understand that people who care only about Firefox are concerned
that this change _may_ make their life slightly more difficult, but
I'm not sure I see what the actual issues are.

The concerns that have been raised so far:
- merging c-c into m-c would increase the size of m-c. Joshua has
shown data indicating that this increase is equivalent to 4 months of
m-c checkins at the current rate. I think this is small enough to make
this concern a non-issue.
- possible confusion when mxr'ing in mozilla-central. As someone who
does Firefox development work, I've sometimes been confused by results
that were for metro, because they were in browser/ and have paths
similar to those of files I was looking for. I don't think I could be
confused by files in a folder named "mail/".

Whether Mozilla should keep supporting Thunderbird with releng is IMHO
a completely different discussion. As far as I understand it, the
current state is that Mozilla Corporation has committed to keep the
product building and to provide security updates in the foreseeable
future.

Florian

--
Florian Quèze

Ben Hearsum

unread,
Apr 4, 2014, 7:35:38 AM4/4/14
to
Your response is pretty much what I was trying to get at (which I did
poorly, sorry about that).

On 04/03/14 07:38 PM, Mike Hommey wrote:
>> 3. The tooling doesn't suck (all solutions for subrepos or multi repository
>> management are significantly worse than single repo experiment).
>
> True. But it seems to me the problem is noone actively seeked fixing
> those problems and just went the "easy" way by putting everything in the
> same basket. And suffering as a consequence. Which leads to what you're
> writing next.

Yep. This ship has long sailed, but if Firefox had been moved to another
repository at the same time as Thunderbird/SeaMonkey (when we moved to
Mercurial originally IIRC), we would've been heavily invested into
solving this problems.

>> While I concede that Mozilla's needs are slightly different from that of a
>> large corporation with a repository behind a firewall, the benefits of
>> unified repositories remain. The drawbacks (large clone times) can largely
>> be mitigated through extensions (with Mercurial at least).
>>
>> To use a Mozilla example to support claim #2, I'll use mozbase. mozbase is a
>> suite of Python packages. It's effectively the "Mozilla standard library."
>> It used to live in GitHub and was merged to mozilla-central periodically.
>> People working on Python in the tree would often need or want to make
>> changes to mozbase. They had to commit to Git, wait for a merge to m-c, then
>> commit whatever changes were depending on it. The process was brutally
>> agonizing. Often days would go by between mozbase merges. Stop energy was
>> everywhere. Now, mozbase lives inside mozilla-central. In one atomic commit
>> I can update mozbase *and* change all in-tree consumers in one go. It's
>> faster for everybody and makes everyone more productive. It keeps Mozilla
>> fast and nimble.
>
> Except now, it's the other users of mozbase that aren't in m-c that suffer.

+1. It's hard for people to get the tools that are embedded into our
massive repo, and it's easy to accidentally (or on purpose) depend on
completely unrelated things, making them useless to others.

Joshua Cranmer 🐧

unread,
Apr 4, 2014, 9:29:33 AM4/4/14
to
Interestingly enough, the --apparent-size for mozilla-central without
comm-central is 1165MB while the one for mozilla-central with
comm-central is 1249MB.

Zack Weinberg

unread,
Apr 4, 2014, 10:08:32 PM4/4/14
to
On 2014-04-03 9:07 AM, Benjamin Smedberg wrote:

> Reason #1: confusion about what code belongs to what projects
>
> Currently when hacking on Firefox, it's roughly clear that all the code
> in mozilla-central belongs to Firefox in some way, and we have been
> effectively removing most of the code that isn't part of Firefox. When
> searching through the codebase (either locally or using the online dools
> like DXR/MXR) the addition of code which belongs to different products
> will significantly harm developer understanding.

I disagree with this assessment: I have on several occasions had patches
stall out because comm-central is using code that *appears* to be dead
in m-c, or, contrariwise, because new infrastructure *appears* to be
universally available, but turns out to be unavailable in Thunderbird
and/or Seamonkey. It would be far easier to see this sort of thing
coming if all of our C++ code was in one repository.

(How about we go ahead and do this but we also at the same time ban
compiled-code XPCOM components that aren't linked into libxul? Half
kidding.)

zw

Justin Wood (Callek)

unread,
Apr 7, 2014, 7:05:19 PM4/7/14
to
SUMMARY [based on my interpretation of responses in this thread]:

As if this was a pure-vote based on responses:

11 - YES Merge c-c into m-c
5 - No Don't Merge It in
2 - Abstained (No Decision Specified)

(Who):

Edmorley: Abstain
Jcranmer: YES
Bsmedberg: NO
MBanner: YES
Bhearsum: ABSTAIN
Khuey: NO
GPS: Yes
ishikawa: YES
Phillip Kewisch: yes
Zack Weinberg: Yes
Bholley: No
Henri: YES
Dolske: No
Phillip Chee: YES
clokep: YES
nalexander: NO
Florian: Yes
Callek: Yes

If I got any of those wrong please tell me.

I know its not a "vote here please" and number of responses
(human-count-wise) is indeed low. And then factoring in meritocracy some
humans responses likely weigh more than others in this decision. So to
further along, whom of this list gets to make the decision, if no-one
whom do we escalate to for an explicit yes/no?

I'd love to see this move forward, and the threads responses seem to
have dwindled down to almost nothing.

~Justin Wood (Callek)

Trevor Saunders

unread,
Apr 7, 2014, 7:22:51 PM4/7/14
to dev-pl...@lists.mozilla.org
On Mon, Apr 07, 2014 at 07:05:19PM -0400, Justin Wood (Callek) wrote:
> I know its not a "vote here please" and number of responses
> (human-count-wise) is indeed low. And then factoring in meritocracy some
> humans responses likely weigh more than others in this decision. So to
> further along, whom of this list gets to make the decision, if no-one whom
> do we escalate to for an explicit yes/no?

istr hearing Brendan needs to approve new top level dirs, so if true it
would seem to be him :-)

> I'd love to see this move forward, and the threads responses seem to have
> dwindled down to almost nothing.

so would I for what little its worth ;)

Trev

>
> ~Justin Wood (Callek)
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
signature.asc

Nick Alexander

unread,
Apr 7, 2014, 7:49:47 PM4/7/14
to dev-pl...@lists.mozilla.org
On 2014-04-07, 4:05 PM, Justin Wood (Callek) wrote:
> SUMMARY [based on my interpretation of responses in this thread]:
>
> As if this was a pure-vote based on responses:
>
> 11 - YES Merge c-c into m-c
> 5 - No Don't Merge It in
> 2 - Abstained (No Decision Specified)
>
> (Who):

<snip>

> nalexander: NO

Based on the further discussion and history, I'll amend my -1 to a
gentle +0.

Nick

Joshua Cranmer 🐧

unread,
Apr 7, 2014, 8:22:31 PM4/7/14
to benj...@smedbergs.us, Brendan Eich
I'd like to see this resolved within the next 24 hours. To summarize the
current state of affairs, as I see it:

The only substantive objections raised to this merge were the three
points mentioned by bsmedberg, to which all other dissenters (both in
this newsgroup and on IRC) have essentially concurred. These three are:
1. Conflation of Firefox code with not-Firefox code.
2. Repository size
3. Unnecessary.

My responses to these three points boil down to the following:
1. Not a big issue, but alternative 2 should solve any issues here.
2. The additional heft added to mozilla-central would not be large in
the context of normal mozilla-central development.
3. bsmedberg posed an alternative that I concede would solve the build
issue, but that would cause maintenance and support experiences to worsen.

There was another point brought up (I hesitate to call it an objection)
that asked what this merge would mean for precedent. My response is that
a) precedent is effectively set by the old mobile-browser repository and
b) comm-central is not a precedent which non-Mozilla-developed
applications can expect to follow.

Effectively, I propose two alternatives in the merge:
Alternative 1: Merge comm-central into mozilla-central as a flat merge
(as proposed in the top of the thread)
Alternative 2: Merge comm-central into a subdirectory of mozilla-central
named 'comm/'

I prefer the first alternative, mostly because it involves less work to
do a flat merge and preparatory work commenced under the assumption that
it would happen like so, but I would be more than willing to do the work
to merge under alternative 2 instead.

I'm CC'ing Brendan Eich and Bsmedberg explicitly because those are the
people to whom I'm mostly directing the question of finally resolving
this proposal.


On 4/7/2014 6:05 PM, Justin Wood (Callek) wrote:
> SUMMARY [based on my interpretation of responses in this thread]:
>
> As if this was a pure-vote based on responses:
>
> 11 - YES Merge c-c into m-c
> 5 - No Don't Merge It in
> 2 - Abstained (No Decision Specified)

There was some discussion in IRC about this, and there were some people
who indicated support/opposition there without responding to the mailing
list.

Bobby Holley

unread,
Apr 7, 2014, 11:51:02 PM4/7/14
to Joshua Cranmer 🐧, dev. planning, Benjamin Smedberg, Brendan Eich
On Mon, Apr 7, 2014 at 5:22 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>wrote:

> I'd like to see this resolved within the next 24 hours. To summarize the
> current state of affairs, as I see it:
>

That's pretty fast, considering that:
(a) The updated proposals have just been sent out.
(b) The community and technical leadership are distracted an exhausted
right now with other issues.

Why does this need to be rushed?


> My responses to these three points boil down to the following:
> 1. Not a big issue, but alternative 2 should solve any issues here.
>

I don't think that's true. Even if the code were in comm/, anyone hacking
on the source code needs to know that the rules are very different for that
subdirectory.

2. The additional heft added to mozilla-central would not be large in the
> context of normal mozilla-central development.
>

I think it's still too much considering the prioritization of TB/SM.
mozilla-central should not contain a significant amount of non-tier-11
code.

Matthew N.

unread,
Apr 8, 2014, 3:34:59 AM4/8/14
to
On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote:
> 1. Conflation of Firefox code with not-Firefox code.

I'd like tooling such as MXR to be updated to exclude whatever
directories would be added from comm-central so I don't have to spend
extra time ignoring them. Ideally they would be under one top-level
directory to make this easy.

MattN

Philipp Kewisch

unread,
Apr 8, 2014, 4:56:54 AM4/8/14
to
I did mention earlier that it would indeed be nice to influence ordering
so that its easier to group by product, but ignoring the whole directory
doesn't seem like the right solution to me? If this is done anyway, then
it would in turn be nice to ignore browser/mobile/b2g when searching for
(former) c-c code.

Philipp

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 10:14:53 AM4/8/14
to
On 4/7/2014 10:51 PM, Bobby Holley wrote:
> On Mon, Apr 7, 2014 at 5:22 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>wrote:
>
>> I'd like to see this resolved within the next 24 hours. To summarize the
>> current state of affairs, as I see it:
>>
> That's pretty fast, considering that:
> (a) The updated proposals have just been sent out.
> (b) The community and technical leadership are distracted an exhausted
> right now with other issues.
>
> Why does this need to be rushed?

The goal is to land these changes in the 31 release cycle. If this
schedule is missed, then it obligates release engineering to have to
support the current situation for an extra 42 weeks due to the ESR
branch cycle. In addition, there are already some build configuration
tasks that are blocking on landing this reworked comm-central design. If
I need to change the landing scripts, that requires extra lead time to
make changes.
> I don't think that's true. Even if the code were in comm/, anyone hacking
> on the source code needs to know that the rules are very different for that
> subdirectory.

You mean just like anyone hacking on source code would need to know that
the rules are very different for nsprpub/, security/manager/, or any of
the other semi-autonomous or imported libraries into mozilla-central?
Mozilla-central already hosts a wide range of different tree rules, and
my experience with both mozilla-central and comm-central development is
that divergent tree rules are not a barrier in practice.

Zack Weinberg

unread,
Apr 8, 2014, 10:26:46 AM4/8/14
to
I'd be fine with a "ignore code not part of Firefox" checkbox, but
getting comm-central code to show up on default MXR searches is
precisely why I *support* this proposal.

zw

Bobby Holley

unread,
Apr 8, 2014, 10:35:06 AM4/8/14
to Joshua Cranmer 🐧, dev. planning
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com>wrote:

> You mean just like anyone hacking on source code would need to know that
> the rules are very different for nsprpub/, security/manager/, or any of the
> other semi-autonomous or imported libraries into mozilla-central?
> Mozilla-central already hosts a wide range of different tree rules, and my
> experience with both mozilla-central and comm-central development is that
> divergent tree rules are not a barrier in practice.


I'm more or less talking about refactorings that would break comm/, and the
confusion over what is tier-1. I'm not adamant about it, but the concern
stands.

Gavin Sharp

unread,
Apr 8, 2014, 12:21:29 PM4/8/14
to Joshua Cranmer 🐧, dev. planning
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
> You mean just like anyone hacking on source code would need to know that the
> rules are very different for nsprpub/, security/manager/, or any of the
> other semi-autonomous or imported libraries into mozilla-central?

Those are very different - they're not consumers of Gecko. If you're
changing Gecko, you are not responsible for fixing Thunderbird or
SeaMonkey consumers. Having the TB/SM code in mozilla-central implies
that you do (or at the very least introduces confusion). That's a
problem.

Gavin

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 12:33:36 PM4/8/14
to
I don't think it does. I suspect that most developers rely on the
results returned by tbpl to indicate whether or not they have broken
code. By not hosting TB and SM in the same tbpl views as Firefox builds,
most developers would be unaware (and thus generally wouldn't care) if
TB/SM were broken.

Martin Thomson

unread,
Apr 8, 2014, 12:42:42 PM4/8/14
to Joshua Cranmer 🐧, dev-pl...@lists.mozilla.org
On 2014-04-08, at 09:33, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:

> I don't think it does. I suspect that most developers rely on the results returned by tbpl to indicate whether or not they have broken code. By not hosting TB and SM in the same tbpl views as Firefox builds, most developers would be unaware (and thus generally wouldn't care) if TB/SM were broken.

Let’s be very clear in what you are asking here. You are asking Firefox developers to contribute their time and efforts to maintaining Thunderbird and Spider Monkey.

This might not be a huge burden given the contribution others already make. But it’s not free.

Gijs Kruitbosch

unread,
Apr 8, 2014, 12:55:35 PM4/8/14
to
Err, no. For one, it's SeaMonkey, not spidermonkey. I realize we have a
lot of monkeys, but it's an important distinction. :-)

And for another, still no: because it's a separate TBPL view, as long as
the mozilla-central Firefox desktop and mobile and b2g builds pass,
landing is fine. The proposal is only about the source code location,
not about making SM/TB show up on the main mozilla-central TBPL view.

~ Gijs

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 12:57:51 PM4/8/14
to
On 4/8/2014 11:42 AM, Martin Thomson wrote:
> On 2014-04-08, at 09:33, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
>
>> I don't think it does. I suspect that most developers rely on the results returned by tbpl to indicate whether or not they have broken code. By not hosting TB and SM in the same tbpl views as Firefox builds, most developers would be unaware (and thus generally wouldn't care) if TB/SM were broken.
> Let’s be very clear in what you are asking here. You are asking Firefox developers to contribute their time and efforts to maintaining Thunderbird and Spider Monkey.

That is *NOT* what I am asking, and I cannot see how you are inferring
that from my responses. Adding the comm-central code to mozilla-central
is not, in any way, shape, or form, changing the current tree rules with
respect to whether or not mozilla-central changes may break
comm-central, as affirmed in Mark Banner's original message.

Gavin Sharp

unread,
Apr 8, 2014, 1:43:42 PM4/8/14
to Joshua Cranmer 🐧, dev. planning
On Tue, Apr 8, 2014 at 9:33 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
> I don't think it does. I suspect that most developers rely on the results
> returned by tbpl to indicate whether or not they have broken code.

Sure, that's one way. But before you even get to the point of pushing
a patch to try, you have to grep for code to fix in your patch. Having
extra code in the tree that you have checked out introduces overhead
there.

Gavin

Johnny Stenback

unread,
Apr 8, 2014, 2:41:45 PM4/8/14
to Joshua Cranmer 🐧, dev-pl...@lists.mozilla.org, benj...@smedbergs.us, Brendan Eich
If you want an answer to whether or not we will to this in the next 24
hours then the answer is absolutely no.

I'm personally strongly against reversing our position on this. Adding
more non-tier-1 code to mozilla-central is IMO the wrong direction here,
and rushing a decision like that, especially given the recent events, is
IMO not reasonable. And yes, I would fully expect Brendan to weigh in on
this if we were to do this.

It seems very clear to me that this will increase the amount of time
engineers who work on tier-1 products end up having to spend on
non-tier-1 projects, meaning it would decrease the amount of time they
spend on tier-1 projects. Therefore I do not support this change.
jst

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 3:05:12 PM4/8/14
to
On 4/8/2014 1:41 PM, Johnny Stenback wrote:
> It seems very clear to me that this will increase the amount of time
> engineers who work on tier-1 products end up having to spend on
> non-tier-1 projects, meaning it would decrease the amount of time they
> spend on tier-1 projects. Therefore I do not support this change.

I do not think this is likely to increase the time spent on maintaining
Thunderbird by non-Thunderbird developers but would rather decrease it.
These changes would bring about substantial improvements and reduction
in maintenance efforts by both releng and the build system peers. The
odd scenario of someone trying to unnecessarily (per tier-1 rules) fix
Thunderbird code merely because it's an API use in the tree would be
more than balanced by the reduced effort on the part of release
engineering or build systems trying to deal with failures that would be
prevented by Thunderbird being in mozilla-central: most recent scenarios
are issues caused by path lengths on Windows, or the inability to get
localized builds on beta.

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 3:09:07 PM4/8/14
to
In my experience of comm-central development, most changes to APIs that
would break comm-central are either mechanical transitions or API
changes for which the comm-central uses are important and end up
blocking the API change in mozilla-central. It's not clear to me that
the overhead that would be introduced would be distinctly measurable.

Benjamin Smedberg

unread,
Apr 8, 2014, 3:24:42 PM4/8/14
to Justin Wood (Callek), dev-pl...@lists.mozilla.org
On 4/7/2014 7:05 PM, Justin Wood (Callek) wrote:
>
>
> So to further along, whom of this list gets to make the decision, if
> no-one whom do we escalate to for an explicit yes/no?
>

I will assert that this is my decision to make unless I am overruled by
Brendan.

On 4/7/2014 8:22 PM, Joshua Cranmer 🐧 wrote:
> I'd like to see this resolved within the next 24 hours. To summarize
> the current state of affairs, as I see it:
>
> The only substantive objections raised to this merge were the three
> points mentioned by bsmedberg, to which all other dissenters (both in
> this newsgroup and on IRC) have essentially concurred. These three are:
> 1. Conflation of Firefox code with not-Firefox code.
> 2. Repository size
> 3. Unnecessary.

The tradeoff here is a little complex, but I'm going to articulate some
base axioms:

* Firefox, Firefox for Android, and B2G are the first priorities of the
Mozilla project.
* We have a secondary commitment to provide security and maintenance
updates to Thunderbird.
* The organization of our source code should reflect our project priorities.

And some assumptions, some of which have been called into question in
this thread:

* Most people hacking Firefox should not and do not have to consider
comm-central's needs when writing patches.

Zack has mentioned that some of his patches got hung up because of
concerns about affecting comm-central. I don't know the details, but I
will strongly assert that this means we should be more aggressive about
*removing* code, not that this is an argument for merging them more.

* The policies we write down here mostly don't matter: new contributors
and old will pay attention to whatever code they read/search.

This is human nature.

This leads me to some basic conclusions:

* Thunderbird (and Seamonkey) code should not be present in the code
that people read and search by default: this includes DXR/MXR as well as
local checkouts indexed with whatever local IDE/editor they are using.
* We don't currently have a way to commit this code to mozilla-central
but exclude it from local checkouts or DXR. We could set up this
infrastructure.

Given those, we will not include comm-central in mozilla-central at the
present time.

--BDS

Justin Wood (Callek)

unread,
Apr 8, 2014, 4:04:02 PM4/8/14
to
On 4/8/2014 3:24 PM, Benjamin Smedberg wrote:
>
> * The organization of our source code should reflect our project
> priorities.

I'm not sold on this point of yours...

We have xulrunner in m-c.

We have non-Firefox python packages in m-c, which have non-Firefox
codebase uses and bugfixes landing.

We have nspr/nss in m-c, including parts that have zero affect on
Firefox day-to-day dev.

We have the addon-sdk in m-c itself, which is there to assist the
addon-sdk (tier 2 project) when Firefox changes land.

we also have other-licenses stuff in m-c which is not all used by
Firefox directly.

>
> * The policies we write down here mostly don't matter: new
contributors and old will pay attention to whatever code they read/search.
>
> This is human nature.

I don't buy this. There is lots of code in m-c, everyone is a new
contributor once, but being aware of Thunderbird/SeaMonkey using a
feature is not a barrier I think we should care about. And in-fact I
think its a feature.

If a dev is removing code that is only used in thunderbird/SeaMonkey its
a "Hey they are the ones using it, is this really a priority for us, or
should I just remove it and tell them" vs "NO-ONE uses this"

also "I wrote this script to convert nsAString to nsString across the
whole tree, I won't run it on c-c because I don't care about
TB/SeaMonkey, however since they are in m-c they get it for free"... no
extra time lost by helping us.

The hit of humans seeing comm-apps exist is one of policy when coupled
with the above other things and not one of wasted time, imho. Heck I'm
happy to have us amend the license block in every c-c file with

"THIS IS TIER 2 CODE, BUSTAGE IS NOT A BLOCKER TO STUFF LANDING FOR
Firefox/B2G/Android" if it gets this moved forward.

-~ as to the MXR/DXR concerns we can certainly amend code to leave the
comm/ subdir or whatever out of the searches/checkout and leave
comm-central a seperate beast on those services. I personally don't
like the thought of that as it explicitly omits stuff you'd expect to
live there.

Making life more difficult for those of us community who are furthering
the mission with Thunderbird/SeaMonkey in our own ways (by being
different than Mozilla's *core* focus) is not imo a good thing when you
weigh the amount of difficulty on both sides of the coin.

Volunteers by their nature should (imo) be nurtured to make their lives
easier in the places they are able/willing to volunteer, and us paid
people who do it all the time can realize that "hey stuff in suite/ or
mail/ is simply-put not tier 1."

~Justin Wood (Callek)

Gijs Kruitbosch

unread,
Apr 8, 2014, 6:13:37 PM4/8/14
to Benjamin Smedberg
On 08/04/2014 20:24, Benjamin Smedberg wrote:
> The tradeoff here is a little complex, but I'm going to articulate some
> base axioms:
>
> * Firefox, Firefox for Android, and B2G are the first priorities of the
> Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.
> * The organization of our source code should reflect our project
> priorities.

I disagree with this 3rd axiom. I think the organization of our source
code should be optimized for developer productivity of the people
working on the tier-1 projects (from (or under, in the case of e.g.
nss/js/...) axiom 1). This, to me, is the higher-level version of your
3rd axiom (in that source code organization only matters insofar as it
is correlated to developer productivity), but considering it at that
level means I reach different conclusions.

The current split does not optimize for developer productivity. Not
"even" for tier-1 developer productivity. Toolkit code especially is
shared, and while not all the code in it is currently
Firefox-used/usable, it isn't a productive use of anybody's time to
distinguish those bits from the bits we do use, and fully purge e.g. the
CSS that we override in-product, or the components which we only use in
altered form, etc.

Effectively, we have to at least consider the theoretical distinction
between the toolkit and firefox modules, and their respective bits of
in-window JS (yes, toolkit has some of that too!), CSS, and JS modules.

> And some assumptions, some of which have been called into question in
> this thread:
>
> * Most people hacking Firefox should not and do not have to consider
> comm-central's needs when writing patches.

Which is why I believe this assumption doesn't hold. What's more, as a
Firefox desktop frontend developer, I actually think I would be *more*
productive if there were concrete non-Firefox-toolkit-using code in m-c,
not only because of atomic patches for toolkit + some consumers, but
also because of concrete examples of how toolkit stuff gets used elsewhere.

> Zack has mentioned that some of his patches got hung up because of
> concerns about affecting comm-central. I don't know the details, but I
> will strongly assert that this means we should be more aggressive about
> *removing* code, not that this is an argument for merging them more.

Again, I don't think excising this code will help anyone. If we want to
actively work against people trying to use XUL and Toolkit for anything
but Firefox, and eliminate the toolkit/firefox frontend js/css split,
then yes, this is the right thing to do, and we should remove all
non-Firefox-used Toolkit code.

However, I don't think that's what we want to be doing (at least at the
moment), and the pain/gain ratio does not appeal to me. Therefore it
seems like the argument for being aggressive about removing code is
spurious: there is little we could remove, and it would make more sense
to do the opposite, and make the life of toolkit-changing folks (tier-1
project and TB/SM developers alike) easier by merging cc to mc.

~ Gijs

Joshua Cranmer 🐧

unread,
Apr 8, 2014, 9:45:24 PM4/8/14
to
On 4/8/2014 2:24 PM, Benjamin Smedberg wrote:
> The tradeoff here is a little complex, but I'm going to articulate
> some base axioms:
>
> * Firefox, Firefox for Android, and B2G are the first priorities of
> the Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.
> * The organization of our source code should reflect our project
> priorities.
>

I think the core disagreement here may come in understanding what is
implied by the commitment to provide security and maintenance to
Thunderbird. To my eyes, this commitment has translated into saying
that, while Thunderbird may not necessarily be working at all times as a
buildable project, it does mean that mozilla-central developers should
be prepared to assist Thunderbird developers in the case of problems and
that completely gratuitous bustage should be avoided, effectively making
Thunderbird around a tier 2 platform. It also means to me that Mozilla
employees in certain categories, most notably release engineering, are
tasked with needing to maintain Thunderbird-related infrastructure.

The way this merge proposal has been presented and mostly discussed has,
I think, confused people as to the real purposes. I think many of the
dissenters are dissenting under the belief that the main rationale of
the proposal is "make comm-central developers' lives easier." This is
not the case: while I have personally desired this merge for that
reason, I would have never voiced an opinion here on it were this the
main goal of the proposal, for many of the reasons.

The current way that Thunderbird is built--as a separate repository that
is the parent of mozilla-central--is completely untenable; the changes
to make the comm-central build system more maintainable is a project
known as ccrework, which I've been working on for quite some time--and
which most of the build system peers have been hectoring me to get
completely finished. The proposal to move comm-central into
mozilla-central is the ultimate end of the ccrework project, and that
decision was not part of the original plans. Rather, it was made when I
came to the realization that one of the two goals of ccrework, the
deduplication and simplification of release engineering configurations,
could not be made without the merger proposed herein. It is the lack of
other tenable setups that led us to this proposal, a fact which I fear
may have been muddled by many of the discussions made in this thread.

So I want to explicitly mention my concern that the impact on areas like
release engineering or other expenditure of resources needed to provide
minimal Thunderbird support has not been taken into account when
arriving at this decision.

> This leads me to some basic conclusions:
>
> * Thunderbird (and Seamonkey) code should not be present in the code
> that people read and search by default: this includes DXR/MXR as well
> as local checkouts indexed with whatever local IDE/editor they are using.
> * We don't currently have a way to commit this code to mozilla-central
> but exclude it from local checkouts or DXR. We could set up this
> infrastructure.
>
> Given those, we will not include comm-central in mozilla-central at
> the present time.

If I may ask:
* If we had this hg solution, would you be willing to accede to the merge?
* Are you willing to commit resources to making these changes to hg?
(DXR ought to already have this infrastructure; if not, it's clearly a
DXR bug)

Blake Winton

unread,
Apr 8, 2014, 11:27:16 PM4/8/14
to
On 2014-04-08, 18:13, Gijs Kruitbosch wrote:
> On 08/04/2014 20:24, Benjamin Smedberg wrote:
>> The tradeoff here is a little complex, but I'm going to articulate some
>> base axioms:
>> * Firefox, Firefox for Android, and B2G are the first priorities of the
>> Mozilla project.
>> * We have a secondary commitment to provide security and maintenance
>> updates to Thunderbird.
>> * The organization of our source code should reflect our project
>> priorities.
> I disagree with this 3rd axiom. I think the organization of our source
> code should be optimized for developer productivity of the people
> working on the tier-1 projects (from (or under, in the case of e.g.
> nss/js/...) axiom 1). This, to me, is the higher-level version of your
> 3rd axiom (in that source code organization only matters insofar as it
> is correlated to developer productivity), but considering it at that
> level means I reach different conclusions.

I think we should also consider the other groups who need to work with
our source code. RelEng is the one that springs immediately to mind
(perhaps because I work near several of them ;), but I suspect there are
others, such as the people working on the build system, perhaps?

It would be nice to hear opinions from those groups as to what would be
easiest to work with, and how much easier or harder the various options are.

Later,
Blake.

Justin Wood (Callek)

unread,
Apr 8, 2014, 11:42:40 PM4/8/14
to
For what its worth I am from Releng, but I also double as a SeaMonkey
Council member, so bear that in mind.

I outlined strong support for this earlier in the thread with an
emphasis (I like to think) on the importance of this change, as I see
it, for releng.

I won't repeat that in this post though.

~Justin Wood (Callek)

Gavin Sharp

unread,
Apr 9, 2014, 12:37:42 AM4/9/14
to Gijs Kruitbosch, dev. planning
On Tue, Apr 8, 2014 at 3:13 PM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> Which is why I believe this assumption doesn't hold. What's more, as a
> Firefox desktop frontend developer, I actually think I would be *more*
> productive if there were concrete non-Firefox-toolkit-using code in m-c, not
> only because of atomic patches for toolkit + some consumers, but also
> because of concrete examples of how toolkit stuff gets used elsewhere.

I don't buy it :) You would not be more productive in making Firefox
great, you'd be more productive in maintaining the toolkit
abstractions. That's not really a primary goal (going back to
Benjamin's axiom #1).

But we don't actually need to pick one of the two "get rid of toolkit/
entirely" and "merge all toolkit consumers into m-c" extremes - that's
a false dichotomy.

Benjamin's arguing that we should get closer to the "get rid of
toolkit/" extreme than we are now, and that we certainly shouldn't
take steps in the direction of "merge all toolkit consumers into m-c"
(as this proposal suggests). I agree with him. I also agree with you
that trying to get to "get rid of toolkit/ entirely" doesn't have a
great cost/benefit ratio on its own.

Gavin

Doug Turner

unread,
Apr 9, 2014, 12:47:53 AM4/9/14
to Mark Banner, dev-pl...@lists.mozilla.org
I would rather see /browser and /mobile removed from mozilla-central
making this repo exclusive to 'gecko development'. So, I disagree
with your proposal and would not support this move.

Have you considering just importing m-c into your repo? I am sure
there are smart git ways of doing this using submodules -- for
example.

Lastly and somewhat related - people use code search to figure out how
to do something. I would hate for them to find bits of
old/incorrect/crufty SeaMonkey code (which has a LOC / Contributing
Engineer ratio approaching INF). I am not sure if Thunderbird is
similar but I suspect so.

Joshua Cranmer 🐧

unread,
Apr 9, 2014, 1:04:34 AM4/9/14
to
On 4/8/2014 11:47 PM, Doug Turner wrote:
> I would rather see /browser and /mobile removed from mozilla-central
> making this repo exclusive to 'gecko development'. So, I disagree
> with your proposal and would not support this move.

If I ever thought this was a tenable move, I would have suggested it.
Instead, mobile code was merged into mozilla-central precisely because
of the pains of developing across multiple repositories.
> Have you considering just importing m-c into your repo? I am sure
> there are smart git ways of doing this using submodules -- for
> example.
Submodules are not an acceptable solution, particularly because of the
necessary repository layout. Importing mozilla-central into comm-central
but not vice versa is not an effective solution for maintenance, since
it eliminates the ability to bisect on mozilla-central-induced failures.

> Lastly and somewhat related - people use code search to figure out how
> to do something. I would hate for them to find bits of
> old/incorrect/crufty SeaMonkey code (which has a LOC / Contributing
> Engineer ratio approaching INF). I am not sure if Thunderbird is
> similar but I suspect so.

Actually, almost all of the C++ code (and cruftiest bits) are shared
between Thunderbird and SeaMonkey. Most of the cruftiness in Thunderbird
code is too old to even use bad APIs, actually (libmime and guts of
compose are largely written in C instead of C++ and rely more on NSPR
than ancient XPCOM APIs).

Mike Hommey

unread,
Apr 9, 2014, 1:18:50 AM4/9/14
to Blake Winton, dev-pl...@lists.mozilla.org
On Tue, Apr 08, 2014 at 11:27:16PM -0400, Blake Winton wrote:
> On 2014-04-08, 18:13, Gijs Kruitbosch wrote:
> >On 08/04/2014 20:24, Benjamin Smedberg wrote:
> >>The tradeoff here is a little complex, but I'm going to articulate some
> >>base axioms:
> >>* Firefox, Firefox for Android, and B2G are the first priorities of the
> >>Mozilla project.
> >>* We have a secondary commitment to provide security and maintenance
> >>updates to Thunderbird.
> >>* The organization of our source code should reflect our project
> >>priorities.
> >I disagree with this 3rd axiom. I think the organization of our source
> >code should be optimized for developer productivity of the people
> >working on the tier-1 projects (from (or under, in the case of e.g.
> >nss/js/...) axiom 1). This, to me, is the higher-level version of your
> >3rd axiom (in that source code organization only matters insofar as it
> >is correlated to developer productivity), but considering it at that
> >level means I reach different conclusions.
>
> I think we should also consider the other groups who need to work with our
> source code. RelEng is the one that springs immediately to mind (perhaps
> because I work near several of them ;), but I suspect there are others, such
> as the people working on the build system, perhaps?

My build system peer take on this is that I don't care, as long as c-c
stops using its own configure and copy of config/ and build/[1]. That can
be achieved with or without merging c-c in m-c.

Mike

1. Note that c-c is the only "third-party" gecko-based application i'm aware
of that uses its own copy of our build system and have problems with
changes in our build system as a consequence. AFAIK, others just use
--enable-application.

ishikawa

unread,
Apr 9, 2014, 3:15:36 AM4/9/14
to
If there is a concern that firefox/b2g people are concerned
about breaking TB/SeaMonkey,
I will not mind having something like this in every source files
in the c-c portion under m-c as suggested by
Justine Wood.
> The hit of humans seeing comm-apps exist is one of policy when coupled with
> the above other things and not one of wasted time, imho. Heck I'm happy to
> have us amend the license block in every c-c file with
>
> "THIS IS TIER 2 CODE, BUSTAGE IS NOT A BLOCKER TO STUFF LANDING FOR
> Firefox/B2G/Android" if it gets this moved forward.
>

> -~ as to the MXR/DXR concerns we can certainly amend code to leave the comm/
> subdir or whatever out of the searches/checkout and leave comm-central a
> seperate beast on those services.

If this gets merging done, I would be happy with this (provided of course,
to have an option
to include both c-c portion as well as the native m-c.

> I personally don't like the thought of
> that as it explicitly omits stuff you'd expect to live there.
>
> Making life more difficult for those of us community who are furthering the
> mission with Thunderbird/SeaMonkey in our own ways (by being different than
> Mozilla's *core* focus) is not imo a good thing when you weigh the amount of
> difficulty on both sides of the coin.
>
> Volunteers by their nature should (imo) be nurtured to make their lives
> easier in the places they are able/willing to volunteer, and us paid people
> who do it all the time can realize that "hey stuff in suite/ or mail/ is
> simply-put not tier 1."

I think the move would help the assumed "Community-support" of TB/SeaMonkey.
TB TryBuilder suffered build bustages often in early last year and
I think those were partially caused by the extra maintenance work
caused by the split of c-c and m-c.

I am hoping that the merge would reduce the overall work, but
only the maintenance people of tryservers and build infrastructure can
explain this well.

I believe that many community contributors won't mind firefox/b2g patches
break TB/SeaMonkey.
That is the way of life as I have seen it for the last couple of years.

What I am afraid is that the decision here is to be seen
as the beginning of the end of TB/SeaMonkey by the user community.
I would be inclined to judge it this way :-(


Chiaki Ishikawa

ishikawa

unread,
Apr 9, 2014, 3:25:50 AM4/9/14
to
On (2014年04月09日 14:04), Joshua Cranmer 🐧 wrote:
> since it eliminates the ability to bisect on mozilla-central-induced
> failures.

This is a good point. Currently, there is no way to run bisect effectively
for TB
because it uses two independent/separate hg repositories (one for c-c and
one for m-c).
This setup makes automatic bi-secting impossible (not to mention the
necessity of clever trick to
create patches for both c-c tree and m-c tree
and ask TryServer to understand which patches are for which during submission.)

As Joshua Cranmer stated this move should lessen the burden on the people
who support
the build infrastructure and such, and such relief should not be
underesitmated.
But again, this can be only be emphasized by people who know the
infrastructure inside out.

TIA


Gijs Kruitbosch

unread,
Apr 9, 2014, 4:45:07 AM4/9/14
to Gavin Sharp
On 09/04/2014 05:37, Gavin Sharp wrote:
> On Tue, Apr 8, 2014 at 3:13 PM, Gijs Kruitbosch
> <gijskru...@gmail.com> wrote:
>> Which is why I believe this assumption doesn't hold. What's more, as a
>> Firefox desktop frontend developer, I actually think I would be *more*
>> productive if there were concrete non-Firefox-toolkit-using code in m-c, not
>> only because of atomic patches for toolkit + some consumers, but also
>> because of concrete examples of how toolkit stuff gets used elsewhere.
>
> I don't buy it :) You would not be more productive in making Firefox
> great, you'd be more productive in maintaining the toolkit
> abstractions. That's not really a primary goal (going back to
> Benjamin's axiom #1).

Perhaps not a primary goal, but certainly a secondary goal that's made
my patches more difficult to write and sometimes got them r-'d in the past.

> But we don't actually need to pick one of the two "get rid of toolkit/
> entirely" and "merge all toolkit consumers into m-c" extremes - that's
> a false dichotomy.
>
> Benjamin's arguing that we should get closer to the "get rid of
> toolkit/" extreme than we are now, and that we certainly shouldn't
> take steps in the direction of "merge all toolkit consumers into m-c"
> (as this proposal suggests). I agree with him. I also agree with you
> that trying to get to "get rid of toolkit/ entirely" doesn't have a
> great cost/benefit ratio on its own.

If we're aiming to get rid of toolkit completely, then why are we
keeping it and claiming it's essentially supported? Are you essentially
claiming that we should pay no heed to this distinction and
progressively move code into browser/ ? AFAICT that would be a change in
direction from what we have been doing.

To give concrete examples, some of the Australis customization API
changes have had a long-term plan of "move this to toolkit", and some of
the recent findbar changes might have been simpler if we could have
treated it as a "Firefox-only" component. (nb: I am not intimately
familiar with these changes, but I would be surprised if the opposite
were the case) Almost all of our CSS work has definitely been harder
because of the toolkit split. Being able to aggressively remove bits of
toolkit (or treat it as "this applies to all Firefox windows instead of
just the main browser window like browser.css" rather than "this applies
to all XUL windows in toolkit") would have changed how we did some of
the theme work.

If we're not aiming to get rid of toolkit (considering you said this is
a false choice...), where is the magical "closer to the [remove it]
extreme" point (which isn't the complete removal) that we *are* trying
to get to, and how is it defined?

As Joshua noted further downthread, I was under the impression that we
were maintaining the status quo and "avoiding gratuitous bustage". Even
for that, I think merging would help. Not all toolkit consumers have the
status TB has, and so I'm not sure I agree with your slippery-slope
assertion of this going towards merging all consumers. This was probably
a flaw in how I wrote my previous message, but even so. :-)

~ Gijs

Ben Hearsum

unread,
Apr 9, 2014, 9:12:57 AM4/9/14
to
I'm part of MoCo RelEng. Here's my thoughts from that perspective,
though I don't really have a strong preference either way:

There's no doubt that Thunderbird automation is in worse shape than
Firefox automation - both of which are maintained by MoCo RelEng.

I haven't been involved as deeply in it, but I know that B2G's
repositories have caused some challenges for multiple reasons:
externally hosted, git (instead of hg), as well as being split across
many many (60+) repositories. I don't have a good sense for how painful
the multiple repositories have been vs. the other parts.

From where I sit, the thing that would make things easiest is
consistency. If Thunderbird (for as long as we continue to support it)
lives in a separate repository, it would be easier if all of other
applications did, too. If Firefox is in mozilla-central, it's easier if
Thunderbird is too. Moving Thunderbird into mozilla-central would be
easier for RelEng because the automation that handles that style of
build is much more solid.

- Ben

Chris AtLee

unread,
Apr 9, 2014, 9:29:25 AM4/9/14
to Ben Hearsum, dev-pl...@lists.mozilla.org
On 09:12, Wed, 09 Apr, Ben Hearsum wrote:
>I'm part of MoCo RelEng. Here's my thoughts from that perspective,
>though I don't really have a strong preference either way:
>
>There's no doubt that Thunderbird automation is in worse shape than
>Firefox automation - both of which are maintained by MoCo RelEng.
>
>I haven't been involved as deeply in it, but I know that B2G's
>repositories have caused some challenges for multiple reasons:
>externally hosted, git (instead of hg), as well as being split across
>many many (60+) repositories. I don't have a good sense for how painful
>the multiple repositories have been vs. the other parts.

One approach that we've used to manage this complexity is to include
references to the various B2G repos inside m-c. In a way we're managing
our own submodules via external tooling. E.g. b2g/config/gaia.json
refers to the repository and revision of gaia to use, and we also have
fully specified XML manifests for all of the B2G devices in tree, e.g.
https://hg.mozilla.org/mozilla-central/file/7160658c4be3/b2g/config/emulator/sources.xml

I could see us using the same technique for manging the m-c:c-c
relationship.

Cheers,
Chris
signature.asc

Gervase Markham

unread,
Apr 9, 2014, 12:58:47 PM4/9/14
to Benjamin Smedberg, Justin Wood (Callek)
On 08/04/14 20:24, Benjamin Smedberg wrote:
> * Firefox, Firefox for Android, and B2G are the first priorities of the
> Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.

This is a useful formulation. Perhaps the question we are struggling
with is: to what extent is it reasonable for Mozilla's secondary
commitment to affect the lives and work of people who are not
specifically tasked with meeting that commitment?

I think people would generally agree the answer is "not very much, but
it doesn't have to be zero", but we have different decisions about what
can reasonably be considered to be "not very much". (Perhaps in some
cases because people have different opinions about whether Mozilla
should really still have that secondary commitment in the first place.)

There is also the issue that doing something may reduce the work for
some people (e.g. RelEng) and increase it by a different amount for
others (e.g. people searching DXR who get Thunderbird-related hits), and
how to balance those two without metrics on either the
reduction/increase in work or the relative sizes of population in each
group.

The last issue I would throw into the pot is what I might call "project
charity". We are all on the same team here, and part of the same
community. If my life gets a little more complicated on occasion because
of something someone else is doing, charity and friendliness suggests
that I bear with them to some degree.

I am not going to dispute bsmedberg's assertion that, absent Brendan,
he's the primary decision maker. But it would be awesome if he could
outline what steps might be taken to "get to yes" on this issue. Do you
need a DXR patch so it has a checkbox for "include Thunderbird"?
Something else?

Gerv

Gregory Szorc

unread,
Apr 9, 2014, 4:49:07 PM4/9/14
to Ben Hearsum, dev-pl...@lists.mozilla.org
On 4/4/14, 4:35 AM, Ben Hearsum wrote:
> Your response is pretty much what I was trying to get at (which I did
> poorly, sorry about that).
>
> On 04/03/14 07:38 PM, Mike Hommey wrote:
>>> 3. The tooling doesn't suck (all solutions for subrepos or multi repository
>>> management are significantly worse than single repo experiment).
>>
>> True. But it seems to me the problem is noone actively seeked fixing
>> those problems and just went the "easy" way by putting everything in the
>> same basket. And suffering as a consequence. Which leads to what you're
>> writing next.
>
> Yep. This ship has long sailed, but if Firefox had been moved to another
> repository at the same time as Thunderbird/SeaMonkey (when we moved to
> Mercurial originally IIRC), we would've been heavily invested into
> solving this problems.
>
>>> While I concede that Mozilla's needs are slightly different from that of a
>>> large corporation with a repository behind a firewall, the benefits of
>>> unified repositories remain. The drawbacks (large clone times) can largely
>>> be mitigated through extensions (with Mercurial at least).
>>>
>>> To use a Mozilla example to support claim #2, I'll use mozbase. mozbase is a
>>> suite of Python packages. It's effectively the "Mozilla standard library."
>>> It used to live in GitHub and was merged to mozilla-central periodically.
>>> People working on Python in the tree would often need or want to make
>>> changes to mozbase. They had to commit to Git, wait for a merge to m-c, then
>>> commit whatever changes were depending on it. The process was brutally
>>> agonizing. Often days would go by between mozbase merges. Stop energy was
>>> everywhere. Now, mozbase lives inside mozilla-central. In one atomic commit
>>> I can update mozbase *and* change all in-tree consumers in one go. It's
>>> faster for everybody and makes everyone more productive. It keeps Mozilla
>>> fast and nimble.
>>
>> Except now, it's the other users of mozbase that aren't in m-c that suffer.
>
> +1. It's hard for people to get the tools that are embedded into our
> massive repo, and it's easy to accidentally (or on purpose) depend on
> completely unrelated things, making them useless to others.

What do people need to do?

Grab snapshots? You can grab an archive from a sub-directory via the
Mercurial web interface. But it requires upgrading our Mercurial server
to 2.6 or later.

Lots of the in-tree things are Python packages and available via PyPI.
If we aren't releasing to PyPI enough, that's an addressable concern.

If there are dependency concerns, that sounds like a problem that could
be enforced via testing.

There was *lots* of discussion about moving mozbase into the tree. In
the end, optimizing for Firefox/in-tree development (the largest
consumer of mozbase) was a major driver. As I said, other companies
apply this same reasoning w.r.t. operating monolithic repositories.

If a tool/library becomes too big, we can always move active development
of it outside the tree and perform periodic imports into
mozilla-central. While I feel this is less optimal for Firefox
development, it is certainly doable, as NSS and NSPR have shown.

The cited problems seem to be minor from my perspective. They don't seem
to overrule the importance of optimizing the Firefox development
workflow, where 1% changes in developer productivity multiplied by
hundreds of salaried developers amounts to millions of dollars and
faster development times.

Matthew N.

unread,
Apr 9, 2014, 7:24:42 PM4/9/14
to
On 4/8/14, 1:56 AM, Philipp Kewisch wrote:
> On 4/8/14, 9:34 AM, Matthew N. wrote:
>> On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote:
>>> 1. Conflation of Firefox code with not-Firefox code.
>>
>> I'd like tooling such as MXR to be updated to exclude whatever
>> directories would be added from comm-central so I don't have to spend
>> extra time ignoring them. Ideally they would be under one top-level
>> directory to make this easy.
>
> I did mention earlier that it would indeed be nice to influence ordering
> so that its easier to group by product, but ignoring the whole directory
> doesn't seem like the right solution to me? If this is done anyway, then
> it would in turn be nice to ignore browser/mobile/b2g when searching for
> (former) c-c code.

http://mxr.mozilla.org/comm-central/ could be updated to index m-c but
not ignore those directories. This way no change would be needed to
developer's existing workflows.

MattN

Philip Chee

unread,
Apr 10, 2014, 2:05:59 AM4/10/14
to
On 09/04/2014 12:47, Doug Turner wrote:

> Lastly and somewhat related - people use code search to figure out how
> to do something. I would hate for them to find bits of
> old/incorrect/crufty SeaMonkey code (which has a LOC / Contributing
> Engineer ratio approaching INF). I am not sure if Thunderbird is
> similar but I suspect so.

I want to point out that in the past KaiRo has filed Firefox bugs to
"fix issues discovered when porting [Firefox feature] to SeaMonkey". So
sometimes that incorrect/crufty code *is* Firefox code, and SeaMonkey
does it the right way.

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.

Robert Kaiser

unread,
Apr 10, 2014, 11:17:06 AM4/10/14
to
Philip Chee schrieb:
> I want to point out that in the past KaiRo has filed Firefox bugs to
> "fix issues discovered when porting [Firefox feature] to SeaMonkey". So
> sometimes that incorrect/crufty code *is* Firefox code, and SeaMonkey
> does it the right way.

I'm not sure on "the right way", though a secondary review by SeaMonkey
reviewers has sometimes brought forward some actual bugs, and we did
actually port the fixes back, so the code is the same now. A numbers of
times it's been coding style differences enforced by SeaMonkey
reviewers. And other times, like with sanitize, we ported code that was
supposed to land in Firefox but never did (making it a .jsm) - in many
cases, what I ported years ago is now an old version of Firefox code,
though, and badly would need a pile of other patches to be ported on top.

KaiRo


Zack Weinberg

unread,
Apr 10, 2014, 1:13:21 PM4/10/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/08/2014 03:24 PM, Benjamin Smedberg wrote:
...
> Zack has mentioned that some of his patches got hung up because of
> concerns about affecting comm-central. I don't know the details,
> but I will strongly assert that this means we should be more
> aggressive about *removing* code, not that this is an argument for
> merging them more.

For concreteness: the only one still not resolved is bug 650960. (See
specifically comments 18 through 27. Subsequent discussion is all
related to a part of the patch that I thought could land separately,
but there turned out to be no point without the rest of it.)

That is in fact an attempt to remove code which everyone agrees is bad
(at least from a UI perspective) and for which a sane replacement
exists -- considering only Firefox. However, the replacement is not
available in comm-central apps. Under current policy I think I
would've been technically entitled to go ahead and land the patch, but
I don't think it would have been courteous to do so.

I think that if comm-central were merged into moz-central it would be
*dramatically* easier to unjam this bug, because there would no longer
be an artificial boundary discouraging people from adopting new
toolkit functionality in SM and TB. I could just do it myself if no
one got to it first.

zw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTRtEvAAoJEJH8wytnaapkVz4QAIqbRG3cCdgje0Hqmw+makx+
Y9E3bD9sDvvnxSXukCNQcE2YVN4qVr5UTmX5vRZGUww3nkUeebLzk8lWOw13rPFr
RrAI9MADZBBs9tBe6dczZBO+M53I55oZPZDrrIDm3/OvepUcL4zOFnMDewZGdsCp
peZxv6stXyOzM/dm3GDBlRaktr7YaxqeQ9c2XZlTqn+V+7p6AsNsOH+Z7D7FaTjP
0FGCDByIfqMuGJmkG0DKqWrtcVe4aYap/mAEvUP8p6M9Kd1GP99Q637p0g3sQUxI
+7N1a7LQUNJ77I2dgIYUZ1HBjSFxaK+Ue++Bu15A869jNCGq1nKe1envaOgDVA9j
epW/Oc2KA7ufBuDD/fWfWseNhxz7TdCUn5owAOROC1USLJdHyqCfZO5wpd5zu3pc
NOhA21IQ+Hqg+PoRhH4xyT1QkzrP91MMSNpvk+EWz7RyPY9TL9y9q/sBT/oytd6g
RZc3EkiqjkvvixaoSk8Ov1+wiSc1V503NA6LNxlrL6KNz2doBaqLwOAKOConyJ0e
FMWWuMWx/2amwic6Wpz3ni/5qgwVLbCG1xhLp+phWFlRYVzpJayucfXmlQQ+pHO8
Wx/sVwAynCNiorvwoEOBx0Jkj3vw0KQcOpYD7HlvIKbEjKpZwm1dNjlt9WPvLHmh
XuV83wzzrN740N+yQMCF
=3TS5
-----END PGP SIGNATURE-----

Gavin Sharp

unread,
Apr 10, 2014, 6:40:20 PM4/10/14
to Gijs Kruitbosch, dev. planning
On Wed, Apr 9, 2014 at 1:45 AM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> If we're aiming to get rid of toolkit completely, then why are we keeping it
> and claiming it's essentially supported? Are you essentially claiming that
> we should pay no heed to this distinction and progressively move code into
> browser/ ? AFAICT that would be a change in direction from what we have been
> doing.

Like I tried to say in my previous post, "get rid of toolkit
completely" is not a goal in and of itself. We should stop dedicating
effort to creating a generic cross-platform app runtime and toolkit,
and we should not let toolkit-purity issues hamper us from making
Firefox better. Both of those things fall short of "actively work to
kill toolkit and anyone who depends on it", which I don't think is
reasonable.

> To give concrete examples, some of the Australis customization API changes
> have had a long-term plan of "move this to toolkit", and some of the recent
> findbar changes might have been simpler if we could have treated it as a
> "Firefox-only" component. (nb: I am not intimately familiar with these
> changes, but I would be surprised if the opposite were the case) Almost all
> of our CSS work has definitely been harder because of the toolkit split.
> Being able to aggressively remove bits of toolkit (or treat it as "this
> applies to all Firefox windows instead of just the main browser window like
> browser.css" rather than "this applies to all XUL windows in toolkit") would
> have changed how we did some of the theme work.

In general, we should take those shortcuts where we can. Devil is in
the details. Please raise and encourage others to raise these specific
"toolkit is making my life difficult" cases on firefox-dev and we can
discuss further.

> Not all toolkit consumers have the status TB
> has, and so I'm not sure I agree with your slippery-slope assertion of this
> going towards merging all consumers. This was probably a flaw in how I wrote
> my previous message, but even so. :-)

I wasn't suggesting that it's a slippery slope - I agree with you that
it isn't. I was just using an extreme example, because I was talking
about the extremes. I think taking just one step "down the slope" is
probably too far, though.

Gavin

Neil

unread,
Apr 11, 2014, 3:37:02 AM4/11/14
to
Zack Weinberg wrote:
> (How about we ... ban compiled-code XPCOM components that aren't
> linked into libxul? Half kidding.)
Firefox actually ships at least one "external" compiled-code XPCOM
component.

--
Warning: May contain traces of nuts.

Henri Sivonen

unread,
Apr 11, 2014, 8:54:24 AM4/11/14
to dev. planning
On Tue, Apr 8, 2014 at 10:24 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> * We have a secondary commitment to provide security and maintenance updates
> to Thunderbird.
...
> Zack has mentioned that some of his patches got hung up because of concerns
> about affecting comm-central. I don't know the details, but I will strongly
> assert that this means we should be more aggressive about *removing* code,
> not that this is an argument for merging them more.

In the case of the code I want to remove from m-c, not accommodating
c-c at the time of removal by just letting c-c burn and expecting c-c
devs to figure it out would be both be terribly
impolite/confrontational and contrary to the commitment to provide
maintenance update to Thunderbird.

That is to say, I don't think it's realistic to just remove code from
m-c and let c-c burn in fundamental ways (like IMAP not working or
non-ASCII letters in email being broken). When that's not realistic,
the ease of moving code from m-c to c-c becomes relevant. It would be
easier in a single-repo setting. The current setup means that it takes
even more developer time to do removals, since you not only need to
make the m-c removal patch but you need to deal with the weirdness of
m-c patches on TB try, etc.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

Zack Weinberg

unread,
Apr 11, 2014, 11:47:39 AM4/11/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/11/2014 03:37 AM, Neil wrote:
> Zack Weinberg wrote:
>> (How about we ... ban compiled-code XPCOM components that aren't
>> linked into libxul? Half kidding.)
> Firefox actually ships at least one "external" compiled-code XPCOM
> component.

My knee-jerk reaction is that we should stop doing that, but perhaps
there is a compelling reason?

zw

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTSA6ZAAoJEJH8wytnaapkRYMP/2+ivVzs4VugQp4lQfpxihqF
zAAJqMAyFbWWJ5aB5xDVT0CjvatdxoRDhRPbwNg8F1IRG5uUbxc3tuh0WmtJzX3x
UvfrgYGIdBkuwUDErHHJW02Xo0IsMRUedr1nOYnGEgB4aTLi/boqGQi/dq6sKM5d
szJqgz2WyhNHitL6o5UnZ7tvz8iTgpq7q15SReB0Ix8TMWkc7u/Y/Ew9BB3jvqHX
tke7UxNxdHwQe52PWhae84ijyg7jUzinQyUYdAO+6dLVzrCpeUKisl6BmZj0FFSA
gXo2QSiUdQ9uGnsdgAFwSck0FyHsJDUQOReDie0efMoyOD+sn2HQi1iiPJIl9KtS
rTgvL6HX/IiEbBPXYTEVIa02908q8FatMEJJCbQOIe4uU8kUFxLR3JCnQapSQk5G
vFHyz5BKogOpN5aK+C9BfErtVVn7LfnJItxAbVxFDXEG9TTfvvGLXabQewn/cB7g
PIKcnLbB16hto4rCExGcO2VVDj6+wq/kdxqkAtXVWobALvk0xW/NZIwwt0rc8fz2
YTX3ItPraGa6fVpCxp9+rGuyO+mnRCspo9EH+c7ky21klOnJmSpQuIi1O6vTkNeb
F8zovLlgR83vvKmMx1bJtsSlPNzjs99AXUV4+MRLNVB+BgpFF+4+5CNhop+Eg2pj
PsetLVbYWmM9utzfYhcn
=5naI
-----END PGP SIGNATURE-----

alta88[nntp]

unread,
Apr 11, 2014, 1:02:30 PM4/11/14
to
+1

This decision is being made at the wrong pay grade, with the wrong micro
focus.

The reasons given are contrived to create goal seeked bullet points from
an existing bias. An honest cost-benefit has not been performed; some
of the hidden costs have already been mentioned.

What cost has not been considered is the inevitable headline "Mozilla
Reneges on Promise to Support Thunderbird; Remaining Developers Abandon It.

Some opponents of this plan have posted here with the Thunderbird UA;
this is puzzling - perhaps switching to a new mail client is a lesser
productivity sink than the tremendous problem of seeing /comm in an mxr
search?

Benjamin Smedberg

unread,
Apr 11, 2014, 1:20:58 PM4/11/14
to Gervase Markham, Justin Wood (Callek), mozilla.dev.planning group
On 4/9/2014 12:58 PM, Gervase Markham wrote:
> I am not going to dispute bsmedberg's assertion that, absent Brendan,
> he's the primary decision maker. But it would be awesome if he could
> outline what steps might be taken to "get to yes" on this issue. Do
> you need a DXR patch so it has a checkbox for "include Thunderbird"?
> Something else? Gerv

I still believe that the best and fastest solution here is to merge m-c
into comm-central so that there is a single tree with all the sources
but don't push that merge to mozilla-central. In terms of local
development with MQ at least, it is pretty trivial to split patches into
two pieces, the part that touches comm/ and the part which doesn't. I
know jcranmer still has concerns about this, but it doesn't seem to me
any more complicated than the existing two-repo structure. And as a
bonus, we could still decide to merge the repos in the future. The only
technical issue I can think of is you probably want a server hook to
prevent people committing gecko changes only into comm-central.

In the other case, we would need the following things:

* exclude the comm/ tree in the local checkout by default
* make DXR/MXR index the Firefox-only sources by default
* make sure that comm-only commits don't trigger Firefox builds (on
mozilla-central)
* make sure that local bisection tools ignore comm-only commits

--BDS

Justin Wood (Callek)

unread,
Apr 11, 2014, 3:51:47 PM4/11/14
to
On 4/11/2014 1:20 PM, Benjamin Smedberg wrote:
> On 4/9/2014 12:58 PM, Gervase Markham wrote:
>> I am not going to dispute bsmedberg's assertion that, absent Brendan,
>> he's the primary decision maker. But it would be awesome if he could
>> outline what steps might be taken to "get to yes" on this issue. Do
>> you need a DXR patch so it has a checkbox for "include Thunderbird"?
>> Something else? Gerv
>
> I still believe that the best and fastest solution here is to merge m-c
> into comm-central so that there is a single tree with all the sources
> but don't push that merge to mozilla-central. In terms of local
> development with MQ at least, it is pretty trivial to split patches into
> two pieces, the part that touches comm/ and the part which doesn't. I
> know jcranmer still has concerns about this, but it doesn't seem to me
> any more complicated than the existing two-repo structure. And as a
> bonus, we could still decide to merge the repos in the future. The only
> technical issue I can think of is you probably want a server hook to
> prevent people committing gecko changes only into comm-central.

Only that the merge to comm-only completely eliminates the ability to
bisect. Its hard today, but still possible, in your suggestion its not.

> In the other case, we would need the following things:
>
> * exclude the comm/ tree in the local checkout by default

Given the disk space/usage evaluation by jcranmer I don't actually see
why this is a requirement nor can I see how it can be *easily* possible
in todays mercurial versions, can you elaborate please.

> * make DXR/MXR index the Firefox-only sources by default

I can easily do this for MXR, unsure of what it takes for DXR.

> * make sure that comm-only commits don't trigger Firefox builds (on
> mozilla-central)

We already have instrumentation in buildbot to support this, and I'd go
one step further than browser/ or b2g/ checkins don't trigger
Thunderbird builds.

> * make sure that local bisection tools ignore comm-only commits

Considering the vast array of local bisection tools, and how bisection
actually works, I don't forsee this as a real tangible goal, nor
necessarily a good one.

Bisects that mark comm-only commit (a) as good will easily be able to
traverse to/from non-gecko commits using their appropriate bisection
logic that can properly narrow down to the correct commit.

~Justin Wood (Callek)

Trevor Saunders

unread,
Apr 11, 2014, 4:24:58 PM4/11/14
to Justin Wood (Callek), dev-pl...@lists.mozilla.org
On Fri, Apr 11, 2014 at 03:51:47PM -0400, Justin Wood (Callek) wrote:
> On 4/11/2014 1:20 PM, Benjamin Smedberg wrote:
> >On 4/9/2014 12:58 PM, Gervase Markham wrote:
> >>I am not going to dispute bsmedberg's assertion that, absent Brendan,
> >>he's the primary decision maker. But it would be awesome if he could
> >>outline what steps might be taken to "get to yes" on this issue. Do
> >>you need a DXR patch so it has a checkbox for "include Thunderbird"?
> >>Something else? Gerv
> >
> >I still believe that the best and fastest solution here is to merge m-c
> >into comm-central so that there is a single tree with all the sources
> >but don't push that merge to mozilla-central. In terms of local
> >development with MQ at least, it is pretty trivial to split patches into
> >two pieces, the part that touches comm/ and the part which doesn't. I
> >know jcranmer still has concerns about this, but it doesn't seem to me
> >any more complicated than the existing two-repo structure. And as a
> >bonus, we could still decide to merge the repos in the future. The only
> >technical issue I can think of is you probably want a server hook to
> >prevent people committing gecko changes only into comm-central.
>
> Only that the merge to comm-only completely eliminates the ability to
> bisect. Its hard today, but still possible, in your suggestion its not.

The tools seriously suck for this, but I don't think its *impossible*.
Imagine you have a commit merging in m-c that you know introduced a bug.
now you have a bunch of commits to bisect over, and in principal you
have a commit for which comm/ should build with all of the commits in
m-c. Now take $x to be a commit in m-c you wish to test and $y to be a
commit for which comm/ should build with m-c from $x. you can then run
git checkout $x; git checkout $y -- comm/ then you can test $x with
comm/ stuff.

> >* make sure that local bisection tools ignore comm-only commits
>
> Considering the vast array of local bisection tools, and how bisection
> actually works, I don't forsee this as a real tangible goal, nor necessarily
> a good one.

It seems pretty possible to me, you just have to filter out certain
commits before you pick the one you want to test. Now that can be a
foot gun, but it could be pretty generally useful too e.g. consider
commits that only change docs.

Trev

>
> Bisects that mark comm-only commit (a) as good will easily be able to
> traverse to/from non-gecko commits using their appropriate bisection logic
> that can properly narrow down to the correct commit.
>
> ~Justin Wood (Callek)
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
signature.asc

Justin Wood (Callek)

unread,
Apr 11, 2014, 4:55:20 PM4/11/14
to
No, its not, we have build system things that need to change throughout
the tree, configure, etc.

So if we have a branch point that is m-c-only and hundreds of commits,
and a single merge point that builds c-c we can't bisect inside those
hundreds-of-commits.


>>> * make sure that local bisection tools ignore comm-only commits
>>
>> Considering the vast array of local bisection tools, and how bisection
>> actually works, I don't forsee this as a real tangible goal, nor necessarily
>> a good one.
>
> It seems pretty possible to me, you just have to filter out certain
> commits before you pick the one you want to test. Now that can be a
> foot gun, but it could be pretty generally useful too e.g. consider
> commits that only change docs.
>

Sure, if local devs choose to filter out, its the "by default" that is
hard. And which tools (note ben used the plural) here that bothers me,
which tools. how do we ensure the people ben cares about get updated,
etc. etc. etc.?

~Justin Wood (Callek)

Justin Dolske

unread,
Apr 11, 2014, 5:36:54 PM4/11/14
to
On 4/11/14 10:02 AM, alta88[nntp] wrote:

> What cost has not been considered is the inevitable headline "Mozilla
> Reneges on Promise to Support Thunderbird; Remaining Developers Abandon It.

It's been nearly 2 years since Thunderbird was transitioned to a
community project. AFAIK there was never any explicit timeframe for how
long quasi-official support would continue. I'm not proposing we drop it
today, but 2 years is a long time in the software world... It would be
entirely reasonable for Mozilla to now reconsider how much longer (if
any) it will continue to resource TB.

Justin

Gregory Szorc

unread,
Apr 11, 2014, 5:51:51 PM4/11/14
to Justin Wood (Callek), dev-pl...@lists.mozilla.org
It depends how you are doing the "merge." Can't you merge every single
changeset from m-c into c-c? i.e. instead of overlaying m-c @ tip
periodically, you essentially perform an |hg export -r
lastchangeset::tip | hg import -|? The "convert" hg extension can manage
this for you. While you may push hundreds of changesets at a time,
you'll have a 1:1 mapping of commits (albeit with different hashes) for
you to bisect over. You run into problems with automation bustage (you
probably want to hold off "merging" m-c into c-c while c-c is burning).
But I think the problems are manageable.

This method is still a little crummy due to the way m-c merges work. If
I have my way, autoland will enable a more linear m-c and we'll do away
with integration repositories and merge commits almost completely (I
want m-c to have a perfectly linear history with no merges and no
backouts). I don't expect that to happen within a year though.

Mike Hommey

unread,
Apr 11, 2014, 8:24:15 PM4/11/14
to Benjamin Smedberg, mozilla.dev.planning group, Justin Wood (Callek), Gervase Markham
On Fri, Apr 11, 2014 at 01:20:58PM -0400, Benjamin Smedberg wrote:
> On 4/9/2014 12:58 PM, Gervase Markham wrote:
> >I am not going to dispute bsmedberg's assertion that, absent Brendan, he's
> >the primary decision maker. But it would be awesome if he could outline
> >what steps might be taken to "get to yes" on this issue. Do you need a DXR
> >patch so it has a checkbox for "include Thunderbird"? Something else? Gerv
>
> I still believe that the best and fastest solution here is to merge m-c into
> comm-central so that there is a single tree with all the sources but don't
> push that merge to mozilla-central. In terms of local development with MQ at
> least, it is pretty trivial to split patches into two pieces, the part that
> touches comm/ and the part which doesn't. I know jcranmer still has concerns
> about this, but it doesn't seem to me any more complicated than the existing
> two-repo structure. And as a bonus, we could still decide to merge the
> repos in the future. The only technical issue I can think of is you probably
> want a server hook to prevent people committing gecko changes only into
> comm-central.
>
> In the other case, we would need the following things:
>
> * exclude the comm/ tree in the local checkout by default
> * make DXR/MXR index the Firefox-only sources by default
> * make sure that comm-only commits don't trigger Firefox builds (on
> mozilla-central)

* make sure that only comm-only commits trigger Thunderbird builds
(otherwise, Thunderbird builds are going to suck a lot more infra than
they do today)

Mike

Joshua Cranmer 🐧

unread,
Apr 11, 2014, 10:30:58 PM4/11/14
to
On 4/11/2014 4:51 PM, Gregory Szorc wrote:
> It depends how you are doing the "merge." Can't you merge every single
> changeset from m-c into c-c? i.e. instead of overlaying m-c @ tip
> periodically, you essentially perform an |hg export -r
> lastchangeset::tip | hg import -|? The "convert" hg extension can
> manage this for you. While you may push hundreds of changesets at a
> time, you'll have a 1:1 mapping of commits (albeit with different
> hashes) for you to bisect over. You run into problems with automation
> bustage (you probably want to hold off "merging" m-c into c-c while
> c-c is burning). But I think the problems are manageable.

I know you're trying to help, but I'd like to ask you to step back for
moment and ask if you would be willing to impose this kind of repository
management requirements on normal Firefox development. The development
ergonomics of comm-central is presently already in much worse situations
than most mozilla-central developers would be willing to tolerate, and I
think mozilla-central developers are far more willing to mandate
completely unergonomic procedures for comm-central than they would
tolerate on mozilla-central. In contrast, very many of the people
advocating poor ergonomics for comm-central are trying to push for
better developer ergonomics in mozilla-central.

...

This thread is getting very hard for me to participate in, since (to me)
my concerns are not being addressed or even acknowledged, and my
frustration is reaching the point where it is hard to remain civil. This
isn't meant to be directed at anyone in particular (at least, I'd like
to believe so).

Gavin Sharp

unread,
Apr 12, 2014, 11:20:06 AM4/12/14
to Joshua Cranmer 🐧, dev. planning
On Fri, Apr 11, 2014 at 10:30 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
> I know you're trying to help, but I'd like to ask you to step back for
> moment and ask if you would be willing to impose this kind of repository
> management requirements on normal Firefox development. The development
> ergonomics of comm-central is presently already in much worse situations
> than most mozilla-central developers would be willing to tolerate, and I
> think mozilla-central developers are far more willing to mandate completely
> unergonomic procedures for comm-central than they would tolerate on
> mozilla-central.

I think "completely unergonomic" is an exaggeration in this case, but
I definitely am willing to tolerate comm-central development being
"less ergonomic" if that has significant positive impact on Firefox. I
don't think that's unreasonable, given bsmedberg's base axioms.

("significant" and "completely" are subjectivity-introducing
modifiers, which really goes to the heart of the disagreement here. It
seems unlikely that discussion alone will bring closer the two
perspectives.)

Gavin

Justin Wood (Callek)

unread,
Apr 12, 2014, 7:56:29 PM4/12/14
to
To me this was an obvious given, but I'd love the ability to trigger
jobs on arbitrary csets that didn't get jobs triggered on (piggybacking
support on other tree-sanity measures releng does, not writing new
one-off stuff, fwiw)

~Justin Wood (Callek)

Gervase Markham

unread,
Apr 14, 2014, 4:53:31 AM4/14/14
to Justin Dolske
On 11/04/14 22:36, Justin Dolske wrote:
> It's been nearly 2 years since Thunderbird was transitioned to a
> community project. AFAIK there was never any explicit timeframe for how
> long quasi-official support would continue. I'm not proposing we drop it
> today, but 2 years is a long time in the software world... It would be
> entirely reasonable for Mozilla to now reconsider how much longer (if
> any) it will continue to resource TB.

Given what happened last time when rumours of TB's death began to
circulate, can we all avoid raising that spectre again in an
unstructured fashion?

If you feel strongly that we should reconsider our level of support for
TB, probably the safest first route is an email to the Thunderbird
leads, so at least they know you are starting a discussion.

Gerv


Nicholas Nethercote

unread,
Apr 14, 2014, 4:52:53 PM4/14/14
to Justin Dolske, dev. planning
On Sat, Apr 12, 2014 at 7:36 AM, Justin Dolske <dol...@mozilla.com> wrote:
>
> 2 years is a long time in the software world.

No it's not.

The technical aspects of this decision have been discussed to death,
so I won't say anything about that. I am surprised, however, by how
heartless the discussion has been.

Nick

Boris Zbarsky

unread,
Apr 16, 2014, 1:38:56 PM4/16/14
to
On 4/16/14 1:06 PM, Florian Quèze wrote:
> There's a huge difference between "not being well-supported" (which I
> think Patrick has perfectly accepted) and having people actively
> advocating to make your work needlessly difficult.

The key point of disagreement here seems to be about the word "needlessly".

-Boris
It is loading more messages.
0 new messages