Re: Merging comm-central into mozilla-central

[antoine . mechelynck]

After reading this whole long thread (though I daresay I've read some parts of 
it "diagonally") I learned in it that the official MoCo policy is that Firefox 
developers must NEVER spend time (or at least company time) on giving the least 
help to Thunderbird and SeaMonkey. This made me sad but didn't really surprise 
me.

I also noticed that some Firefox developers don't apply that directive to the 
letter and it made me think that all hope isn't left.

To me, anything that can make work easier for everyone is a plus, and reducing 
friction is IMHO one important way of making work easier. If merging the 
repositories reduces duplication of work, so much the better. OTOH, if it 
requires special and costly hacks to make sure that Firefox, Thunderbird, 
Lightning, and, if it gets integrated too, ChatZilla (which is distributed as 
part of SeaMonkey, is written in XUL and JS, but lived in a separate hg 
reopsitory last time I looked) can all build correctly, then it should be 
avoided. I'm not competent enough to judge between these two possibilities.

But as a QA peer for SeaMonkey, I have made it my policy (which doesn't depend 
on anyone else's decisions because I'm not paid for it) to help other projects' 
developers to the measure of my capacities. When I move a bug originally filed 
in SeaMonkey::General to someplace in MailNews Core, Toolkit or Core (or 
anywhere else but these are the most frequent non-Suite-specific Products for 
such bugs) I follow that bug for all its life, help debugging it if I can, and 
contribute to VERIFYing it on SeaMonkey when it's FIXED. To me this is simple 
courtesy (helping other people, e.g. Firefox people, who happen to have the 
same problems as I do) and it is also in my own interest (to check how bugs 
affecting SeaMonkey but originating in Core, Toolkit, etc., get fixed -- or 
don't, as the case may be. For this reason I will go on helping the MoCo 
developers of common code to the best of my abilities even if the reciprocal is 
in general not true.

It has been asked if the SeaMonkey developers were committed to go on 
maintaining SeaMonkey even if and when c-c and m-c get merged, and SeaMonkey 
Council members have said yes. That was also the impression I had: we are 
committed to keeping SeaMonkey alive and up to date as long as we possibly can 
regardless of where its code lives, even though the people who maintain 
SeaMonkey are few, and they are all doing it in their spare time even though 
some of them (two, I think; maybe three) also have jobs at MoCo which, 
admittedly, probably teach them important stuff about the Mozilla (including 
SeaMonkey) code in general even when they're earning their daily bread working 
on Firefox. But the "don't care if you break comm-central" policy is not 
helping us, and the recent news about altogether scrapping full-fledged 
extensions, complete themes, and even XUL in general has caused us quite some 
trepidation. AFAIK, the current consensus is that we'll go on using the same 
Gecko and Tool
 kit code as Firefox as long as it remains humanly possible considering the 
kind of Suite we want to have. But we are not at all sure that it will remain 
possible even for two years, and we don't like the prospect at all. We'd prefer 
to have less forked code (including both "application code" and "build tools 
code") rather than more, but not at the price of losing what makes SeaMonkey 
stand out as "the best SeaMonkey we can make".


Best regards,
Tony.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[callek]

Noteworthy, elsewhere in this thread, I did state that while I am a MoCo paid 
staff member, working in Release Engineering. and while this would NOT be part 
of my paid duties.

I *did* state that I really want this bad enough that I'd volunteer to work on 
and complete the Release Engineering portions as required in my free time.  So 
while I would agree no-one in "moco Release is going to futz with it [in order 
to earn a paycheck]" I've said that I would commit to fixing up the Release 
infra if this was greenlit.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central (summary v1)

[Yonggang Luo]

From my points of view, merging thunderbird back into mozilla source tree
is not a good idea.
And I think we need to html-ize the Thunderbird source tree, and remove the
C/C++ dependencies to gecko as much as possible.
And merging the comm back into mozilla-central is getting comm to be to BIG
to maintain.

I suggest to getting comm into github, and moving all the related issues
into github but not mozilla bugzilla, that's too hard to
creating a pull request and contributing codes.

Indeed, I think the best way is to reactive the gecko xulrunner,
and getting Thunderbird only dependence to XULRunner,
And the thunderbird only need to compitable with the most  ESR released
version
of XULRunner, and doesn't need to tracing the mozilla gecko patches in such
a fast way.
They are running in totally different patching speed.



On Fri, Nov 6, 2015 at 11:32 PM, ISHIKAWA,chiaki 
wrote:

> On 2015/10/27 9:06, Philipp Kewisch wrote:
>
>> Hi all,
>>
>> I'd love to see if we can move towards an agreement. For those of you
>> that would prefer not to merge, I'd love to hear what your absolute
>> minimum requirements would be that you'd accept a merge with. Changes to
>> hg? Changes to dxr? A policy chanage? If we can establish clear
>> requirements, maybe we can see they are not so hard to fulfill and we
>> can come to an agreement quickly. Ideally, I'd like to find a middle
>> ground here that is acceptable to everyone.
>>
>> Let me summarize requirements I have read:
>>
>> * Thunderbird bustages should not close Firefox trees
>> * A version of dxr that does not show comm projects
>> * A version of dxr that shows all projects
>> * Treeherder remains separate
>> * Normal m-c try pushes don't automatically build Thunderbird
>> * There should be a commitment that comm projects will be regularly
>> maintained at least in the foreseeable future
>>
>> * Thunderbird builds should not run on every m-c/m-i commit
>> * The default checkout should not contain comm projects
>> * It does not make sense if Thunderbird will be separate short term
>> * There should be least amount of pressure to fix Thunderbird things for
>> Firefox contributors
>>
>>
>> If these are the requirements, with the exception of narrow clones which
>> as I've understood are not stable yet, I believe they are all fairly
>> easy to fulfill.
>>
>> Are there any other requirements I've missed?
>>
>> Philipp
>>
>>
> I think the above summarizes the discussions and counter-points raised
> rather well.
>
> Although I don't hear from many volunteers who send in TB patches
> occasionally
> in this thread, I believe many of them would work hard to make the
> following a reality:
>
> > There should be a commitment that comm projects will be regularly
> > maintained at least in the foreseeable future
>
> [Of course, there is NO contract by the user community, so "commitment" is
> a rather
> vague term here. I can't speak for others.]
>
> I, for one, use TB for regular work at the office and at home regularly,
> and
> have come to depend on it. So any serious bugs that I find (and there are
> many
> unfortunately) *HAVE* to be fixed eventually and so I try to send patches.
> Some may send in patches to fix these bugs, and others may send in patches
> to bring in new features. But if there are a million users out there,
> I bet there are a couple hundred volunteers who can program. (I think
> there was a statistics
> compiled by someone to show the user community contribution in terms of
> patches sent in
> by individuals in the last few years after Mozilla foundation put TB at
> the mercy of
> user community.)
>
> And to make this maintenance easier (less breakage of tree herder
> compilation, less duplication of slightly different similar documents
> etc.), the merge is preferable from the standpoint of developers IMHO.
>
> TIA
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Nov 6, 2015 at 1:46 PM, Mike Hommey  wrote:

> On Fri, Nov 06, 2015 at 01:12:30PM -0600, Joshua Cranmer ? wrote:
> > On 11/6/2015 12:38 PM, Doug Turner wrote:
> > >I would have rather done this in a private email, but some replied and
> said I wasn’t clear.
> > >
> > >
> > >-> Do not merge comm-central into mozilla-central <-
> > >
> > >
> > >1) I think merging comm-central is a bad idea as it will basically tax
> all gecko + firefox developers forever.
> > >
> > >2) It isn’t clear that Thunderbird is a supported product anymore.
> MoCo certainly isn’t responsible for it.  I don’t think MoFo does anything
> for it.
> >
> > I know that Thunderbird has been in talks with the Mozilla Foundation
> about
> > being officially supported by them, and I believe the only thing left is
> to
> > sign the ink on some papers for that. There are others who were involved
> in
> > those talks who could give more specific details.
> >
> > >3) We’re spending $ and time in Release on this project.  I would
> rather not have to do that given (2).
> > >
> > >4) This sets a bad precedent.  I don’t think we want every application
> built on top of gecko to be in mozilla-central.
> >
> > I've explained why this isn't really a precedent several times.
> > >
> > >
> > >We don’t have all of the time and resources in the world.  We have to
> be very deliberate about what we work on.  And Thunderbird — as it is now —
> isn’t something MoCo is focusing on.  Because of this, I really doubt
> anyone in moco Release is going to futz with it.
> >
> > Except the release engineers in moco are already spending a good deal of
> > time on managing the Thunderbird release engineering--exactly as Mozilla
> > promised they would back in 2012.
>
> And other moco engineers are wasting time because of the status quo (and
> I won't detail here because that's been covered in the thread already).
>
> Whether it happens in mozilla-central or somewhere else, this merge
> *will* have to happen at some point.


What about creating a "project branch" repository for comm-central that has
the same root commit as mozilla-central? (This was discussed earlier in the
thread.) We periodically merge mozilla-central into this repo but never the
other way, thus isolating mozilla-central from comms foo.

This does impact the ability to bisect projects independently. But it does
enable code migration to occur easier since cherry picks and merges are
easy. It also theoretically allows anyone to create and test commits on a
"unified" repo. If/when we do get the green light to merge comm-central, it
should just be a merge commit into mozilla-central.

I think this gets us to a better position without fully exposing people who
don't care about comm-central. This transition could occur whenever: it's
up to the comm-central folks to green light it and make the infrastructure
changes to support it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 11/6/2015 12:38 PM, Doug Turner wrote:

I would have rather done this in a private email, but some replied and said I 
wasn’t clear.


-> Do not merge comm-central into mozilla-central <-


1) I think merging comm-central is a bad idea as it will basically tax all 
gecko + firefox developers forever.

2) It isn’t clear that Thunderbird is a supported product anymore.  MoCo 
certainly isn’t responsible for it.  I don’t think MoFo does anything for it.


I know that Thunderbird has been in talks with the Mozilla Foundation 
about being officially supported by them, and I believe the only thing 
left is to sign the ink on some papers for that. There are others who 
were involved in those talks who could give more specific details.



3) We’re spending $ and time in Release on this project.  I would rather not 
have to do that given (2).

4) This sets a bad precedent.  I don’t think we want every application built on 
top of gecko to be in mozilla-central.


I've explained why this isn't really a precedent several times.



We don’t have all of the time and resources in the world.  We have to be very 
deliberate about what we work on.  And Thunderbird — as it is now — isn’t 
something MoCo is focusing on.  Because of this, I really doubt anyone in moco 
Release is going to futz with it.


Except the release engineers in moco are already spending a good deal of 
time on managing the Thunderbird release engineering--exactly as Mozilla 
promised they would back in 2012.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central (summary v1)

[ISHIKAWA,chiaki]

On 2015/10/27 9:06, Philipp Kewisch wrote:

Hi all,

I'd love to see if we can move towards an agreement. For those of you
that would prefer not to merge, I'd love to hear what your absolute
minimum requirements would be that you'd accept a merge with. Changes to
hg? Changes to dxr? A policy chanage? If we can establish clear
requirements, maybe we can see they are not so hard to fulfill and we
can come to an agreement quickly. Ideally, I'd like to find a middle
ground here that is acceptable to everyone.

Let me summarize requirements I have read:

* Thunderbird bustages should not close Firefox trees
* A version of dxr that does not show comm projects
* A version of dxr that shows all projects
* Treeherder remains separate
* Normal m-c try pushes don't automatically build Thunderbird
* There should be a commitment that comm projects will be regularly
maintained at least in the foreseeable future

* Thunderbird builds should not run on every m-c/m-i commit
* The default checkout should not contain comm projects
* It does not make sense if Thunderbird will be separate short term
* There should be least amount of pressure to fix Thunderbird things for
Firefox contributors


If these are the requirements, with the exception of narrow clones which
as I've understood are not stable yet, I believe they are all fairly
easy to fulfill.

Are there any other requirements I've missed?

Philipp



I think the above summarizes the discussions and counter-points raised 
rather well.


Although I don't hear from many volunteers who send in TB patches 
occasionally
in this thread, I believe many of them would work hard to make the 
following a reality:


> There should be a commitment that comm projects will be regularly
> maintained at least in the foreseeable future

[Of course, there is NO contract by the user community, so "commitment" is a 
rather
vague term here. I can't speak for others.]

I, for one, use TB for regular work at the office and at home regularly, and
have come to depend on it. So any serious bugs that I find (and there are many
unfortunately) *HAVE* to be fixed eventually and so I try to send patches.
Some may send in patches to fix these bugs, and others may send in patches
to bring in new features. But if there are a million users out there,
I bet there are a couple hundred volunteers who can program. (I think there was 
a statistics
compiled by someone to show the user community contribution in terms of patches 
sent in
by individuals in the last few years after Mozilla foundation put TB at the 
mercy of
user community.)

And to make this maintenance easier (less breakage of tree herder compilation, 
less duplication of slightly different similar documents etc.), the merge is 
preferable from the standpoint of developers IMHO.

TIA

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Doug Turner]

It’s not a simple thing to just merge the code bases.  It’s going to cause a 
bunch of work in Release which we’re just not signed up for.  In our planning 
for 2016, I will add this to what we’d like to do — but no promises as there 
are lots of high priority things we need to get done.


Doug


> On Nov 5, 2015, at 6:58 PM, Joshua Cranmer   wrote:
> 
> This thread has quieted down for a while, but I don't want to let it die out 
> without a clear consensus being reached.
> 
> What I want to know is whether or not there is sufficient consensus for the 
> merge to happen that I can start planning with release engineering and 
> automation on getting merged comm-central builds working, with an eye to 
> actually committing the merge in Q4 or Q1 (the master bug for this work will 
> be bug 787208).
> 
> On 10/23/2015 2:57 AM, Mike Hommey wrote:
>> Hi,
>> 
>> This has been discussed in the past, to no avail. I would like to reopen
>> the discussion.
>> 
>> Acknowledgment: this is heavily inspired from a list compiled by Joshua
>> Cranmer, but please consider this *also* coming from me, with my build
>> system peer hat on.
>> 
>> What:
>> 
>> Let's first summarize what this is about. This is about moving the
>> development of Seamonkey, Thunderbird, and Lightning in the same
>> repository as Firefox, by merging all their code and history from
>> comm-central into mozilla-central.
>> 
>> Seamonkey and Thunderbird share a lot, so comm-central without
>> Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
>> standalone and an addon shipped with Thunderbird, so in practice, it
>> can be considered as being part of Thunderbird.
>> 
>> Why:
>> 
>> - The interaction between the build system in mozilla-central and the
>>   build system in comm-central is complex, and has been a never stopping
>>   cause of all kinds of problems sometimes blocking changes in the
>>   mozilla-central build system, sometimes making them unnecessarily more
>>   complex.
>> 
>> - The interaction between both build systems and automation is complex,
>>   and got even more twisted with mozharness now being in
>>   mozilla-central, because of the chicken-and-egg problem it introduces,
>>   making integration with mozharness hard.
>> 
>> - Likewise with taskcluster.
>> 
>> - Subsequently, with mozilla-central now relying on mozharness and soon
>>   switching away from buildbot, the differences in setup with
>>   comm-central keep increasing, and makes maintaining those builds a
>>   large hurdle.
>> 
>> - Historically, the contents of comm-central used to be in the same
>>   repository as everything else, and the build system has never really
>>   copped with the separation. Arguably, this was in the CVS days.
>>   It's a testament to our build and release engineers that the cobbled
>>   together result has held up for as long as it has, but it's really
>>   not sustainable anymore.
>> 
>> - mozilla-central and comm-central are as tied as top-level
>>   mozilla-central and js/ are. Imagine what development would look like
>>   if js/ was in a separate repository.
>> 
>> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
>>   changes tend to break comm-central. While it can be argued that it
>>   shouldn't be platform engineers' burden to care about those, the fact
>>   is that even if they do care, the complexity of testing those changes
>>   on try or locally doesn't even slightly encourage them to actually do
>>   the work.
>> 
>> - TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>>   number of users, behind Firefox, and before Firefox for Android and
>>   Firefox OS.  Many of those users may legitimately want to contribute
>>   to Thunderbird, and the bar to entry is made much higher by the
>>   multi-repository setup and the extra complexity it entails. Mozilla is
>>   actively making the bar to entry for Firefox/Firefox for
>>   Android/Firefox OS contributions lower, at the expense of Thunderbird
>>   contributors. This is a sad state of affairs.
>> 
>> Why not, and counter-counter-arguments:
>> 
>> - It would increase mozilla-central significantly.
>> Well, first, it's true, for some value of "significant".
>> comm-central is about 131M of .hg/ data, while is about 2309M as of
>> writing. That's a 5.7% increase in size of the repository. On the
>> other hand, 131M is less than the size mozilla-central grew in the
>> last 3 months.
>> 
>> - It sets a bad precedent, other Gecko-based projects might want to
>>   merge.
>>   - mobile/ set the precedent half a decade ago.
>>   - as mentioned above, historically, everything was in the same
>> repository, and the split can be argued to be the oddity here
>>   - there are barely any Gecko-based projects left that are not in
>> comm-central.
>> 
>> - It adds burden to developers, needing to support those projects
>>   merged from comm-central.
>> Just look around in 

Re: Merging comm-central into mozilla-central

[Doug Turner]

I would have rather done this in a private email, but some replied and said I 
wasn’t clear.


-> Do not merge comm-central into mozilla-central <-


1) I think merging comm-central is a bad idea as it will basically tax all 
gecko + firefox developers forever.

2) It isn’t clear that Thunderbird is a supported product anymore.  MoCo 
certainly isn’t responsible for it.  I don’t think MoFo does anything for it.

3) We’re spending $ and time in Release on this project.  I would rather not 
have to do that given (2).

4) This sets a bad precedent.  I don’t think we want every application built on 
top of gecko to be in mozilla-central.


We don’t have all of the time and resources in the world.  We have to be very 
deliberate about what we work on.  And Thunderbird — as it is now — isn’t 
something MoCo is focusing on.  Because of this, I really doubt anyone in moco 
Release is going to futz with it.

Doug


> On Nov 6, 2015, at 9:20 AM, Doug Turner  wrote:
> 
> It’s not a simple thing to just merge the code bases.  It’s going to cause a 
> bunch of work in Release which we’re just not signed up for.  In our planning 
> for 2016, I will add this to what we’d like to do — but no promises as there 
> are lots of high priority things we need to get done.
> 
> 
> Doug
> 
> 
>> On Nov 5, 2015, at 6:58 PM, Joshua Cranmer   wrote:
>> 
>> This thread has quieted down for a while, but I don't want to let it die out 
>> without a clear consensus being reached.
>> 
>> What I want to know is whether or not there is sufficient consensus for the 
>> merge to happen that I can start planning with release engineering and 
>> automation on getting merged comm-central builds working, with an eye to 
>> actually committing the merge in Q4 or Q1 (the master bug for this work will 
>> be bug 787208).
>> 
>> On 10/23/2015 2:57 AM, Mike Hommey wrote:
>>> Hi,
>>> 
>>> This has been discussed in the past, to no avail. I would like to reopen
>>> the discussion.
>>> 
>>> Acknowledgment: this is heavily inspired from a list compiled by Joshua
>>> Cranmer, but please consider this *also* coming from me, with my build
>>> system peer hat on.
>>> 
>>> What:
>>> 
>>> Let's first summarize what this is about. This is about moving the
>>> development of Seamonkey, Thunderbird, and Lightning in the same
>>> repository as Firefox, by merging all their code and history from
>>> comm-central into mozilla-central.
>>> 
>>> Seamonkey and Thunderbird share a lot, so comm-central without
>>> Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
>>> standalone and an addon shipped with Thunderbird, so in practice, it
>>> can be considered as being part of Thunderbird.
>>> 
>>> Why:
>>> 
>>> - The interaction between the build system in mozilla-central and the
>>>  build system in comm-central is complex, and has been a never stopping
>>>  cause of all kinds of problems sometimes blocking changes in the
>>>  mozilla-central build system, sometimes making them unnecessarily more
>>>  complex.
>>> 
>>> - The interaction between both build systems and automation is complex,
>>>  and got even more twisted with mozharness now being in
>>>  mozilla-central, because of the chicken-and-egg problem it introduces,
>>>  making integration with mozharness hard.
>>> 
>>> - Likewise with taskcluster.
>>> 
>>> - Subsequently, with mozilla-central now relying on mozharness and soon
>>>  switching away from buildbot, the differences in setup with
>>>  comm-central keep increasing, and makes maintaining those builds a
>>>  large hurdle.
>>> 
>>> - Historically, the contents of comm-central used to be in the same
>>>  repository as everything else, and the build system has never really
>>>  copped with the separation. Arguably, this was in the CVS days.
>>>  It's a testament to our build and release engineers that the cobbled
>>>  together result has held up for as long as it has, but it's really
>>>  not sustainable anymore.
>>> 
>>> - mozilla-central and comm-central are as tied as top-level
>>>  mozilla-central and js/ are. Imagine what development would look like
>>>  if js/ was in a separate repository.
>>> 
>>> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
>>>  changes tend to break comm-central. While it can be argued that it
>>>  shouldn't be platform engineers' burden to care about those, the fact
>>>  is that even if they do care, the complexity of testing those changes
>>>  on try or locally doesn't even slightly encourage them to actually do
>>>  the work.
>>> 
>>> - TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>>>  number of users, behind Firefox, and before Firefox for Android and
>>>  Firefox OS.  Many of those users may legitimately want to contribute
>>>  to Thunderbird, and the bar to entry is made much higher by the
>>>  multi-repository setup and the extra complexity it entails. Mozilla is
>>>  actively making the bar to entry for 

Re: Merging comm-central into mozilla-central

[Mike Hommey]

On Fri, Nov 06, 2015 at 01:12:30PM -0600, Joshua Cranmer ? wrote:
> On 11/6/2015 12:38 PM, Doug Turner wrote:
> >I would have rather done this in a private email, but some replied and said 
> >I wasn’t clear.
> >
> >
> >-> Do not merge comm-central into mozilla-central <-
> >
> >
> >1) I think merging comm-central is a bad idea as it will basically tax all 
> >gecko + firefox developers forever.
> >
> >2) It isn’t clear that Thunderbird is a supported product anymore.  MoCo 
> >certainly isn’t responsible for it.  I don’t think MoFo does anything for it.
> 
> I know that Thunderbird has been in talks with the Mozilla Foundation about
> being officially supported by them, and I believe the only thing left is to
> sign the ink on some papers for that. There are others who were involved in
> those talks who could give more specific details.
> 
> >3) We’re spending $ and time in Release on this project.  I would rather not 
> >have to do that given (2).
> >
> >4) This sets a bad precedent.  I don’t think we want every application built 
> >on top of gecko to be in mozilla-central.
> 
> I've explained why this isn't really a precedent several times.
> >
> >
> >We don’t have all of the time and resources in the world.  We have to be 
> >very deliberate about what we work on.  And Thunderbird — as it is now — 
> >isn’t something MoCo is focusing on.  Because of this, I really doubt anyone 
> >in moco Release is going to futz with it.
> 
> Except the release engineers in moco are already spending a good deal of
> time on managing the Thunderbird release engineering--exactly as Mozilla
> promised they would back in 2012.

And other moco engineers are wasting time because of the status quo (and
I won't detail here because that's been covered in the thread already).

Whether it happens in mozilla-central or somewhere else, this merge
*will* have to happen at some point.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

This thread has quieted down for a while, but I don't want to let it die 
out without a clear consensus being reached.


What I want to know is whether or not there is sufficient consensus for 
the merge to happen that I can start planning with release engineering 
and automation on getting merged comm-central builds working, with an 
eye to actually committing the merge in Q4 or Q1 (the master bug for 
this work will be bug 787208).


On 10/23/2015 2:57 AM, Mike Hommey wrote:

Hi,

This has been discussed in the past, to no avail. I would like to reopen
the discussion.

Acknowledgment: this is heavily inspired from a list compiled by Joshua
Cranmer, but please consider this *also* coming from me, with my build
system peer hat on.

What:

Let's first summarize what this is about. This is about moving the
development of Seamonkey, Thunderbird, and Lightning in the same
repository as Firefox, by merging all their code and history from
comm-central into mozilla-central.

Seamonkey and Thunderbird share a lot, so comm-central without
Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
standalone and an addon shipped with Thunderbird, so in practice, it
can be considered as being part of Thunderbird.

Why:

- The interaction between the build system in mozilla-central and the
   build system in comm-central is complex, and has been a never stopping
   cause of all kinds of problems sometimes blocking changes in the
   mozilla-central build system, sometimes making them unnecessarily more
   complex.

- The interaction between both build systems and automation is complex,
   and got even more twisted with mozharness now being in
   mozilla-central, because of the chicken-and-egg problem it introduces,
   making integration with mozharness hard.

- Likewise with taskcluster.

- Subsequently, with mozilla-central now relying on mozharness and soon
   switching away from buildbot, the differences in setup with
   comm-central keep increasing, and makes maintaining those builds a
   large hurdle.

- Historically, the contents of comm-central used to be in the same
   repository as everything else, and the build system has never really
   copped with the separation. Arguably, this was in the CVS days.
   It's a testament to our build and release engineers that the cobbled
   together result has held up for as long as it has, but it's really
   not sustainable anymore.

- mozilla-central and comm-central are as tied as top-level
   mozilla-central and js/ are. Imagine what development would look like
   if js/ was in a separate repository.

- Relatedly, many codebase-wise changes (e.g. refactorings), or core API
   changes tend to break comm-central. While it can be argued that it
   shouldn't be platform engineers' burden to care about those, the fact
   is that even if they do care, the complexity of testing those changes
   on try or locally doesn't even slightly encourage them to actually do
   the work.

- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
   number of users, behind Firefox, and before Firefox for Android and
   Firefox OS.  Many of those users may legitimately want to contribute
   to Thunderbird, and the bar to entry is made much higher by the
   multi-repository setup and the extra complexity it entails. Mozilla is
   actively making the bar to entry for Firefox/Firefox for
   Android/Firefox OS contributions lower, at the expense of Thunderbird
   contributors. This is a sad state of affairs.

Why not, and counter-counter-arguments:

- It would increase mozilla-central significantly.
 Well, first, it's true, for some value of "significant".
 comm-central is about 131M of .hg/ data, while is about 2309M as of
 writing. That's a 5.7% increase in size of the repository. On the
 other hand, 131M is less than the size mozilla-central grew in the
 last 3 months.

- It sets a bad precedent, other Gecko-based projects might want to
   merge.
   - mobile/ set the precedent half a decade ago.
   - as mentioned above, historically, everything was in the same
 repository, and the split can be argued to be the oddity here
   - there are barely any Gecko-based projects left that are not in
 comm-central.

- It adds burden to developers, needing to support those projects
   merged from comm-central.
 Just look around in mozilla-central at all the optional things
 that are not visible on treeherder and break regularly. The
 situation wouldn't be different in that sense. But the people
 that do care about those projects will have a better experience
 supporting them.

Considering all the above, are there still objections to this
happening, and can we finally allow Joshua to go ahead with his merge
plan? (CCing bsmedberg, who, iirc, had Brendan's delegation to have the
final word on this)

Cheers,

Mike



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

Re: Merging comm-central into mozilla-central

[Jörg Knobloch]

  
  
Has a decision been made or was this all just NATO (No Action, Talk
Only)?

Jorg K.
  

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Henri Sivonen]

On Fri, Oct 23, 2015 at 9:45 PM, Bobby Holley  wrote:
> On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer  
> wrote:
>
>> I also wonder why you have a peculiar insistence that comm-central code
>> must not appear to any contributor, given the continued existence of "stuff
>> that Firefox doesn't care about" in mozilla-central, such as support for
>> tier-3 platforms (do we still have QT code in the tree) or xulrunner.
>
>
> FWIW, I personally think we should remove things things from the tree.

I think we shouldn't remove Qt support from the tree. Jolla ships a
Qt-based Gecko-based browser. Sure, their market share is tiny, but
they are still contributing to making Gecko *in a Web browser* (as
opposed to an email client or something else non-Web) available to
more mobile users and they do a better job at delivering updates than
FxOS vendors do. I think it's very sad that they have to do it without
support from us and that they feel like they need to tweet
https://twitter.com/zzste/status/433236310816333824 and retweet from
their corporate Twitter account only to be ignored.

If anything, I think we should make it easier for them to do their
thing on m-c (not as tier-1, of course) and count their contribution
to the delivery of Gecko in a browser to users on mobile towards our
stats regarding reaching users on mobile.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Henri Sivonen]

On Tue, Oct 27, 2015 at 10:04 PM, Boris Zbarsky  wrote:
> On 10/23/15 8:32 PM, Robert O'Callahan wrote:
>>
>> I support merging c-c into m-c.
>
>
> For what it's worth, I do as well.  Of course I also do some due diligence
> about not breaking Thunderbird before landing patches, just like I do for
> Firefox extensions and whatnot and I feel that that is the morally right
> thing to do, at least for me.

I support the merge.

I do have technical worries about Thunderbird being able to adapt to
upcoming Firefox-side changes (every time I make Gecko changes that
affect Thunderbird, the C++ code on the c-c side looks more crufty
than the m-c code from 1999 that I'm dragging closer to the present
day), but I feel we have to find a way for Thunderbird to stay afloat
*for its users*. I don't want us to undermine the trust that nearly 10
million people place in Mozilla and the tone with which those nearly
10 million people talk about Mozilla to others.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote
 wrote:
> On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking  wrote:
>>
>> The question is, do we fix that friction by making collaboration
>> easier, or do we fix it by reducing collaboration.
>
> Yes. Merging c-c into m-c would achieve the first alternative. (And it
> has support from plenty of people in this thread, including build
> system peers like glandium and gps whose opinion I think should hold
> strong sway on the topic of repository structure.)
>
> Do you have suggestions for achieving the second alternative?

The suggestion would be to give the build engineers explicit
permission to do whatever changes they need without worrying about if
it breaks thunderbird.

I.e. do the same thing in the build system as we do in the rest of the tree.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mike Hommey]

On Mon, Oct 26, 2015 at 11:44:40PM -0700, Jonas Sicking wrote:
> On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote
>  wrote:
> > On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking  wrote:
> >>
> >> The question is, do we fix that friction by making collaboration
> >> easier, or do we fix it by reducing collaboration.
> >
> > Yes. Merging c-c into m-c would achieve the first alternative. (And it
> > has support from plenty of people in this thread, including build
> > system peers like glandium and gps whose opinion I think should hold
> > strong sway on the topic of repository structure.)
> >
> > Do you have suggestions for achieving the second alternative?
> 
> The suggestion would be to give the build engineers explicit
> permission to do whatever changes they need without worrying about if
> it breaks thunderbird.
> 
> I.e. do the same thing in the build system as we do in the rest of the tree.

Let's say we do this. At some point we'll reach the fact that the c-c
specific hacks in the build system are getting in the way (which they
already are, but it's kind of bearable for now), and we'll want to
remove them. What happens then?

Well, I guess we could declare that it's not our problem and leave it to
the TB and SM people to change their build system and automation to cope
with that. And leave them without a build for months. Do we expect them
to survive that?

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mike Hommey]

On Tue, Oct 27, 2015 at 04:24:45PM +0900, Mike Hommey wrote:
> On Mon, Oct 26, 2015 at 11:44:40PM -0700, Jonas Sicking wrote:
> > On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote
> >  wrote:
> > > On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking  wrote:
> > >>
> > >> The question is, do we fix that friction by making collaboration
> > >> easier, or do we fix it by reducing collaboration.
> > >
> > > Yes. Merging c-c into m-c would achieve the first alternative. (And it
> > > has support from plenty of people in this thread, including build
> > > system peers like glandium and gps whose opinion I think should hold
> > > strong sway on the topic of repository structure.)
> > >
> > > Do you have suggestions for achieving the second alternative?
> > 
> > The suggestion would be to give the build engineers explicit
> > permission to do whatever changes they need without worrying about if
> > it breaks thunderbird.
> > 
> > I.e. do the same thing in the build system as we do in the rest of the tree.
> 
> Let's say we do this. At some point we'll reach the fact that the c-c
> specific hacks in the build system are getting in the way (which they
> already are, but it's kind of bearable for now), and we'll want to
> remove them. What happens then?
> 
> Well, I guess we could declare that it's not our problem and leave it to
> the TB and SM people to change their build system and automation to cope
> with that. And leave them without a build for months. Do we expect them
> to survive that?

Although I guess the alternative would be to tell them to do the merge
on their own in their own repo, and cope with keeping up on their own,
which would be less worse, albeit not optimal.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jörg Knobloch]

On 27/10/2015 03:32, Ehsan Akhgari wrote:

Over the years I have gained a *ton* of experience in code that
interfaces with both Firefox and Thunderbird/SeaMonkey.  I can't really
think of a single instance where I made a change in that code and it
broke something in Thunderbird and the breakage was magically fixed
without my involvement.

What happens in practice is people file bugs and ping you and unless
we're talking about a very simple API change that is obvious to mirror
in c-c, nobody will do anything about the regression unless if the
Firefox developer looks at it.  So it's a choice between actively
ignoring people (which is really being rude to them, which is not an
option I would personally take) or having to do some work (which often
involves reading and understanding the c-c code, debugging it, and so on.)

Now, as an employee of MoCo, I am told to spend 0 time on these issues.
  Therefore, I try to be responsible, and nice, and spend my spare time
to fix them.  (Saying this part with the best possible intentions) And
you've seen how I have been treated elsewhere in the thread, in the
sub-thread that I stopped participating in.  This situation is really
not sustainable for a healthy community.


 

I don't think the picture Ehsan is painting of the Thunderbird "people 
filing bugs" is quite accurate.


I've been a contributor since March 2015, so my experience is limited. 
However, all bugs I know of where Thunderbird people pestered Ehsan 
(except the *one* Ehsan mentioned in his other e-mail about the document 
encoder) had to do purely with the M-C editor or other parts of Gecko. 
Since Thunderbird users use a "content-editable" element to write their 
e-mail, they are more exposed to M-C editor bugs (like spell check marks 
disappearing, fonts/styles getting lost, pre-formatted blocks getting 
obliterated, copy/paste not working, etc., you can find the bug numbers 
in the document linked below). All these bugs were Gecko bugs 
reproducible in Firefox, no Thunderbird needed. What is costing Ehsan 
his spare time is that the M-C editor as part of Gecko is sadly 
neglected by Mozilla, it is not the pesky Thunderbird people. In fact, 
quite the opposite is the case: Thanks to the pesky Thunderbird people, 
M-C editor problems are getting reported and fixed, I myself have landed 
six editor fixes, eight spell check related fixes and assisted with some 
others issues. Telling Mozilla employees they should spend 0 time on 
some areas of Gecko is in fact a bad decision which has led to a lot of 
friction!


Just for completeness: The is another area where Thunderbird people are 
pestering: Autocomplete. For about six months Thunderbird users had to 
live with recipient addresses being erroneously flagged as unknown in 
red colour. And the problem was in M-C. (Technical detail: an unsigned 
int was decremented below 0 leading to "interesting" results.)


Quote:
> I can't really
> think of a single instance where I made a change in that code and it
> broke something in Thunderbird and the breakage was magically fixed
> without my involvement.

This is inaccurate. Apart from the one "special" decoder case, changes 
mostly did not break Thunderbird, but Gecko. They were only noticed by 
Thunderbird users. And of course the Gecko breakage didn't fix itself 
magically.


One example hot of the press: Yesterday I was made aware of bug 1050566, 
a drag and drop problem (and a regression of an earlier Gecko change). 
Who complained: Of course a Thunderbird user, they dragged something 
onto a mail "composition" window. Where is the problem: In Gecko, since 
the problem can be reproduced in Firefox alone. Of course the problem 
was noticed and reported by a Thunderbird user since there are not many 
Firefox users who use

  data:text/html, 
as a URL and drag stuff onto the window.



Coming back to the topic of the merge: The special case Ehsan mentioned 
(encoder, bug 1125956) would have benefited from a merged repository.
(Note to Ehsan: Please take a look at bug 1214377. Your conditional 
compilation from bug 1125956 has been made obsolete by your other 
changes in the area.)


Jorg K.
(Mozilla contributor - http://www.jorgk.com/misc/Mozilla-work.pdf).


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philip Chee]

On 27/10/2015 15:24, Mike Hommey wrote:
> On Mon, Oct 26, 2015 at 11:44:40PM -0700, Jonas Sicking wrote:
>> On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote
>>  wrote:
>> > On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking  wrote:
>> >>
>> >> The question is, do we fix that friction by making collaboration
>> >> easier, or do we fix it by reducing collaboration.
>> >
>> > Yes. Merging c-c into m-c would achieve the first alternative. (And it
>> > has support from plenty of people in this thread, including build
>> > system peers like glandium and gps whose opinion I think should hold
>> > strong sway on the topic of repository structure.)
>> >
>> > Do you have suggestions for achieving the second alternative?
>> 
>> The suggestion would be to give the build engineers explicit
>> permission to do whatever changes they need without worrying about if
>> it breaks thunderbird.
>> 
>> I.e. do the same thing in the build system as we do in the rest of the tree.
> 
> Let's say we do this. At some point we'll reach the fact that the c-c
> specific hacks in the build system are getting in the way (which they
> already are, but it's kind of bearable for now), and we'll want to
> remove them. What happens then?
> 
> Well, I guess we could declare that it's not our problem and leave it to
> the TB and SM people to change their build system and automation to cope
> with that. And leave them without a build for months. Do we expect them
> to survive that?
> 
> Mike

And what happens if c-c needs to push out a chemspill/security fix while
the build system is broken?

Phil

-- 
Philip Chee , 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Boris Zbarsky]

On 10/23/15 8:32 PM, Robert O'Callahan wrote:

I support merging c-c into m-c.


For what it's worth, I do as well.  Of course I also do some due 
diligence about not breaking Thunderbird before landing patches, just 
like I do for Firefox extensions and whatnot and I feel that that is 
the morally right thing to do, at least for me.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/27/2015 2:50 PM, Boris Zbarsky wrote:

On 10/27/15 3:17 PM, Joshua Cranmer  wrote:

[1] An example from just this morning is the emasculation of
nsIDOMWindow. It's clear at this point that all of our binary code has
to be linked into libxul


Why can you not use nsPIDOMWindow?  If there are particular APIs it's 
missing that you need, please file bugs and we can put them there, 
just like we did for APIs that various parts of Gecko needed.


We did replace our uses with nsPIDOMWindow, but it's an example of an 
API that can be used external to libxul being replaced with one that 
can't be.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Boris Zbarsky]

On 10/27/15 3:17 PM, Joshua Cranmer  wrote:

[1] An example from just this morning is the emasculation of
nsIDOMWindow. It's clear at this point that all of our binary code has
to be linked into libxul


Why can you not use nsPIDOMWindow?  If there are particular APIs it's 
missing that you need, please file bugs and we can put them there, just 
like we did for APIs that various parts of Gecko needed.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Boris Zbarsky]

On 10/27/15 3:55 PM, Joshua Cranmer  wrote:

We did replace our uses with nsPIDOMWindow, but it's an example of an
API that can be used external to libxul being replaced with one that
can't be.


Just to be clear, we're happy to make things on nsPIDOMWindow virtual or 
exported as needed to the extent that it's needed for Thunderbird.  We 
did in fact think about this carefully before emptying out nsIDOMWindow.


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[callek]

On Friday, October 23, 2015 at 3:58:07 AM UTC-4, Mike Hommey wrote:
> Hi,
> 
> This has been discussed in the past, to no avail. I would like to reopen
> the discussion.
> 
> Acknowledgment: this is heavily inspired from a list compiled by Joshua
> Cranmer, but please consider this *also* coming from me, with my build
> system peer hat on.
> 
> What:
> 
> Let's first summarize what this is about. This is about moving the
> development of Seamonkey, Thunderbird, and Lightning in the same
> repository as Firefox, by merging all their code and history from
> comm-central into mozilla-central.
> 
> Seamonkey and Thunderbird share a lot, so comm-central without
> Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
> standalone and an addon shipped with Thunderbird, so in practice, it
> can be considered as being part of Thunderbird.
> 
> Why:
> 
> - The interaction between the build system in mozilla-central and the
>   build system in comm-central is complex, and has been a never stopping
>   cause of all kinds of problems sometimes blocking changes in the
>   mozilla-central build system, sometimes making them unnecessarily more
>   complex.
> 
> - The interaction between both build systems and automation is complex, 
>   and got even more twisted with mozharness now being in
>   mozilla-central, because of the chicken-and-egg problem it introduces,
>   making integration with mozharness hard.
> 
> - Likewise with taskcluster.
> 
> - Subsequently, with mozilla-central now relying on mozharness and soon
>   switching away from buildbot, the differences in setup with
>   comm-central keep increasing, and makes maintaining those builds a
>   large hurdle.
> 
> - Historically, the contents of comm-central used to be in the same
>   repository as everything else, and the build system has never really
>   copped with the separation. Arguably, this was in the CVS days.
>   It's a testament to our build and release engineers that the cobbled
>   together result has held up for as long as it has, but it's really
>   not sustainable anymore.
> 
> - mozilla-central and comm-central are as tied as top-level
>   mozilla-central and js/ are. Imagine what development would look like
>   if js/ was in a separate repository.
> 
> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
>   changes tend to break comm-central. While it can be argued that it
>   shouldn't be platform engineers' burden to care about those, the fact
>   is that even if they do care, the complexity of testing those changes
>   on try or locally doesn't even slightly encourage them to actually do
>   the work.
> 
> - TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>   number of users, behind Firefox, and before Firefox for Android and
>   Firefox OS.  Many of those users may legitimately want to contribute
>   to Thunderbird, and the bar to entry is made much higher by the
>   multi-repository setup and the extra complexity it entails. Mozilla is
>   actively making the bar to entry for Firefox/Firefox for
>   Android/Firefox OS contributions lower, at the expense of Thunderbird
>   contributors. This is a sad state of affairs.
> 
> Why not, and counter-counter-arguments:
> 
> - It would increase mozilla-central significantly.
> Well, first, it's true, for some value of "significant".
> comm-central is about 131M of .hg/ data, while is about 2309M as of
> writing. That's a 5.7% increase in size of the repository. On the
> other hand, 131M is less than the size mozilla-central grew in the
> last 3 months.
> 
> - It sets a bad precedent, other Gecko-based projects might want to
>   merge.
>   - mobile/ set the precedent half a decade ago.
>   - as mentioned above, historically, everything was in the same
> repository, and the split can be argued to be the oddity here
>   - there are barely any Gecko-based projects left that are not in
> comm-central.
> 
> - It adds burden to developers, needing to support those projects
>   merged from comm-central.
> Just look around in mozilla-central at all the optional things
> that are not visible on treeherder and break regularly. The
> situation wouldn't be different in that sense. But the people
> that do care about those projects will have a better experience
> supporting them.
> 
> Considering all the above, are there still objections to this
> happening, and can we finally allow Joshua to go ahead with his merge
> plan? (CCing bsmedberg, who, iirc, had Brendan's delegation to have the
> final word on this)
> 
> Cheers,
> 
> Mike

To be explicit,

I am on the SeaMonkey Council (drivers), and am an employee of MoCo.

>From the code complexity standpoint Mozilla Releng code would also be greatly 
>benefitted by the merge. Making our day-to-day easier and less cumbersome. 
>Though we don't deal directly with thunderbird, the ability to remove any/all 
>of the complexity which does would be a boon to 

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

On 10/23/15 11:22 PM, Bobby Holley wrote:
>> What's even more sad is that it's at the expense of Thunderbird (and
>> > SeaMonkey) *and* at the expense of Firefox build system changes.
>> >
> That may be a reason for the people working on the build system to refactor
> it without consideration for Thunderbird. That may sound heartless, but it
> is the current directive from the organization that is paying us to work on
> m-c.

>From what I've understood from the build system folks, I think that
refactoring the build system without taking c-c into account wouldn't be
much of a problem if the merge happens.

There are Thunderbird folks that will happily use their free time to
look into bustages resulting from build system changes, we are already
doing that today.

If we can come to the agreement that patches to the m-c build system
done by Thunderbird folks won't be outright rejected, I think we are
good. Of course these patches should avoid being special cases, but if
an assumption is made in the build system that can be generalized, I
think it would be beneficial to both sides.

Philipp


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Justin Dolske]

On 10/23/15 10:22 AM, Benjamin Smedberg wrote:


I'm sorry that it makes you sad, but Mozilla has explicitly decided to
prioritize the bar to entry for Firefox development, and the speed of
development of Firefox, at the expense of Thunderbird (and seamonkey).
And as Firefox development moves faster toward things such as stopping
supporting XUL addons, removing support for heavyweight themes, and even
cutting XUL altogether, we should all expect the impedance mismatch to
become worse. We are not only saying that you don't have to fix
comm-central apps: we're also saying that we don't *want* core
contributors to spend time on comm-central.


+1. Last time this thread came up, I thought the guidance was that core 
contributors (and especially MoCo employees) should explicitly *not* be 
spending time on TB/SM code. Even in the "I'll just be nice and go a bit 
out of my way", because those costs are undervalued and add up.


This isn't out of spite or malice towards those projects, but a 
recognition that we need to focus our extremely limited time and 
resources. We're in a hypercompetitive market with giants (Google, 
Microsoft, Apple) who effectively have infinite time and resources in 
comparison. Constant distractions from our core do no one any good.


[And the same argument applies to things within Firefox as well - there 
are many things we could be doing, but need to aggressively focus our 
efforts on a few things that matter most.]


I'd also reiterate your point that this issue is, unfortunately, likely 
to get much worse as we start making deeper changes to modernize the 
platform (like de-XULification). I already see complaints from TB/SM 
folks about the difficulty in keeping pace today, and I'm not sure how 
those projects will realistically be able to keep up in the future. (And 
so it certainly seems like an odd time to be merging that code into 
mozilla-central.)


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Steve Fink]

On 10/23/2015 10:22 AM, Benjamin Smedberg wrote:
I support going back to a giant monolithic repository if we can 
cleanly delineate the code for various projects.


We know that the searchability and readability of our code is a major 
barrier to some kinds of participation. We should continue to optimize 
ourselves around that workflow.


Does this proposal come with a plan to check out subsets of the code? 
In particular, I want to express the following as something inbetween 
"serious concerns" and "requirements":


 * The default view of dxr.mozilla.org should not include non-Firefox 
code

 * The default checkout should not include non-Firefox code. (Note:
   this is about the working tree: I don't think the space in the .hg
   directory matters enough to worry about).


Why are we still arguing over this? It seems like BDS is fine with 
merging it back in, as long as some reasonable objections are resolved 
first.


With respect to the first one, I would personally like to further 
request that a non-default, relatively easily findable, view be 
available that *does* include non-Firefox code. I often search dxr for 
callers of a function where I *want* to see as many users as possible. I 
have no intention of "fixing" them, I just want to see them. It might be 
because I'm answering a question along the lines of "does anyone ever 
use it like this? Or have they in the past?" Or maybe I'm just searching 
for example code. Or maybe I'm implementing something for my static 
analysis and want to see whether it's worth handling a particular edge 
case. "If they did it once, they might try to do it again."


For my personal usage patterns, it is more common that I'd want to see 
results from m-c, c-c, external embedders, amo, and code from any other 
random clueless idiot on the internet. I would prefer to have a default 
view that showed anything from anywhere, with all past revisions 
included, but to have every result clearly denote whether it's from the 
current Firefox code (and have it sort those results to the top.) That 
"past revisions" part would clearly incur some performance 
considerations, but nothing that a dram or two of unicorn blood couldn't 
dispel away.


For the second one, it feels like a bit of a scary amount of 
complication in order to avoid seeing distracting code during a typical 
grep, but it also feels like a good pragmatic way to minimize the 
distraction caused by c-c's presence in the repo.


I can see that this might not be a satisfactory outcome to someone who 
just wants to pull the trigger and merge it all in so they can get 
cracking on build system improvements, without waiting on these annoying 
tooling considerations. But if so, why aren't the continued arguments 
focused on addressing BDS's (semi-)requirements? [note that gps *did* 
respond to the sparse checkout portion; is the current state of that 
support satisfactory? That's the blocking question here.]


Perhaps the concern is that it's foolish to merge it in now if the 
direction of c-c development is going to end up needing it split out 
eventually anyway? I doubt that's near enough at hand to matter, 
personally, and splitting it back out doesn't seem hard.






- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
   number of users, behind Firefox, and before Firefox for Android and
   Firefox OS.  Many of those users may legitimately want to contribute
   to Thunderbird, and the bar to entry is made much higher by the
   multi-repository setup and the extra complexity it entails. 
Mozilla is

   actively making the bar to entry for Firefox/Firefox for
   Android/Firefox OS contributions lower, at the expense of Thunderbird
   contributors. This is a sad state of affairs.


I'm sorry that it makes you sad, but Mozilla has explicitly decided to 
prioritize the bar to entry for Firefox development, and the speed of 
development of Firefox, at the expense of Thunderbird (and seamonkey). 
And as Firefox development moves faster toward things such as stopping 
supporting XUL addons, removing support for heavyweight themes, and 
even cutting XUL altogether, we should all expect the impedance 
mismatch to become worse. We are not only saying that you don't have 
to fix comm-central apps: we're also saying that we don't *want* core 
contributors to spend time on comm-central.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Nicholas Nethercote]

On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking  wrote:
>
> Given that people are already feeling pressure to fix up thunderbird
> code when they land patches, I can only see that pressure increasing
> when you don't even need to pull a separate tree.

That's more or less correct, though I'd rewrite it as the following:

"Given that people are already feeling pressure to fix up thunderbird
code when they land patches, we should make things easier by not
making them need to pull a separate tree."


On Mon, Oct 26, 2015 at 1:29 PM, Justin Dolske  wrote:

> +1. Last time this thread came up, I thought the guidance was that core
> contributors (and especially MoCo employees) should explicitly *not* be
> spending time on TB/SM code. Even in the "I'll just be nice and go a bit out
> of my way", because those costs are undervalued and add up.

Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
come with zero cost. Because if I change an API used by thunderbird
then a bug will be filed, and it will be marked as depending on the
bug in which I changed the API, and I'll see that in bugmail, and then
I'll read the bug, and feel bad that I inconvenienced someone -- but
I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
need to needinfo me to ask about the change -- but maybe they should
know better, and maybe I should ignore them again -- and if I get CC'd
maybe I can just un-CC myself.

In comparison, for the cases I've experienced, modifying the TB code
is really simple. E.g. I'll have to modify 80 places in m-c code and
then 4 places in c-c code. Numbers like that.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

On 10/23/15 11:09 PM, Eric Rescorla wrote:
>> It may well be that having c-c code in m-c decreases friction overall,
>> > since it saves time for the people that know they're allowed to break TB
>> > but choose to help it anyway. However, the cost of redirected work for
>> > contributors that _don't_ know they're allowed to break TB is real. That is
>> > the tradeoff that needs to be weighed IMO.
> 
> What Bobby said here seems very important. In the cost/benefit analysis,
> the impact on Firefox needs to be weighted very heavily. In particular,
> breaking TB should not cause failures either on try or on commit, and
> changes to pieces of Gecko should not be held up on their impact on TB.

If we get this right on the tooling side, I don't think it will be a
concern. For contributors that are regular Mozillians, I think it has
been clearly communicated that making changes in Firefox and Toolkit
does not require fixing Thunderbird/Seamonkey.

New contributors will either have a mentor that knows and can
communicate this fact, or will not see the changes when using a
correctly configured dxr, which is likely linked in one of the
contributor guides.

Even if they do a grep and find code locally, they will be aware that
Thunderbird and Firefox are separate products, and if they set out to
fix a Firefox bug I don't think they'd immediately think they need to
fix it in Thunderbird without asking questions. Personally I think they
will either ignore Thunderbird outright, or ask someone if they need to
take care of it. As per current policy, they will be told they do not
have to.

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central (summary v1)

[Philipp Kewisch]

Hi all,

I'd love to see if we can move towards an agreement. For those of you
that would prefer not to merge, I'd love to hear what your absolute
minimum requirements would be that you'd accept a merge with. Changes to
hg? Changes to dxr? A policy chanage? If we can establish clear
requirements, maybe we can see they are not so hard to fulfill and we
can come to an agreement quickly. Ideally, I'd like to find a middle
ground here that is acceptable to everyone.

Let me summarize requirements I have read:

* Thunderbird bustages should not close Firefox trees
* A version of dxr that does not show comm projects
* A version of dxr that shows all projects
* Treeherder remains separate
* Normal m-c try pushes don't automatically build Thunderbird
* There should be a commitment that comm projects will be regularly
maintained at least in the foreseeable future

* Thunderbird builds should not run on every m-c/m-i commit
* The default checkout should not contain comm projects
* It does not make sense if Thunderbird will be separate short term
* There should be least amount of pressure to fix Thunderbird things for
Firefox contributors


If these are the requirements, with the exception of narrow clones which
as I've understood are not stable yet, I believe they are all fairly
easy to fulfill.

Are there any other requirements I've missed?

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

On 10/24/15 1:41 AM, Bobby Holley wrote:
> We have three options:
> (1) Build peers do a bunch of extra work to support c-c in a separate repo.
> (2) We land c-c in m-c, so that build peers can support it without much
> extra work.
> (3) We don't land c-c in m-c, build peers ignore c-c, and TB fends for
> itself as pure downstream.
> 
> (1) seems strictly sub-optimal. The decision here is pretty much between
> (2) and (3).

I think there is another option here. Although I would of course prefer
(2), I think we could add:

(4) We land c-c in m-c, build peers ignore comm projects, TB folks help
with any build issues that break comm projects.

Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

On 10/26/15 10:05 PM, Steve Fink wrote:
> 
> Perhaps the concern is that it's foolish to merge it in now if the
> direction of c-c development is going to end up needing it split out
> eventually anyway? I doubt that's near enough at hand to matter,
> personally, and splitting it back out doesn't seem hard.

I think it is to early to take this into consideration. There are no
near-term plans to change Thunderbird to a model that would allow or
require splitting it out. I believe there are also at least a few
components that would require glue code or a customized Firefox runtime.
For example, I don't think registering for the default mail application
in windows is something that would work post xul in a pure html/js
environment.

If it turns out there is a way to do this with new API few years down
the road and it is determined that splitting Thunderbird out again
brings new advantages, we can still do that. A lot can change in that
time frame, both in Firefox and Thunderbird.

I support the merge.


Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Mon, Oct 26, 2015 at 3:45 PM, Nicholas Nethercote
 wrote:
> On Mon, Oct 26, 2015 at 11:39 AM, Jonas Sicking  wrote:
>>
>> Given that people are already feeling pressure to fix up thunderbird
>> code when they land patches, I can only see that pressure increasing
>> when you don't even need to pull a separate tree.
>
> That's more or less correct, though I'd rewrite it as the following:
>
> "Given that people are already feeling pressure to fix up thunderbird
> code when they land patches, we should make things easier by not
> making them need to pull a separate tree."

Well, that's exactly the question in this thread, isn't it.

Everyone acknowledges that there's currently friction due to the way
that collaboration with thunderbird is done.

The question is, do we fix that friction by making collaboration
easier, or do we fix it by reducing collaboration.

> On Mon, Oct 26, 2015 at 1:29 PM, Justin Dolske  wrote:
>
>> +1. Last time this thread came up, I thought the guidance was that core
>> contributors (and especially MoCo employees) should explicitly *not* be
>> spending time on TB/SM code. Even in the "I'll just be nice and go a bit out
>> of my way", because those costs are undervalued and add up.
>
> Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
> come with zero cost. Because if I change an API used by thunderbird
> then a bug will be filed, and it will be marked as depending on the
> bug in which I changed the API, and I'll see that in bugmail, and then
> I'll read the bug, and feel bad that I inconvenienced someone -- but
> I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
> need to needinfo me to ask about the change

Yup. This matches my experience exactly. This is a good example of the
above mentioned friction.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Brian Smith]

On Mon, Oct 26, 2015 at 1:45 PM, Joshua Cranmer  
wrote:

> FWIW, when Brian Smith made his comments on mozilla.dev.security.policy, I
> did try to find a bug detailing what he was talking about... and I couldn't
> find what he was talking about, which means that our security team is
> finding problems in Thunderbird and not properly notifying any Thunderbird
> developers of them.


Did you try clicking on the links in my emails?

> Here is a good example to show that the security of Thunderbird's
> S/MIME handling is not properly managed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1178032

> You can see an example of this policy at work at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1114787.

Love,
Brian
-- 
https://briansmith.org/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 8:25 PM, Mitchell Baker wrote:

Yes, this is a good topic and I agree i'm a necessary party here.
Is there some way of getting a good sense of the work that we're 
talking about?


I'm not sure which work you're referring to here, but I will try to 
answer to the best of my abilities.


The work required to actually do the merge is nothing more than a script 
I've already written and tested, as well as a few days with a release 
engineer to set up new configs. Ongoing maintenance would hopefully be 
minimal, as the difference would hopefully just be using one config file 
for Thunderbird and one for Firefox that differ only in things like 
choosing which mozconfig to use or choosing which directory to upload 
to, but I don't have a good enough insight into our build configuration 
to know for sure. Ongoing build system maintenance would probably be 
nil, excepting to-be-deprecated constructs which are used only in c-c 
(which I do try to keep on top of anyways, so that shouldn't be an issue).


As for the work required in build system to maintain the current 
state... There's a lot of hacks in the m-c build system to support 
Thunderbird, particularly the --external-top-srcdir configure option, 
the existence of multiple topsrcdirs, and checks for mozilla/ in several 
places (yeah, don't add a new mozilla/ source directory to the build 
system, things will break). The situation in release engineering is 
worse, since at this point we're using completely different build 
techniques, and it's hard or impossible for us to migrate to the 
mozharness-based builds, since mozharness is in mozilla-central and 
comm-central needs to do some build logic to figure out which version of 
mozilla-central (particularly on the Try server) to support. The build 
system support for the latter case also requires retaining partial 
duplication of some functionality in comm-central, resulting in a 
veritable Frankenbuild scenario.



On 10/23/15 6:15 PM, Doug Turner wrote:
Thunderbird is under supported and potentially harmful (as Brian 
Smith pointed out on the mozilla-dev-security-policy back in Sept).  
Before merging c-c into m-c, I think we should have agreement on what 
kind of support the mozilla project and foundation is going to give 
to Thunderbird.


FWIW, when Brian Smith made his comments on mozilla.dev.security.policy, 
I did try to find a bug detailing what he was talking about... and I 
couldn't find what he was talking about, which means that our security 
team is finding problems in Thunderbird and not properly notifying any 
Thunderbird developers of them.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Philipp Kewisch]

On 10/24/15 3:15 AM, Doug Turner wrote:
> Thunderbird is under supported and potentially harmful (as Brian Smith 
> pointed out on the mozilla-dev-security-policy back in Sept).  Before merging 
> c-c into m-c, I think we should have agreement on what kind of support the 
> mozilla project and foundation is going to give to Thunderbird.
> 
> I think that this decision really should be made by Mitchell (cced).
> 
> Doug

So there may be certain issues in S/MIME, but I don't believe that this
qualifies for a flat statement that Thunderbird is potentially harmful.

Nevertheless, I concur that working out an agreement on level of support
would be helpful. The Thunderbird Council is working hard on this, as it
would be of benefit for us too, but I don't think this should be a
strict requirement for merging m-c and c-c. Finding a complete strategy
for the future of Thunderbird takes time and a lot of communication with
Mozilla and other interested parties, merging m-c and c-c now would be
of immediate benefit for both sides.

Before we continue to loop in Mitchell here I think we should come to an
agreement on the technical side, there seem to be a few rough edges we
should iron out first.

Philipp

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

Jonas Sicking schrieb:

Everyone acknowledges that there's currently friction due to the way
that collaboration with thunderbird is done.

The question is, do we fix that friction by making collaboration
easier, or do we fix it by reducing collaboration.


I think the only way to "fix the friction by reducing collaboration" is 
to say that you are actively trying to kill Thunderbird and make their 
life as hard as possible. Is that what you are trying to say?


Otherwise, if we acknowledge that they can and should live, we need to 
see that we fix the friction by making collaboration easier.


KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Nicholas Nethercote]

On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking  wrote:
>
> The question is, do we fix that friction by making collaboration
> easier, or do we fix it by reducing collaboration.

Yes. Merging c-c into m-c would achieve the first alternative. (And it
has support from plenty of people in this thread, including build
system peers like glandium and gps whose opinion I think should hold
strong sway on the topic of repository structure.)

Do you have suggestions for achieving the second alternative?

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

On 2015-10-26 7:26 PM, Jonas Sicking wrote:

On Mon, Oct 26, 2015 at 1:29 PM, Justin Dolske  wrote:


+1. Last time this thread came up, I thought the guidance was that core
contributors (and especially MoCo employees) should explicitly *not* be
spending time on TB/SM code. Even in the "I'll just be nice and go a bit out
of my way", because those costs are undervalued and add up.


Speaking for myself: even if I did ignore c-c, ignoring c-c doesn't
come with zero cost. Because if I change an API used by thunderbird
then a bug will be filed, and it will be marked as depending on the
bug in which I changed the API, and I'll see that in bugmail, and then
I'll read the bug, and feel bad that I inconvenienced someone -- but
I'll be strong, I'll ignore that bad feeling -- and then maybe they'll
need to needinfo me to ask about the change


Yup. This matches my experience exactly. This is a good example of the
above mentioned friction.


The example above talks about changing an API but there are more 
sophisticated issues in how these code bases interact.  I will cite one 
tricky example that I ran into over the past year or so.  I started to 
look into fixing some issues in our docencoder code that directly 
affects Firefox users.  Admittedly the m-c code was completely broken in 
interesting ways when I looked at it, but after I landed my initial 
change I started to see a torrent of regressions in Thunderbird, and as 
I fixed more of the code I ended up breaking more and more in 
Thunderbird.  I spent quite a bit of time debugging the c-c side of 
things and I ended up adding some Thunderbird specific hack 
 
that is basically me avoiding rewriting the Thunderbird code hooking 
into the Gecko guts, and in some other cases I ran into issues where I 
didn't understand what behaviors Thunderbird actually relies on, the 
result of which is many unfixed regressions that are still on my plate.


If the Thunderbird code was in the tree, I would have found the broken 
code in question by grepping and I think I would probably avoid 
modifying the code after seeing the Thunderbird usage of the code 
altogether.  That would have meant I would have gotten quite a bit of my 
weekends back which is a good change for me, but it would also mean that 
none of the broken behavior in Firefox would have been fixed, which 
would be a bad change for Firefox users.  (I have effectively decided to 
avoid this code like the plague because of the way Thunderbird uses it, 
but at least now some of the fixes are already in m-c...

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

On 2015-10-26 7:17 PM, Philipp Kewisch wrote:

On 10/23/15 11:09 PM, Eric Rescorla wrote:

It may well be that having c-c code in m-c decreases friction overall,

since it saves time for the people that know they're allowed to break TB
but choose to help it anyway. However, the cost of redirected work for
contributors that _don't_ know they're allowed to break TB is real. That is
the tradeoff that needs to be weighed IMO.


What Bobby said here seems very important. In the cost/benefit analysis,
the impact on Firefox needs to be weighted very heavily. In particular,
breaking TB should not cause failures either on try or on commit, and
changes to pieces of Gecko should not be held up on their impact on TB.


If we get this right on the tooling side, I don't think it will be a
concern. For contributors that are regular Mozillians, I think it has
been clearly communicated that making changes in Firefox and Toolkit
does not require fixing Thunderbird/Seamonkey.


This is I think the crux of the issue.  "Making changes in Firefox 
doesn't require fixing Thunderbird/SeaMonkey" is far away from the truth 
in practice.


Over the years I have gained a *ton* of experience in code that 
interfaces with both Firefox and Thunderbird/SeaMonkey.  I can't really 
think of a single instance where I made a change in that code and it 
broke something in Thunderbird and the breakage was magically fixed 
without my involvement.


What happens in practice is people file bugs and ping you and unless 
we're talking about a very simple API change that is obvious to mirror 
in c-c, nobody will do anything about the regression unless if the 
Firefox developer looks at it.  So it's a choice between actively 
ignoring people (which is really being rude to them, which is not an 
option I would personally take) or having to do some work (which often 
involves reading and understanding the c-c code, debugging it, and so on.)


Now, as an employee of MoCo, I am told to spend 0 time on these issues. 
 Therefore, I try to be responsible, and nice, and spend my spare time 
to fix them.  (Saying this part with the best possible intentions) And 
you've seen how I have been treated elsewhere in the thread, in the 
sub-thread that I stopped participating in.  This situation is really 
not sustainable for a healthy community.


To me it's completely clear that the rule on paper that we have for not 
worrying about c-c has failed in practice.  I think any technical 
decision based on the imaginary idea that people can just ignore TB/SM 
code is doomed to fail.


In the past I have supported moving c-c into m-c.  I was the person who 
filed  three years 
ago.  I still think that this decision makes perfect sense from a 
technical point of view.  Every time that we have merged a satellite 
repository into m-c the result has been a net win for the ongoing 
technical work.


But there is also the policy side of things.  At Mozilla we typically 
make rules by documenting existing practices, but this is one of those 
cases where existing practices differ wildly with the rules.  I used to 
think that it's OK to just ignore the policy side of things and focus on 
the technical work, but from my personal experience the result of doing 
that is different individuals spend varying amounts of efforts on c-c 
issues (varying from 0 to substantial amounts of time) and they're all 
treated as if everyone's spending 0 amount of time, because that's what 
the rules say.


This leaves a pretty bad taste on a personal level.  But at the project 
level, it is detrimental to the health of our communities, and as a 
result to the quality of Thunderbird and SeaMonkey (and thirdly Firefox).


I have come to the conclusion that it's been a mistake to ignore the 
policy side of things in these discussions.  I honestly don't know what 
the right solution is, but I think that reducing this issue to just the 
technicality of where the source code lives is not a good way to go forward.


Best regards,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mitchell Baker]

I'm in the middle of a hectic business trip, so will write more while 
i"m on the plane home tonight.


The first thing to figure out, as Doug said, is how much support the 
project should provide Thunderbird.  5 minutes might be an obvious yes, 
as noted earlier.  At some level the answer is an obvious "no."  My 
clear recollection is that Brendan was of the view we had reached that 
point a while back, and that Thunderbird should be more separate from 
firefox-centric systems, not less. And that he was vehement about not 
merging the two repos.


In an ideal world I agree that separating the two so that Thunderbird 
team is not spending so much time dealing with Firefox systems is much 
better for thunderbird.  I also suspect that this will become more true 
over time, not less.  And I agree that Firefox and our new products will 
benefit from having a clean separation, and that we need all the forward 
momentum we can get if we are going to impact the state of the web in 
the future.


I'm not sure we're able to do this, so need to do some due diligence to 
figure out what the ideal world today is.  I personally still live in 
Thunderbird, so am interested both for the sake of the thunderbird the 
open source project, and for my own personal daily experience.


As I said, more shortly, i'm running late now.

mitchell

On 10/23/15 6:15 PM, Doug Turner wrote:

Thunderbird is under supported and potentially harmful (as Brian Smith pointed 
out on the mozilla-dev-security-policy back in Sept).  Before merging c-c into 
m-c, I think we should have agreement on what kind of support the mozilla 
project and foundation is going to give to Thunderbird.

I think that this decision really should be made by Mitchell (cced).

Doug



On Oct 23, 2015, at 7:32 PM, Robert O'Callahan  wrote:

On Sat, Oct 24, 2015 at 12:43 PM, Jonas Sicking  wrote:


But I think that the clear directive from project leadership has been
to prioritize Firefox development over other Gecko based projects.


I don't think that's unqualified. If killing off Thunderbird forever saves
a Firefox developer five minutes of work (e.g. by putting an end to this
thread), should we go ahead and do that because we're supposed to be
prioritizing Firefox development? I think clearly we shouldn't do that. We
should give Thunderbird some consideration.

I support merging c-c into m-c.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Mon, Oct 26, 2015 at 9:20 AM, Robert Kaiser  wrote:
> Jonas Sicking schrieb:
>>
>> I definitely think that some aspects of Firefox development has gotten
>> easier thanks to the split.
>
> I'd like to see which. I don't see much that has gotten easier *because of
> the split*. I see a lot that has gotten easier because we change platform
> and Firefox (mostly) without caring if we break Thunderbird or SeaMonkey

For two reasons.

First of all it'll be hard for developers to tell that they don't have
to fix certain pieces of code. A simple grep will turn up all hits in
the tree, whether they live in thunderbird code or not. And, at least
currently, mxr/dxr would return hits for all code.

Given that people are already feeling pressure to fix up thunderbird
code when they land patches, I can only see that pressure increasing
when you don't even need to pull a separate tree.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

Jonas Sicking schrieb:

Would it be possible to create a thunderbird build system which simply
takes the output of a firefox build and grabs the files that it needs,
and builds the additions that thunderbird needs.

Generally speaking, libraries don't worry about having a build system
which enables building all downstream products. It's the
responsibility of downstream products to trigger the build system of
libraries.


Yes, but our platform is not built in a way to really be able to act as 
an outside library to Thunderbird (or SeaMonkey). The idea to get it 
there was around years ago, under different names (the last of them 
being XULRunner) and it failed. So what we have is "you need to build 
all the platform code if you want to build Thunderbird, and you need to 
compile your Thunderbird-specific code into libxul even". And I think 
that's the reason where this view you bring up there doesn't apply to 
what we have.
Maybe, some years down the road, when Firefox and Thunderbird UI are all 
standard HTML, this will be all different, but until then, lives are 
much easier when all this lives into a common repository.



The goal of putting seamonkey and thunderbird in separate trees has
always been to make firefox development easier, not harder. That
should include the build system.


That was the idea, yes. In reality, we have found out that this made it 
harder, especially for the build system, and we are continuing to waste 
a lot of developer time because making sure that the build system at 
least stays usable to Thunderbird (and SeaMonkey) is slowing efforts 
down to make our build system modern and give it all kinds of 
optimizations like caching, dependency-awareness and whatnot that will 
improve development speed for all platform and Firefox developers.


As the on-paper-owner of the comm-central build system, I would heavily 
appreciate this merge (and killing off "my" module and the repository I 
created way back).


KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

Jonas Sicking schrieb:

I definitely think that some aspects of Firefox development has gotten
easier thanks to the split.


I'd like to see which. I don't see much that has gotten easier *because 
of the split*. I see a lot that has gotten easier because we change 
platform and Firefox (mostly) without caring if we break Thunderbird or 
SeaMonkey - and I think that isn't necessarily related with where the 
code actually lives.


I see where the code lives as a technical issue and how much or if we 
care to break those products when changing code as a policy issue. And I 
don't think that the proposal here is to change policy there.


KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Robert Kaiser]

Edmund Wong schrieb:

As for the long term plans, I'll wait for one of the SeaMonkey
council members to comment on that; but I believe we are determined
to maintain the SeaMonkey code.


I'll weigh in as a SeaMonkey Council member - even though I mostly watch 
what's going on while Edmund is actually one of the people doing a ton 
of work there. ;-)



From all I see and hear, those people active in the SeaMonkey project 
are committed to maintaining it for the foreseeable future.
You never know what happens years down the road, of course, and this is 
a small group of people. But then, from its inception, this was a pretty 
small group, and the project has survived for 10 years now (founded in 
March 2005, 1.0 release in January 2006).


The project has been having build infrastructure issues in recent 
months, but I hear things are somewhat improving - and actually, this 
merge would probably make quite a few things easier, as more of the same 
tooling could be used that Firefox uses (for example, all the custom 
buildbot tooling I wrote up years ago for handling c-c is a major PITA 
up to this day).


KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jörg Knobloch]

Hi all,

I have followed the discussion with interest and I'd like to suggest to 
focus on the practical aspect.


The facts are:
Thunderbird, SeaMonkey and Calendar/Lightning are Mozilla products (with 
a significant number of users).

They are maintained by dedicated communities.
(Kent has explained how the Thunderbird community is planning to ramp up 
the effort even further.)
Mozilla compiles/releases Daily, Aurora, Beta, Release and ESR versions 
of these products on a regular basis, mostly daily.


Let's implement the best technical solution which makes work easiest for 
everyone.


Simple as that, unless we are not discussing a release engineering 
problem here, but something else (as Dough hinted at (quote): "... what 
kind of support the Mozilla project and foundation is going to give to 
Thunderbird").


With kind regards from Berlin, Germany,
Jorg K (Mozilla contributor - http://www.jorgk.com/misc/Mozilla-work.pdf).


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ted Mielczarek]

On Fri, Oct 23, 2015, at 02:17 PM, Joshua Cranmer  wrote:
> Except that to demand contributors don't care about comm-central would 
> be to demand of your employees that they should be jerks to the wider 
> open-source community. Merging comm-central into mozilla-central, with 
> the exception of the time spent doing the actual merge work, would 
> reduce the amount of time that core contributors would have to spend 
> worrying about comm-central in the short and medium-terms for sure.

This is the most salient point to me--even with comm-central code in a
separate repository Mozilla employees still often try to do due
diligence to not break Thunderbird unnecessarily. Having the code in a
separate repository means they essentially always have to do *more*
work, even for trivial things like scriptable rewrites. I've had
situations where making Thunderbird work would be zero effort if it were
in m-c (since the code would be shared, like for build system work), but
I wind up breaking them because I didn't go above and beyond and clone
comm-central and duplicate my fix.

jcranmer is right. We already have lesser-supported and basically
unsupported code in the tree, this isn't going to make life any worse.

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 12:22 PM, Benjamin Smedberg wrote:
I support going back to a giant monolithic repository if we can 
cleanly delineate the code for various projects.


We know that the searchability and readability of our code is a major 
barrier to some kinds of participation. We should continue to optimize 
ourselves around that workflow.


Does this proposal come with a plan to check out subsets of the code? 
In particular, I want to express the following as something inbetween 
"serious concerns" and "requirements":


 * The default view of dxr.mozilla.org should not include non-Firefox 
code

 * The default checkout should not include non-Firefox code. (Note:
   this is about the working tree: I don't think the space in the .hg
   directory matters enough to worry about).


It's a relatively easy matter to fix the first; the second is harder to 
do for all contributors. I've been told it's a coming feature, but I've 
been told this for a while.


I also wonder why you have a peculiar insistence that comm-central code 
must not appear to any contributor, given the continued existence of 
"stuff that Firefox doesn't care about" in mozilla-central, such as 
support for tier-3 platforms (do we still have QT code in the tree) or 
xulrunner. The mere presence of code in a codebase has proven to be 
horribly insufficient to guarantee that people care about maintaining 
it--history has time and time and time again shown that any code that 
doesn't impact Treeherder results *WILL* get broken. (Easiest case in 
point: try building without unified files.)


I'm sorry that it makes you sad, but Mozilla has explicitly decided to 
prioritize the bar to entry for Firefox development, and the speed of 
development of Firefox, at the expense of Thunderbird (and seamonkey). 
And as Firefox development moves faster toward things such as stopping 
supporting XUL addons, removing support for heavyweight themes, and 
even cutting XUL altogether, we should all expect the impedance 
mismatch to become worse. We are not only saying that you don't have 
to fix comm-central apps: we're also saying that we don't *want* core 
contributors to spend time on comm-central.


Except that to demand contributors don't care about comm-central would 
be to demand of your employees that they should be jerks to the wider 
open-source community. Merging comm-central into mozilla-central, with 
the exception of the time spent doing the actual merge work, would 
reduce the amount of time that core contributors would have to spend 
worrying about comm-central in the short and medium-terms for sure.


From my perspective, your insistence on the bar to entry for Firefox 
development (or, rather, explicitly deprioritizing Thunderbird and 
Seamonkey) seems like a weak ad-hoc justification. How can you justify 
letting core contributors take the time to review patches for systems 
that Mozilla will never officially support--mingw, OpenBSD, iOS--while 
saying that they shouldn't be taking the time to review patches for 
systems that Mozilla officially supports?


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Bobby Holley]

On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer  
wrote:

Except that to demand contributors don't care about comm-central would be
> to demand of your employees that they should be jerks to the wider
> open-source community. Merging comm-central into mozilla-central, with the
> exception of the time spent doing the actual merge work, would reduce the
> amount of time that core contributors would have to spend worrying about
> comm-central in the short and medium-terms for sure.
>

I think framing it in terms of being "jerks to the wider open source
community" kind of begs the question of the tradeoff that's always at stake
here. It depends which parts of the community you're talking about.

Having c-c code visible in m-c increases the chance that a developer will
take TB into account when making changes to FF. This might come in the form
of including it in a refactoring/cleanup (and spending extra time doing
so), or in discouraging a refactoring/cleanup of machinery that TB depends
on.

We decided some time ago that we want to encourage those refactorings by
making them (a) more feasible and (b) take less time. The increase in
FF-focused refactorings and time-saving for FF-focused developers has an
outsize negative impact on TB and its developers. However, if FF has
outsize importance compared to TB, this tradeoff starts the make sense.

Mozilla makes very few "demands" of contributors. However, high-level
decisions like repository configurations can tilt the ergonomics toward or
away from Mozilla's priorities, which is why they're important.

It may well be that having c-c code in m-c decreases friction overall,
since it saves time for the people that know they're allowed to break TB
but choose to help it anyway. However, the cost of redirected work for
contributors that _don't_ know they're allowed to break TB is real. That is
the tradeoff that needs to be weighed IMO.

I also wonder why you have a peculiar insistence that comm-central code
> must not appear to any contributor, given the continued existence of "stuff
> that Firefox doesn't care about" in mozilla-central, such as support for
> tier-3 platforms (do we still have QT code in the tree) or xulrunner.


FWIW, I personally think we should remove things things from the tree.

The mere presence of code in a codebase has proven to be horribly
> insufficient to guarantee that people care about maintaining it--history
> has time and time and time again shown that any code that doesn't impact
> Treeherder results *WILL* get broken.
>

That doesn't stop people from spending time fixing already-broken code,
though, or from being discouraged from removing an unused API that is
referenced from tier-3 code.

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/23/2015 09:57 AM, Mike Hommey wrote:
> - It adds burden to developers, needing to support those projects 
> merged from comm-central. Just look around in mozilla-central at
> all the optional things that are not visible on treeherder and
> break regularly. The situation wouldn't be different in that sense.
> But the people that do care about those projects will have a better
> experience supporting them.

I don't believe this would really add a burden; we haven't had
thunderbird bustage block landing code in the past, and we're not
about to start.

One other argument against the merge I can see is machine load: right
now we don't run c-c automation in response to changes on our
integration branches, but only on the merges to m-c. Perhaps we should
keep doing that for now.

On the plus side, it could make it easier to share code between
thunderbird and the b2g email code.

> Considering all the above, are there still objections to this 
> happening, and can we finally allow Joshua to go ahead with his
> merge plan? (CCing bsmedberg, who, iirc, had Brendan's delegation
> to have the final word on this)

Strongly in favour for all the reasons you mentioned.

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWKftoAAoJEOXgvIL+s8n2ALEH/3quXXrs7lAn1qiWjdj0nfTE
r6qbmHHUL1OlfkipeFLy+vjLmI2g5ep/aKlAfYBILowaQgzFlXUiTBiz1+Yz2ChD
1UzCHOGKxcPLNYVpgEu5snBjdWhPk1DJZk5DMt390V2ldU4LVfF0f9FvIsXW6n2G
Cov/GS3KPk3rJToi82ZTjpFJdRMdh/WP6ePxDvRRJsgYiRUtdBu0jhA2Pqi0B1x6
/gmK/i0Jaw5UP/1QZd5JUjuWTuDc2Ta8bX/a3AJ/TSXbXYVcVOMrv7U55sRbN6aA
qbqNAZ/0LsCNRLqA7+2uzUV4+riX9ISgiruuL8wQJCtTXRT4KuZlmqCzDRJ3Ots=
=8jpM
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Sylvestre Ledru]

Le 23/10/2015 09:57, Mike Hommey a écrit :
> Hi,
>
> This has been discussed in the past, to no avail. I would like to reopen
> the discussion.
>
> Acknowledgment: this is heavily inspired from a list compiled by Joshua
> Cranmer, but please consider this *also* coming from me, with my build
> system peer hat on.
>
> What:
>
> Let's first summarize what this is about. This is about moving the
> development of Seamonkey, Thunderbird, and Lightning in the same
> repository as Firefox, by merging all their code and history from
> comm-central into mozilla-central.
>
> Seamonkey and Thunderbird share a lot, so comm-central without
> Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
> standalone and an addon shipped with Thunderbird, so in practice, it
> can be considered as being part of Thunderbird.
>
> Why:
>
One more argument in favor:

As Thunderbird is based on Firefox ESR, we, Firefox release managers,
are also
managing uplift requests to improve Thunderbird (especially during the
two first
ESR releases as we take stability patches).
Sometimes, we see important requests coming for Thunderbird which could
affect badly Firefox.
In these case, we rejects the uplift. Thunderbird developers have to
take them into a relbranch of Firefox ESR
(which are btw also a source of confusion for Fx RM).
While we would still have to do a relbranch for tb specific changes in
gecko, having a single repo would simplify
the situation.

Sylvestre
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Andrew Halberstadt]

On 23/10/15 04:43 AM, Gregory Szorc wrote:


- It adds burden to developers, needing to support those projects
   merged from comm-central.
 Just look around in mozilla-central at all the optional things
 that are not visible on treeherder and break regularly. The
 situation wouldn't be different in that sense. But the people
 that do care about those projects will have a better experience
 supporting them.


The other serious concern is impact to automation. Are we going to close
trees for Thunderbird failures? Are we going to run Thunderbird jobs on
every push? (Do we do this now?)


This is a decision we can make independently of merging comm-central to 
mozilla-central. We have a lot of code living in mozilla-central that 
does not get tested per push, nor does it close the trees when it fails. 
Moving to m-c does not mean that the current state of affairs for 
thunderbird needs to change. Whether or not we'd like the current state 
of affairs for thunderbird to change is another matter, but it doesn't 
need to be a blocking issue w.r.t the merge.


Big +1 for the proposal btw.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Oct 23, 2015 at 6:22 PM, Benjamin Smedberg 
wrote:

> I support going back to a giant monolithic repository if we can cleanly
> delineate the code for various projects.
>
> We know that the searchability and readability of our code is a major
> barrier to some kinds of participation. We should continue to optimize
> ourselves around that workflow.
>
> Does this proposal come with a plan to check out subsets of the code? In
> particular, I want to express the following as something inbetween "serious
> concerns" and "requirements":
>
>  * The default view of dxr.mozilla.org should not include non-Firefox code
>  * The default checkout should not include non-Firefox code. (Note:
>this is about the working tree: I don't think the space in the .hg
>directory matters enough to worry about).
>
> - TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>>number of users, behind Firefox, and before Firefox for Android and
>>Firefox OS.  Many of those users may legitimately want to contribute
>>to Thunderbird, and the bar to entry is made much higher by the
>>multi-repository setup and the extra complexity it entails. Mozilla is
>>actively making the bar to entry for Firefox/Firefox for
>>Android/Firefox OS contributions lower, at the expense of Thunderbird
>>contributors. This is a sad state of affairs.
>>
>
> I'm sorry that it makes you sad, but Mozilla has explicitly decided to
> prioritize the bar to entry for Firefox development, and the speed of
> development of Firefox, at the expense of Thunderbird (and seamonkey). And
> as Firefox development moves faster toward things such as stopping
> supporting XUL addons, removing support for heavyweight themes, and even
> cutting XUL altogether, we should all expect the impedance mismatch to
> become worse. We are not only saying that you don't have to fix
> comm-central apps: we're also saying that we don't *want* core contributors
> to spend time on comm-central.
>

There is a sparse checkout extension for Mercurial at
https://bitbucket.org/facebook/hg-experimental/src/tip/sparse.py?at=default.

Google's work on narrow clone (only actually transfer data for subset of
files) is coming along at https://bitbucket.org/Google/narrowhg. This will
require support on hg.mozilla.org and maybe a flag day.

Sparse doesn't require server cooperation. Individuals could start using it
today if they wanted.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 3:43 AM, Gregory Szorc wrote:

IMO this is one of the two serious concerns. However, I /think/ it will
only add an incremental burden. If nothing else, perhaps this will force us
to better invest in tools that automatically handle refactorings.

The other serious concern is impact to automation. Are we going to close
trees for Thunderbird failures? Are we going to run Thunderbird jobs on
every push? (Do we do this now?)


The automation aspects are open to some debate as to the most reasonable 
way to implement them (caveated on what our infrastructure can support). 
Our buildbot infrastructure currently supports triggering builds if only 
certain files are changed--so changing SeaMonkey-only code, for example, 
doesn't trigger a Thunderbird build and vice versa.


I think it's reasonable to expect that Thunderbird failures do not close 
trees (and I've heard that one of the design goals of Treeherder is/was 
to make project-specific "tier 1" views that would make this easier). I 
also think it's reasonable to not build Thunderbird on every m-i checkin 
or every try push. The main model I've envisioned is to build on every 
m-{c,a,b,esr} checkin and only build on m-i if a comm-central file is 
changed (correspondingly not building FF if only TB-specific code is 
touched), with try handled via an extra -a "app" option, although other 
models (e.g., retaining c-c as a project branch like build-system or 
fx-team) are plausible. I'd like to invite release engineers and 
sheriffs to suggest easier models if they can, since they have much more 
experience here.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 11:56 AM, Fabrice Desré wrote:

On Fri, 23 Oct 2015 11:18:32 +0200, Ms2ger wrote:
  

On the plus side, it could make it easier to share code between
thunderbird and the b2g email code.

Not really since the b2g email app is on github and doesn't share code
with thunderbird for now.


Actually, the b2g email app does reuse JSMime (or at least will be shortly).

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Nicholas Alexander]

+1 from me.  I'd just like to speak to one small part below.

On Fri, Oct 23, 2015 at 12:57 AM, Mike Hommey  wrote:

> Hi,
>
> This has been discussed in the past, to no avail. I would like to reopen
> the discussion.
>



- It sets a bad precedent, other Gecko-based projects might want to
>   merge.
>   - mobile/ set the precedent half a decade ago.
>   - as mentioned above, historically, everything was in the same
> repository, and the split can be argued to be the oddity here
>   - there are barely any Gecko-based projects left that are not in
> comm-central.
>

I've done a lot of mobile-specific build things.  mobile/ was merged into
m-c before I began working on it, but I can't imagine the overhead of doing
half the work in m-c and half of it in a separate repository.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Fabrice Desré]

On Fri, 23 Oct 2015 11:18:32 +0200, Ms2ger wrote:
 
> On the plus side, it could make it easier to share code between
> thunderbird and the b2g email code.

Not really since the b2g email app is on github and doesn't share code 
with thunderbird for now.

  Fabrice
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Benjamin Smedberg]

I support going back to a giant monolithic repository if we can cleanly 
delineate the code for various projects.


We know that the searchability and readability of our code is a major 
barrier to some kinds of participation. We should continue to optimize 
ourselves around that workflow.


Does this proposal come with a plan to check out subsets of the code? In 
particular, I want to express the following as something inbetween 
"serious concerns" and "requirements":


 * The default view of dxr.mozilla.org should not include non-Firefox code
 * The default checkout should not include non-Firefox code. (Note:
   this is about the working tree: I don't think the space in the .hg
   directory matters enough to worry about).


- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
   number of users, behind Firefox, and before Firefox for Android and
   Firefox OS.  Many of those users may legitimately want to contribute
   to Thunderbird, and the bar to entry is made much higher by the
   multi-repository setup and the extra complexity it entails. Mozilla is
   actively making the bar to entry for Firefox/Firefox for
   Android/Firefox OS contributions lower, at the expense of Thunderbird
   contributors. This is a sad state of affairs.


I'm sorry that it makes you sad, but Mozilla has explicitly decided to 
prioritize the bar to entry for Firefox development, and the speed of 
development of Firefox, at the expense of Thunderbird (and seamonkey). 
And as Firefox development moves faster toward things such as stopping 
supporting XUL addons, removing support for heavyweight themes, and even 
cutting XUL altogether, we should all expect the impedance mismatch to 
become worse. We are not only saying that you don't have to fix 
comm-central apps: we're also saying that we don't *want* core 
contributors to spend time on comm-central.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Edmund Wong]

Ehsan Akhgari wrote:
> On 2015-10-23 2:17 PM, Joshua Cranmer  wrote:
>> It's a relatively easy matter to fix the first; the second is harder to
>> do for all contributors. I've been told it's a coming feature, but I've
>> been told this for a while.
>>
>> I also wonder why you have a peculiar insistence that comm-central code
>> must not appear to any contributor, given the continued existence of
>> "stuff that Firefox doesn't care about" in mozilla-central, such as
>> support for tier-3 platforms (do we still have QT code in the tree) or
>> xulrunner. The mere presence of code in a codebase has proven to be
>> horribly insufficient to guarantee that people care about maintaining
>> it--history has time and time and time again shown that any code that
>> doesn't impact Treeherder results *WILL* get broken. (Easiest case in
>> point: try building without unified files.)
> 
> What matters more about what code remains in the tree and what code
> doesn't is whether it's maintained.  We have in the past removed code
> for these tier3 ports and products when they have been unmaintained
> (example: bug 969757) and we should be doing more of that.
> 
> What are the long term plans for the Thunderbird and SeaMonkey community
> to maintain their code, if it gets merged into m-c?  On tb-planning I
> see ongoing discussions about moving to other platforms such as
> Electron, or the broader doubts about how Thunderbird wants to deal with
> future upcoming changes such as the current add-ons?

The SeaMonkey community is still maintaining the code; it's just that
we haven't been able to do it that effectively the past year due to
the fact that we're behind in the infrastructure setup and we've been
trying to keep our tree unbroken due to changes in m-*.  That said,
I really appreciate those who also lent a hand to help SeaMonkey's
trees become green(or relatively green with a hint of orange and red).

As for the long term plans, I'll wait for one of the SeaMonkey
council members to comment on that; but I believe we are determined
to maintain the SeaMonkey code.

Edmund

Edmund
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

On 2015-10-23 2:17 PM, Joshua Cranmer  wrote:

It's a relatively easy matter to fix the first; the second is harder to
do for all contributors. I've been told it's a coming feature, but I've
been told this for a while.

I also wonder why you have a peculiar insistence that comm-central code
must not appear to any contributor, given the continued existence of
"stuff that Firefox doesn't care about" in mozilla-central, such as
support for tier-3 platforms (do we still have QT code in the tree) or
xulrunner. The mere presence of code in a codebase has proven to be
horribly insufficient to guarantee that people care about maintaining
it--history has time and time and time again shown that any code that
doesn't impact Treeherder results *WILL* get broken. (Easiest case in
point: try building without unified files.)


What matters more about what code remains in the tree and what code 
doesn't is whether it's maintained.  We have in the past removed code 
for these tier3 ports and products when they have been unmaintained 
(example: bug 969757) and we should be doing more of that.


What are the long term plans for the Thunderbird and SeaMonkey community 
to maintain their code, if it gets merged into m-c?  On tb-planning I 
see ongoing discussions about moving to other platforms such as 
Electron, or the broader doubts about how Thunderbird wants to deal with 
future upcoming changes such as the current add-ons?


Without long term plans for the code being maintained, we should not 
move it into m-c.



Except that to demand contributors don't care about comm-central would
be to demand of your employees that they should be jerks to the wider
open-source community.


As pointed out by others, this is completely untrue, and I personally 
think that framing the problem like this isn't the most helpful.


Please note that even if we move the code into m-c, we will continue to 
break it (unintentionally) so Thunderbird will still see regressions 
caused by "upstream" changes that they need to deal with.


> Merging comm-central into mozilla-central, with

the exception of the time spent doing the actual merge work, would
reduce the amount of time that core contributors would have to spend
worrying about comm-central in the short and medium-terms for sure.


I don't think one could assert this or the opposite.


 From my perspective, your insistence on the bar to entry for Firefox
development (or, rather, explicitly deprioritizing Thunderbird and
Seamonkey) seems like a weak ad-hoc justification. How can you justify
letting core contributors take the time to review patches for systems
that Mozilla will never officially support--mingw, OpenBSD, iOS--while
saying that they shouldn't be taking the time to review patches for
systems that Mozilla officially supports?


Speaking as someone who has reviewed quite a few such patches, and also 
as someone who has tried to bend over backwards and sideways to serve 
Thunderbird's needs, there is a huge difference between the two.  The 
patches to maintain tier3 platforms are typically written by the 
maintainers for such platforms and for the most part are tiny and simple 
patches, but the outcome c-c breaking because of an m-c changes are 
sometimes in form of complaints and not patches to fix the issues.


Now, where the code is in theory non-consequential towards the behavior 
of people in response to an upstream breakage.  So let's focus on the 
implications of where the code lives, and not conflate that with the 
frictions between the communities.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Doug Turner]

Thunderbird is under supported and potentially harmful (as Brian Smith pointed 
out on the mozilla-dev-security-policy back in Sept).  Before merging c-c into 
m-c, I think we should have agreement on what kind of support the mozilla 
project and foundation is going to give to Thunderbird.

I think that this decision really should be made by Mitchell (cced).

Doug


> On Oct 23, 2015, at 7:32 PM, Robert O'Callahan  wrote:
> 
> On Sat, Oct 24, 2015 at 12:43 PM, Jonas Sicking  wrote:
> 
>> But I think that the clear directive from project leadership has been
>> to prioritize Firefox development over other Gecko based projects.
>> 
> 
> I don't think that's unqualified. If killing off Thunderbird forever saves
> a Firefox developer five minutes of work (e.g. by putting an end to this
> thread), should we go ahead and do that because we're supposed to be
> prioritizing Firefox development? I think clearly we shouldn't do that. We
> should give Thunderbird some consideration.
> 
> I support merging c-c into m-c.
> 
> Rob
> -- 
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mitchell Baker]

Yes, this is a good topic and I agree i'm a necessary party here.
Is there some way of getting a good sense of the work that we're talking 
about?


mitchell

On 10/23/15 6:15 PM, Doug Turner wrote:

Thunderbird is under supported and potentially harmful (as Brian Smith pointed 
out on the mozilla-dev-security-policy back in Sept).  Before merging c-c into 
m-c, I think we should have agreement on what kind of support the mozilla 
project and foundation is going to give to Thunderbird.

I think that this decision really should be made by Mitchell (cced).

Doug



On Oct 23, 2015, at 7:32 PM, Robert O'Callahan  wrote:

On Sat, Oct 24, 2015 at 12:43 PM, Jonas Sicking  wrote:


But I think that the clear directive from project leadership has been
to prioritize Firefox development over other Gecko based projects.


I don't think that's unqualified. If killing off Thunderbird forever saves
a Firefox developer five minutes of work (e.g. by putting an end to this
thread), should we go ahead and do that because we're supposed to be
prioritizing Firefox development? I think clearly we shouldn't do that. We
should give Thunderbird some consideration.

I support merging c-c into m-c.

Rob
--
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Mike Hommey]

On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
> I support going back to a giant monolithic repository if we can cleanly
> delineate the code for various projects.
> 
> We know that the searchability and readability of our code is a major
> barrier to some kinds of participation. We should continue to optimize
> ourselves around that workflow.
> 
> Does this proposal come with a plan to check out subsets of the code? In
> particular, I want to express the following as something inbetween "serious
> concerns" and "requirements":
> 
>  * The default view of dxr.mozilla.org should not include non-Firefox code
>  * The default checkout should not include non-Firefox code. (Note:
>this is about the working tree: I don't think the space in the .hg
>directory matters enough to worry about).
> 
> >- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
> >   number of users, behind Firefox, and before Firefox for Android and
> >   Firefox OS.  Many of those users may legitimately want to contribute
> >   to Thunderbird, and the bar to entry is made much higher by the
> >   multi-repository setup and the extra complexity it entails. Mozilla is
> >   actively making the bar to entry for Firefox/Firefox for
> >   Android/Firefox OS contributions lower, at the expense of Thunderbird
> >   contributors. This is a sad state of affairs.
> 
> I'm sorry that it makes you sad, but Mozilla has explicitly decided to
> prioritize the bar to entry for Firefox development, and the speed of
> development of Firefox, at the expense of Thunderbird (and seamonkey).

What's even more sad is that it's at the expense of Thunderbird (and
SeaMonkey) *and* at the expense of Firefox build system changes.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Bobby Holley]

On Fri, Oct 23, 2015 at 2:08 PM, Mike Hommey  wrote:

> On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
> > I support going back to a giant monolithic repository if we can cleanly
> > delineate the code for various projects.
> >
> > We know that the searchability and readability of our code is a major
> > barrier to some kinds of participation. We should continue to optimize
> > ourselves around that workflow.
> >
> > Does this proposal come with a plan to check out subsets of the code? In
> > particular, I want to express the following as something inbetween
> "serious
> > concerns" and "requirements":
> >
> >  * The default view of dxr.mozilla.org should not include non-Firefox
> code
> >  * The default checkout should not include non-Firefox code. (Note:
> >this is about the working tree: I don't think the space in the .hg
> >directory matters enough to worry about).
> >
> > >- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
> > >   number of users, behind Firefox, and before Firefox for Android and
> > >   Firefox OS.  Many of those users may legitimately want to contribute
> > >   to Thunderbird, and the bar to entry is made much higher by the
> > >   multi-repository setup and the extra complexity it entails. Mozilla
> is
> > >   actively making the bar to entry for Firefox/Firefox for
> > >   Android/Firefox OS contributions lower, at the expense of Thunderbird
> > >   contributors. This is a sad state of affairs.
> >
> > I'm sorry that it makes you sad, but Mozilla has explicitly decided to
> > prioritize the bar to entry for Firefox development, and the speed of
> > development of Firefox, at the expense of Thunderbird (and seamonkey).
>
> What's even more sad is that it's at the expense of Thunderbird (and
> SeaMonkey) *and* at the expense of Firefox build system changes.
>

That may be a reason for the people working on the build system to refactor
it without consideration for Thunderbird. That may sound heartless, but it
is the current directive from the organization that is paying us to work on
m-c.

Whether or not Mozilla should change that directive is a separate
discussion. But as it stands, the only reason Thunderbird can possibly
stand in the way of changes to Firefox is if developers are bucking the
"ignore Thunderbird" directive to some degree.

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

On 2015-10-23 5:20 PM, R Kent James wrote:

On 10/23/2015 1:21 PM, Ehsan Akhgari wrote:

What are the long term plans for the Thunderbird and SeaMonkey community
to maintain their code, if it gets merged into m-c?  On tb-planning I
see ongoing discussions about moving to other platforms such as
Electron, or the broader doubts about how Thunderbird wants to deal with
future upcoming changes such as the current add-ons?

Without long term plans for the code being maintained, we should not
move it into m-c.


Several core Thunderbird team members are meeting with Mark Surman in
Toronto next week to discuss establishing Thunderbird as a formal
Mozilla Foundation project (which looks very likely to happen). Part of
that will be implementing our funding plan, which is targeted at having
$500,000 per year available for Thunderbird maintenance and enhancement.


Financial support from MoFo on Thunderbird has no bearing on the 
technical details under discussion here, as far as I understand.  That 
money can be spent on keeping up with upstream changes, moving away from 
Gecko, or anything else.



So yes we are working quite diligently on long-term plans for
Thunderbird code maintenance and enhancement. (I can't speak for
SeaMonkey). We recognize that the status quo has been less than optimal,
and we are working hard to improve that. Funny though, in spite of many
mishaps and new competition, our user base keeps growing (new record
this week of 9.6 million ADI!).


The user base also has no bearing on the discussion at hand.  Think of 
it this way, if Thunderbird had 10x the user base of Firefox, we would 
still be having the exact same conversation.



As for discussions about other options on tb-planning, you need to
consider those in the same context as other similar discussions about
Firefox. I've seen comments about Firefox moving to servo, and of course
there is the well-known deprecation of XUL, both of which will result in
large existing portions of m-c being made obsolete. Just as the Firefox
hg repos will adapt to their changes, so the Thunderbird hg repos will
adapt to changes.


That doesn't answer my question.

Let me rephrase.  Are Thunderbird and SeaMonkey committed towards long 
term maintenance of their code, should it be moved into mozilla-central? 
 That is the bare minimum necessary (but not sufficient) condition for 
having this conversation.


From what I have seen in the aforementioned forum, it seems like at 
least on the Thunderbird side things are pretty much unclear at this 
point, so the answer to the above question cannot be yes.


I am not in favor of moving the repo unless if there is full commitment 
towards that long term maintenance.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[R Kent James]

On 10/23/2015 2:42 PM, Ehsan Akhgari wrote:


Firefox hg repos will adapt to their changes, so the Thunderbird hg 
repos will adapt to changes.


That doesn't answer my question.


No, but it does address that issue that you brought up, whether 
discussions of other major directions for Thunderbird (branching, 
Electron) have a bearing on whether hg (and mozilla-central) makes sense 
for Thunderbird. My point is our position is no different than the 
position of Firefox.




Let me rephrase.  Are Thunderbird and SeaMonkey committed towards long 
term maintenance of their code, should it be moved into 
mozilla-central?  That is the bare minimum necessary (but not 
sufficient) condition for having this conversation.


If you want a yes/no answer, the answer is "yes" (for Thunderbird, I 
cannot speak for Seamonkey). But I doubt if my personal "yes" is 
sufficient, which is why I gave some details on concrete actions that we 
are taking to develop the resources to maintain our code. If my personal 
"yes" is not sufficient, and my comments on planning are not helpful, 
what would be helpful to gauge our commitment?


:rkent


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Eric Rescorla]

On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc  wrote:

> On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey  wrote:
>
> > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
> > > I support going back to a giant monolithic repository if we can cleanly
> > > delineate the code for various projects.
> > >
> > > We know that the searchability and readability of our code is a major
> > > barrier to some kinds of participation. We should continue to optimize
> > > ourselves around that workflow.
> > >
> > > Does this proposal come with a plan to check out subsets of the code?
> In
> > > particular, I want to express the following as something inbetween
> > "serious
> > > concerns" and "requirements":
> > >
> > >  * The default view of dxr.mozilla.org should not include non-Firefox
> > code
> > >  * The default checkout should not include non-Firefox code. (Note:
> > >this is about the working tree: I don't think the space in the .hg
> > >directory matters enough to worry about).
> > >
> > > >- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
> > > >   number of users, behind Firefox, and before Firefox for Android and
> > > >   Firefox OS.  Many of those users may legitimately want to
> contribute
> > > >   to Thunderbird, and the bar to entry is made much higher by the
> > > >   multi-repository setup and the extra complexity it entails. Mozilla
> > is
> > > >   actively making the bar to entry for Firefox/Firefox for
> > > >   Android/Firefox OS contributions lower, at the expense of
> Thunderbird
> > > >   contributors. This is a sad state of affairs.
> > >
> > > I'm sorry that it makes you sad, but Mozilla has explicitly decided to
> > > prioritize the bar to entry for Firefox development, and the speed of
> > > development of Firefox, at the expense of Thunderbird (and seamonkey).
> >
> > What's even more sad is that it's at the expense of Thunderbird (and
> > SeaMonkey) *and* at the expense of Firefox build system changes.
>
>
> I want to reiterate my original response and what Mike said in the original
> post.
>
> We'll be investing pretty heavily in the Firefox build system in 2016. I
> cannot stress enough the pain comm-central's existence as a separate
> repository gives us when trying to make build system, mach, and automation
> changes. It slows us down and makes our lives (and code!) more painful than
> they could be.
>

Can you explain why this is? Is it that the Firefox build system does not
build the artifacts you would need to then build TB or is it that you need
to somehow figure out how to make TB build alongside Firefox?

-Ekr


> Continued existence of comm-central as a separate repository will slow down
> build system, tools, and automation progress. The developer productivity
> survey results say that Mozilla staff overwhelmingly want these things to
> be much better. A vote against this proposal is a vote against making the
> jobs of "toolers" easier and a vote delaying the progress of improvements
> to developer workflows, infrastructure, productivity, and happiness.
>
> As a "tooler" who wants to make your lives better, I emphatically support
> merging comm-central into mozilla-central.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Eric Rescorla]

Thanks for clarifying. Based on this, it seems like another way to solve
this would be to simply
stop worrying about breaking comm-central. Wouldn't that be even easier?

-Ekr




On Fri, Oct 23, 2015 at 3:38 PM, Gregory Szorc  wrote:

> On Fri, Oct 23, 2015 at 11:13 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc  wrote:
>>
>>> On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey  wrote:
>>>
>>> > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
>>> > > I support going back to a giant monolithic repository if we can
>>> cleanly
>>> > > delineate the code for various projects.
>>> > >
>>> > > We know that the searchability and readability of our code is a major
>>> > > barrier to some kinds of participation. We should continue to
>>> optimize
>>> > > ourselves around that workflow.
>>> > >
>>> > > Does this proposal come with a plan to check out subsets of the
>>> code? In
>>> > > particular, I want to express the following as something inbetween
>>> > "serious
>>> > > concerns" and "requirements":
>>> > >
>>> > >  * The default view of dxr.mozilla.org should not include
>>> non-Firefox
>>> > code
>>> > >  * The default checkout should not include non-Firefox code. (Note:
>>> > >this is about the working tree: I don't think the space in the .hg
>>> > >directory matters enough to worry about).
>>> > >
>>> > > >- TTBOMK, Thunderbird is Mozilla's second largest project in terms
>>> of
>>> > > >   number of users, behind Firefox, and before Firefox for Android
>>> and
>>> > > >   Firefox OS.  Many of those users may legitimately want to
>>> contribute
>>> > > >   to Thunderbird, and the bar to entry is made much higher by the
>>> > > >   multi-repository setup and the extra complexity it entails.
>>> Mozilla
>>> > is
>>> > > >   actively making the bar to entry for Firefox/Firefox for
>>> > > >   Android/Firefox OS contributions lower, at the expense of
>>> Thunderbird
>>> > > >   contributors. This is a sad state of affairs.
>>> > >
>>> > > I'm sorry that it makes you sad, but Mozilla has explicitly decided
>>> to
>>> > > prioritize the bar to entry for Firefox development, and the speed of
>>> > > development of Firefox, at the expense of Thunderbird (and
>>> seamonkey).
>>> >
>>> > What's even more sad is that it's at the expense of Thunderbird (and
>>> > SeaMonkey) *and* at the expense of Firefox build system changes.
>>>
>>>
>>> I want to reiterate my original response and what Mike said in the
>>> original
>>> post.
>>>
>>> We'll be investing pretty heavily in the Firefox build system in 2016. I
>>> cannot stress enough the pain comm-central's existence as a separate
>>> repository gives us when trying to make build system, mach, and
>>> automation
>>> changes. It slows us down and makes our lives (and code!) more painful
>>> than
>>> they could be.
>>>
>>
>> Can you explain why this is? Is it that the Firefox build system does not
>> build the artifacts you would need to then build TB or is it that you need
>> to somehow figure out how to make TB build alongside Firefox?
>>
>
> comm-central's build system and tools are bolted on extensions to
> mozilla-central's corresponding tools, which aren't really meant to be
> extended in that way. mozilla-central's build system and tools like mach
> have to make special considerations for running inside comm-central. The
> relationships are hacky, not very well defined, don't have much visibility,
> hard to debug, and are prone to breakage. The extra code complexity to
> support running things from a separate repository (which means things like
> teaching tools about the existence of multiple source directories) really
> weighs us down. I've lost several days to "because comm-central" issues.
>
> As a concrete example that's come up in the past few weeks, we can't
> easily make wanted changes to jar.mn files or packaging of add-ons/XPIs
> because it means developing, testing, and coordinating landing of changes
> across mozilla-central and comm-central. It's much easier to let
> sub-optimal patterns linger in mozilla-central because the overhead of
> developing a parallel set of changes for comm-central is too high. I dare
> say the knowledge of impending dread from having to deal with comm-central
> fallout has discouraged me from making major build system and tooling
> changes. This situation passively hurts everyone.
>
>
>>
>>> Continued existence of comm-central as a separate repository will slow
>>> down
>>> build system, tools, and automation progress. The developer productivity
>>> survey results say that Mozilla staff overwhelmingly want these things to
>>> be much better. A vote against this proposal is a vote against making the
>>> jobs of "toolers" easier and a vote delaying the progress of improvements
>>> to developer workflows, infrastructure, productivity, and happiness.
>>>
>>> As a "tooler" who wants to make your lives 

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Fri, Oct 23, 2015 at 4:30 PM, Gregory Szorc  wrote:
> If we (m-c build peers) didn't care about comm-central at all, I can pretty
> much guarantee that comm-central would be perpetually broken once m-c build
> system improvements ramp up in the months ahead. C-c's contributors would
> have to spend an inordinate amount of time trying to keep pace with m-c
> changes.

I guess this is the solution I was proposing. It's really sad if this
is not possible and to be honest I'm not really sure what solution I'm
proposing.

One option is of course for Thunderbird to fork, and maybe rejoin once
the build changes have settled.

If thunderbird doesn't have the cycles to keep up with build system
changes, it seems even less realistic to keep up with XUL going away.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 4:42 PM, Ehsan Akhgari wrote:
Let me rephrase.  Are Thunderbird and SeaMonkey committed towards long 
term maintenance of their code, should it be moved into 
mozilla-central?  That is the bare minimum necessary (but not 
sufficient) condition for having this conversation.


From what I have seen in the aforementioned forum, it seems like at 
least on the Thunderbird side things are pretty much unclear at this 
point, so the answer to the above question cannot be yes.


I don't know why the hell you think the answer to that question is 
anything other than yes. Kent is a pessimist, and he sees the current 
signs as that Mozilla is basically trying to throw us under the bus (and 
this current thread suggests that there a few here paying the bus driver 
to run over the corpse a few times), so he is highly motivated to find 
alternative long-term plans to *continue* the maintenance of 
Thunderbird. Indeed, the very fact that we're angling for this change to 
happen, despite the rather intense political fight that is ensuing, is 
itself a loud voice of commitment to maintaining the code.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[R Kent James]

On 10/23/2015 3:09 PM, Ehsan Akhgari wrote:

Hmm, I'm having difficulty reconciling what you're saying above with
this email from two days ago
.
  What happens if Thunderbird decides on option 3 listed there (move
away from using Gecko to another framework) and the code lives in m-c?
Do you mean that the code in m-c will be made to work with another
framework?  Or that code would be abandoned the new Thunderbird will be
developed in another repository?  Or something else?


The "move away from using Gecko to another framework" option would occur 
at earliest three years from now according to a different email posting. 
And this is a discussion only, not a commitment.


If that option were to move forward, the plan would be to use to the 
maximum extent possible during a transition the same code between a 
Gecko-based Thunderbird and an HTML/CSS/JS-based Thunderbird. Whether 
that would mean using a Github or hg.m.o as the canonical repo is way 
beyond any discussions we have had, but based on previous experience, 
were Github to be canonical, then files for particular versions would 
still need to be landed in hg.m.o  Any C++ builds into xul.lib would 
clearly always be in hg.m.o


This as I understand it is the same discussion that Firefox intends to 
have in the post-XUL world. As browser.html is currently a Github repo 
without threatening m-c, I don't see how mailnews.html is any different. 
Another parallel is Gaia which resides in Github while other parts of 
Firefox reside in m-c. These are concrete, current examples in the 
Firefox world, while any discussions of a similar set of features for 
Thunderbird are three years in the future.


:rkent


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 3:21 PM, Ehsan Akhgari wrote:

Except that to demand contributors don't care about comm-central would
be to demand of your employees that they should be jerks to the wider
open-source community.


As pointed out by others, this is completely untrue, and I personally 
think that framing the problem like this isn't the most helpful.
Even if the module owners didn't actively write the patches themselves, 
they'd still have to deal with the inquiries and reviews by comm-central 
authors, which, given the asymmetry of knowledge, is likely to take as 
much if not more of their time in total. If they aren't to spend time on 
comm-central, then that's saying nothing less than they shouldn't even 
talk to us and ignore any patches we request--in other words, saying 
that they should be jerks.


Please note that even if we move the code into m-c, we will continue 
to break it (unintentionally) so Thunderbird will still see 
regressions caused by "upstream" changes that they need to deal with.


While I'd like that this not be the case, I've long ago accepted that 
this will continue to be the case. Nothing about this proposal was ever 
intended to change this.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Oct 23, 2015 at 11:39 PM, Jonas Sicking  wrote:

> On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc  wrote:
> >
> > We'll be investing pretty heavily in the Firefox build system in 2016. I
> > cannot stress enough the pain comm-central's existence as a separate
> > repository gives us when trying to make build system, mach, and
> automation
> > changes. It slows us down and makes our lives (and code!) more painful
> than
> > they could be.
>
> Can this be solved without migrating c-c into m-c?
>

Would it be possible to create a thunderbird build system which simply
> takes the output of a firefox build and grabs the files that it needs,
> and builds the additions that thunderbird needs.
>
>
Given enough time and resources, c-c's build system could be overhauled.
But as it literally uses mozilla-central's build system and is intricately
tied to it, this effort is roughly equatable with overhauling m-c's build
system. i.e. not trivial. As build module owner, it is my opinion that it
is an easier path to incrementally move both build system's to the future
when they are in one repository.

If we (m-c build peers) didn't care about comm-central at all, I can pretty
much guarantee that comm-central would be perpetually broken once m-c build
system improvements ramp up in the months ahead. C-c's contributors would
have to spend an inordinate amount of time trying to keep pace with m-c
changes.


> Generally speaking, libraries don't worry about having a build system
> which enables building all downstream products. It's the
> responsibility of downstream products to trigger the build system of
> libraries.
>

> The goal of putting seamonkey and thunderbird in separate trees has
> always been to make firefox development easier, not harder. That
> should include the build system.
>

I wish I could join you in the ivory tower. But we have 10+ years of
technical debt in the build system(s) we're working against. If things were
easy, they would have been fixed already.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Bobby Holley]

On Fri, Oct 23, 2015 at 4:30 PM, Gregory Szorc  wrote:

> If we (m-c build peers) didn't care about comm-central at all, I can pretty
> much guarantee that comm-central would be perpetually broken once m-c build
> system improvements ramp up in the months ahead. C-c's contributors would
> have to spend an inordinate amount of time trying to keep pace with m-c
> changes.
>

I want to highlight this, because it is the crux of this discussion.

We have three options:
(1) Build peers do a bunch of extra work to support c-c in a separate repo.
(2) We land c-c in m-c, so that build peers can support it without much
extra work.
(3) We don't land c-c in m-c, build peers ignore c-c, and TB fends for
itself as pure downstream.

(1) seems strictly sub-optimal. The decision here is pretty much between
(2) and (3).

bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Fri, Oct 23, 2015 at 3:53 PM, Joshua Cranmer   wrote:
>> The goal of putting seamonkey and thunderbird in separate trees has
>> always been to make firefox development easier, not harder. That
>> should include the build system.
>
> And the point of this thread is that it hasn't, and I can't emphasis this
> point enough. The current split is causing extreme pain on both sides of the
> divide, and I fear that the people who object to this have no conception of
> just how bad of a problem this has been. It's a case of grievously wounding
> those who make silent, heroic efforts against the theoretical pricks of
> someone who may not even exist.

I definitely think that some aspects of Firefox development has gotten
easier thanks to the split.

Sounds like the build system has not. I agree that we need to change
something to improve that situation.

I can't say that I have detailed proposal to make here.

But I think that the clear directive from project leadership has been
to prioritize Firefox development over other Gecko based projects.

My recommendation would be to make whatever build system changes are
needed in order to make the firefox build system as awesome as
possible. Then add minimal hooks which enables c-c to build. Ideally
such hooks are contributed by the thunderbird team.

I'd also expect those hooks to need changing every now and then as the
firefox build system evolves. Again, I think the responsibility to of
the thunderbird developers to keep such hooks working.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Ehsan Akhgari]

On 2015-10-23 6:00 PM, R Kent James wrote:

On 10/23/2015 2:42 PM, Ehsan Akhgari wrote:



Firefox hg repos will adapt to their changes, so the Thunderbird hg
repos will adapt to changes.


That doesn't answer my question.


No, but it does address that issue that you brought up, whether
discussions of other major directions for Thunderbird (branching,
Electron) have a bearing on whether hg (and mozilla-central) makes sense
for Thunderbird. My point is our position is no different than the
position of Firefox.


It's totally different than Firefox.  No matter what code changes we 
make to Firefox, it will be built from the code in m-c.  That's not true 
today for Thunderbird.



Let me rephrase.  Are Thunderbird and SeaMonkey committed towards long
term maintenance of their code, should it be moved into
mozilla-central?  That is the bare minimum necessary (but not
sufficient) condition for having this conversation.


If you want a yes/no answer, the answer is "yes" (for Thunderbird, I
cannot speak for Seamonkey). But I doubt if my personal "yes" is
sufficient, which is why I gave some details on concrete actions that we
are taking to develop the resources to maintain our code. If my personal
"yes" is not sufficient, and my comments on planning are not helpful,
what would be helpful to gauge our commitment?


Hmm, I'm having difficulty reconciling what you're saying above with 
this email from two days ago 
. 
 What happens if Thunderbird decides on option 3 listed there (move 
away from using Gecko to another framework) and the code lives in m-c? 
Do you mean that the code in m-c will be made to work with another 
framework?  Or that code would be abandoned the new Thunderbird will be 
developed in another repository?  Or something else?


Note that when options such as what I quoted above are still on the 
table, it seems like the discussion as to whether the code needs to live 
in m-c is premature.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Eric Rescorla]

On Fri, Oct 23, 2015 at 11:45 AM, Bobby Holley 
wrote:

> On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer  
> wrote:
>
> Except that to demand contributors don't care about comm-central would be
> > to demand of your employees that they should be jerks to the wider
> > open-source community. Merging comm-central into mozilla-central, with
> the
> > exception of the time spent doing the actual merge work, would reduce the
> > amount of time that core contributors would have to spend worrying about
> > comm-central in the short and medium-terms for sure.
> >
>
> I think framing it in terms of being "jerks to the wider open source
> community" kind of begs the question of the tradeoff that's always at stake
> here. It depends which parts of the community you're talking about.
>
> Having c-c code visible in m-c increases the chance that a developer will
> take TB into account when making changes to FF. This might come in the form
> of including it in a refactoring/cleanup (and spending extra time doing
> so), or in discouraging a refactoring/cleanup of machinery that TB depends
> on.
>
> We decided some time ago that we want to encourage those refactorings by
> making them (a) more feasible and (b) take less time. The increase in
> FF-focused refactorings and time-saving for FF-focused developers has an
> outsize negative impact on TB and its developers. However, if FF has
> outsize importance compared to TB, this tradeoff starts the make sense.
>
> Mozilla makes very few "demands" of contributors. However, high-level
> decisions like repository configurations can tilt the ergonomics toward or
> away from Mozilla's priorities, which is why they're important.
>
> It may well be that having c-c code in m-c decreases friction overall,
> since it saves time for the people that know they're allowed to break TB
> but choose to help it anyway. However, the cost of redirected work for
> contributors that _don't_ know they're allowed to break TB is real. That is
> the tradeoff that needs to be weighed IMO.


What Bobby said here seems very important. In the cost/benefit analysis,
the impact on Firefox needs to be weighted very heavily. In particular,
breaking TB should not cause failures either on try or on commit, and
changes to pieces of Gecko should not be held up on their impact on TB.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[R Kent James]

On 10/23/2015 1:21 PM, Ehsan Akhgari wrote:

What are the long term plans for the Thunderbird and SeaMonkey community
to maintain their code, if it gets merged into m-c?  On tb-planning I
see ongoing discussions about moving to other platforms such as
Electron, or the broader doubts about how Thunderbird wants to deal with
future upcoming changes such as the current add-ons?

Without long term plans for the code being maintained, we should not
move it into m-c.


Several core Thunderbird team members are meeting with Mark Surman in 
Toronto next week to discuss establishing Thunderbird as a formal 
Mozilla Foundation project (which looks very likely to happen). Part of 
that will be implementing our funding plan, which is targeted at having 
$500,000 per year available for Thunderbird maintenance and enhancement.


So yes we are working quite diligently on long-term plans for 
Thunderbird code maintenance and enhancement. (I can't speak for 
SeaMonkey). We recognize that the status quo has been less than optimal, 
and we are working hard to improve that. Funny though, in spite of many 
mishaps and new competition, our user base keeps growing (new record 
this week of 9.6 million ADI!).


As for discussions about other options on tb-planning, you need to 
consider those in the same context as other similar discussions about 
Firefox. I've seen comments about Firefox moving to servo, and of course 
there is the well-known deprecation of XUL, both of which will result in 
large existing portions of m-c being made obsolete. Just as the Firefox 
hg repos will adapt to their changes, so the Thunderbird hg repos will 
adapt to changes.


:rkent

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Oct 23, 2015 at 11:13 PM, Eric Rescorla  wrote:

>
>
> On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc  wrote:
>
>> On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey  wrote:
>>
>> > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
>> > > I support going back to a giant monolithic repository if we can
>> cleanly
>> > > delineate the code for various projects.
>> > >
>> > > We know that the searchability and readability of our code is a major
>> > > barrier to some kinds of participation. We should continue to optimize
>> > > ourselves around that workflow.
>> > >
>> > > Does this proposal come with a plan to check out subsets of the code?
>> In
>> > > particular, I want to express the following as something inbetween
>> > "serious
>> > > concerns" and "requirements":
>> > >
>> > >  * The default view of dxr.mozilla.org should not include non-Firefox
>> > code
>> > >  * The default checkout should not include non-Firefox code. (Note:
>> > >this is about the working tree: I don't think the space in the .hg
>> > >directory matters enough to worry about).
>> > >
>> > > >- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>> > > >   number of users, behind Firefox, and before Firefox for Android
>> and
>> > > >   Firefox OS.  Many of those users may legitimately want to
>> contribute
>> > > >   to Thunderbird, and the bar to entry is made much higher by the
>> > > >   multi-repository setup and the extra complexity it entails.
>> Mozilla
>> > is
>> > > >   actively making the bar to entry for Firefox/Firefox for
>> > > >   Android/Firefox OS contributions lower, at the expense of
>> Thunderbird
>> > > >   contributors. This is a sad state of affairs.
>> > >
>> > > I'm sorry that it makes you sad, but Mozilla has explicitly decided to
>> > > prioritize the bar to entry for Firefox development, and the speed of
>> > > development of Firefox, at the expense of Thunderbird (and seamonkey).
>> >
>> > What's even more sad is that it's at the expense of Thunderbird (and
>> > SeaMonkey) *and* at the expense of Firefox build system changes.
>>
>>
>> I want to reiterate my original response and what Mike said in the
>> original
>> post.
>>
>> We'll be investing pretty heavily in the Firefox build system in 2016. I
>> cannot stress enough the pain comm-central's existence as a separate
>> repository gives us when trying to make build system, mach, and automation
>> changes. It slows us down and makes our lives (and code!) more painful
>> than
>> they could be.
>>
>
> Can you explain why this is? Is it that the Firefox build system does not
> build the artifacts you would need to then build TB or is it that you need
> to somehow figure out how to make TB build alongside Firefox?
>

comm-central's build system and tools are bolted on extensions to
mozilla-central's corresponding tools, which aren't really meant to be
extended in that way. mozilla-central's build system and tools like mach
have to make special considerations for running inside comm-central. The
relationships are hacky, not very well defined, don't have much visibility,
hard to debug, and are prone to breakage. The extra code complexity to
support running things from a separate repository (which means things like
teaching tools about the existence of multiple source directories) really
weighs us down. I've lost several days to "because comm-central" issues.

As a concrete example that's come up in the past few weeks, we can't easily
make wanted changes to jar.mn files or packaging of add-ons/XPIs because it
means developing, testing, and coordinating landing of changes across
mozilla-central and comm-central. It's much easier to let sub-optimal
patterns linger in mozilla-central because the overhead of developing a
parallel set of changes for comm-central is too high. I dare say the
knowledge of impending dread from having to deal with comm-central fallout
has discouraged me from making major build system and tooling changes. This
situation passively hurts everyone.


>
>> Continued existence of comm-central as a separate repository will slow
>> down
>> build system, tools, and automation progress. The developer productivity
>> survey results say that Mozilla staff overwhelmingly want these things to
>> be much better. A vote against this proposal is a vote against making the
>> jobs of "toolers" easier and a vote delaying the progress of improvements
>> to developer workflows, infrastructure, productivity, and happiness.
>>
>> As a "tooler" who wants to make your lives better, I emphatically support
>> merging comm-central into mozilla-central.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: Merging comm-central into mozilla-central

[R Kent James]

On 10/23/2015 2:22 PM, Bobby Holley wrote:

That may be a reason for the people working on the build system to refactor
it without consideration for Thunderbird. That may sound heartless, but it
is the current directive from the organization that is paying us to work on
m-c.

Whether or not Mozilla should change that directive is a separate
discussion. But as it stands, the only reason Thunderbird can possibly
stand in the way of changes to Firefox is if developers are bucking the
"ignore Thunderbird" directive to some degree.

bholley


You have very well expressed the fundamental tension that makes these 
discussions difficult: many MoCo staff are in the untenable position of 
feeling they need to not "be heartless", or write off Thunderbird's 25 
million users, by maintaining at least a minimum base level of support 
for Thunderbird. To do so they are 'bucking the "ignore Thunderbird" 
directive', or as BDS put it, "we don't *want* core contributors to 
spend time on comm-central".


On behalf of 25 million Thunderbird users (and Mozillians), I'd like to 
thank those of you who have bucked the directives.  I can assure you 
that those of us who are maintaining Thunderbird also feel the tension. 
What reasonable choice do we and you have? To just suddenly cut off 
access to Thunderbird to those people? We consider ourselves to be loyal 
supporters of the Mozilla brand by supporting Thunderbird, and I hope 
those of you in MoCo who occasionally need to support Thunderbird can 
understand that.


If you are one of the people proposing a heartless ignoring of 
everything Thunderbird, let's talk about ways that we can keep 
Thunderbird viable with the least effort on the part of your team. The 
last public word on Thunderbird from Mozilla is still that Mozilla is 
committed to stability for Thunderbird users. If Thunderbird needs to 
migrate away from some Mozilla service, let's talk about that.


Let's do whatever we reasonably can to reduce the contradiction imposed 
on certain MoCo staff, who feel they should keep Thunderbird viable and 
yet also can do nothing to support it.


:rkent
Chair, Thunderbird Project
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey  wrote:

> On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote:
> > I support going back to a giant monolithic repository if we can cleanly
> > delineate the code for various projects.
> >
> > We know that the searchability and readability of our code is a major
> > barrier to some kinds of participation. We should continue to optimize
> > ourselves around that workflow.
> >
> > Does this proposal come with a plan to check out subsets of the code? In
> > particular, I want to express the following as something inbetween
> "serious
> > concerns" and "requirements":
> >
> >  * The default view of dxr.mozilla.org should not include non-Firefox
> code
> >  * The default checkout should not include non-Firefox code. (Note:
> >this is about the working tree: I don't think the space in the .hg
> >directory matters enough to worry about).
> >
> > >- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
> > >   number of users, behind Firefox, and before Firefox for Android and
> > >   Firefox OS.  Many of those users may legitimately want to contribute
> > >   to Thunderbird, and the bar to entry is made much higher by the
> > >   multi-repository setup and the extra complexity it entails. Mozilla
> is
> > >   actively making the bar to entry for Firefox/Firefox for
> > >   Android/Firefox OS contributions lower, at the expense of Thunderbird
> > >   contributors. This is a sad state of affairs.
> >
> > I'm sorry that it makes you sad, but Mozilla has explicitly decided to
> > prioritize the bar to entry for Firefox development, and the speed of
> > development of Firefox, at the expense of Thunderbird (and seamonkey).
>
> What's even more sad is that it's at the expense of Thunderbird (and
> SeaMonkey) *and* at the expense of Firefox build system changes.


I want to reiterate my original response and what Mike said in the original
post.

We'll be investing pretty heavily in the Firefox build system in 2016. I
cannot stress enough the pain comm-central's existence as a separate
repository gives us when trying to make build system, mach, and automation
changes. It slows us down and makes our lives (and code!) more painful than
they could be.

Continued existence of comm-central as a separate repository will slow down
build system, tools, and automation progress. The developer productivity
survey results say that Mozilla staff overwhelmingly want these things to
be much better. A vote against this proposal is a vote against making the
jobs of "toolers" easier and a vote delaying the progress of improvements
to developer workflows, infrastructure, productivity, and happiness.

As a "tooler" who wants to make your lives better, I emphatically support
merging comm-central into mozilla-central.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Jonas Sicking]

On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc  wrote:
>
> We'll be investing pretty heavily in the Firefox build system in 2016. I
> cannot stress enough the pain comm-central's existence as a separate
> repository gives us when trying to make build system, mach, and automation
> changes. It slows us down and makes our lives (and code!) more painful than
> they could be.

Can this be solved without migrating c-c into m-c?

Would it be possible to create a thunderbird build system which simply
takes the output of a firefox build and grabs the files that it needs,
and builds the additions that thunderbird needs.

Generally speaking, libraries don't worry about having a build system
which enables building all downstream products. It's the
responsibility of downstream products to trigger the build system of
libraries.

The goal of putting seamonkey and thunderbird in separate trees has
always been to make firefox development easier, not harder. That
should include the build system.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Joshua Cranmer ]

On 10/23/2015 5:39 PM, Jonas Sicking wrote:

Can this be solved without migrating c-c into m-c?

Would it be possible to create a thunderbird build system which simply
takes the output of a firefox build and grabs the files that it needs,
and builds the additions that thunderbird needs.


Not without reversing major decisions made in the past 7 years. Back in 
2008, there was an idea of making a common platform runtime that Firefox 
and TB could easily both shared--you may know this runtime better as 
XULRunner, and its fate has been to die a miserable death. The split 
tree aspect was annoying but tolerable until about the time certain 
XPCOM changes required us to link all binary code into libxul (5 years 
ago?). The moz.build rewrites have required increasingly major 
contortions to keep working. Patches to make a mozilla-central work 
better in this platform-regard have been rejected in the past.

The goal of putting seamonkey and thunderbird in separate trees has
always been to make firefox development easier, not harder. That
should include the build system.


And the point of this thread is that it hasn't, and I can't emphasis 
this point enough. The current split is causing extreme pain on both 
sides of the divide, and I fear that the people who object to this have 
no conception of just how bad of a problem this has been. It's a case of 
grievously wounding those who make silent, heroic efforts against the 
theoretical pricks of someone who may not even exist.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Andrew Sutherland]

On Fri, Oct 23, 2015, at 01:02 PM, Joshua Cranmer  wrote:
> Actually, the b2g email app does reuse JSMime (or at least will be
> shortly).

Clarifying: Yes, library reuse is happening and it's good and awesome
and we want more of it.

But: b2g gaia email does not now and is unlikely to ever care about the
canonical source location of any of those libraries[1].

Andrew

1: b2g gaia email checks in its library dependencies from their
upstreams.  It of course would be great to have changes to JSMime (and
other mail libraries consumed by gaia mail) tested against gaia mail's
tests, but this would likely be accomplished by having taskcluster spin
up gaia mail with the candidate JSMime versions and run its tests
against that, not by having gaia mail build against trunk JSMime.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Nicholas Nethercote]

On Fri, Oct 23, 2015 at 6:57 PM, Mike Hommey  wrote:
>
> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
>   changes tend to break comm-central. While it can be argued that it
>   shouldn't be platform engineers' burden to care about those, the fact
>   is that even if they do care, the complexity of testing those changes
>   on try or locally doesn't even slightly encourage them to actually do
>   the work.

I've hit this one a lot, mostly when modernizing PLDHashTable. I
generally try to post a patch for comm-central shortly after landing
an API change on mozilla-central. It's annoying to have to remember
this and file a separate bug. I could just not bother, but that feels
rude and heartless and I don't like being rude and heartless.

There was also at least one occasion where I removed a function that
was unused in mozilla-central but still used in comm-central, and I
forgot to check comm-central before landing. In this case it was an
easy workaround, but if it hard been much harder then backing out the
patch would have been necessary.

So I'm in favour of merging them.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Gregory Szorc]

On Fri, Oct 23, 2015 at 8:57 AM, Mike Hommey  wrote:

> Hi,
>
> This has been discussed in the past, to no avail. I would like to reopen
> the discussion.
>
> Acknowledgment: this is heavily inspired from a list compiled by Joshua
> Cranmer, but please consider this *also* coming from me, with my build
> system peer hat on.
>
> What:
>
> Let's first summarize what this is about. This is about moving the
> development of Seamonkey, Thunderbird, and Lightning in the same
> repository as Firefox, by merging all their code and history from
> comm-central into mozilla-central.
>
> Seamonkey and Thunderbird share a lot, so comm-central without
> Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both
> standalone and an addon shipped with Thunderbird, so in practice, it
> can be considered as being part of Thunderbird.
>
> Why:
>
> - The interaction between the build system in mozilla-central and the
>   build system in comm-central is complex, and has been a never stopping
>   cause of all kinds of problems sometimes blocking changes in the
>   mozilla-central build system, sometimes making them unnecessarily more
>   complex.
>
> - The interaction between both build systems and automation is complex,
>   and got even more twisted with mozharness now being in
>   mozilla-central, because of the chicken-and-egg problem it introduces,
>   making integration with mozharness hard.
>
> - Likewise with taskcluster.
>
> - Subsequently, with mozilla-central now relying on mozharness and soon
>   switching away from buildbot, the differences in setup with
>   comm-central keep increasing, and makes maintaining those builds a
>   large hurdle.
>
> - Historically, the contents of comm-central used to be in the same
>   repository as everything else, and the build system has never really
>   copped with the separation. Arguably, this was in the CVS days.
>   It's a testament to our build and release engineers that the cobbled
>   together result has held up for as long as it has, but it's really
>   not sustainable anymore.
>
> - mozilla-central and comm-central are as tied as top-level
>   mozilla-central and js/ are. Imagine what development would look like
>   if js/ was in a separate repository.
>
> - Relatedly, many codebase-wise changes (e.g. refactorings), or core API
>   changes tend to break comm-central. While it can be argued that it
>   shouldn't be platform engineers' burden to care about those, the fact
>   is that even if they do care, the complexity of testing those changes
>   on try or locally doesn't even slightly encourage them to actually do
>   the work.
>
> - TTBOMK, Thunderbird is Mozilla's second largest project in terms of
>   number of users, behind Firefox, and before Firefox for Android and
>   Firefox OS.  Many of those users may legitimately want to contribute
>   to Thunderbird, and the bar to entry is made much higher by the
>   multi-repository setup and the extra complexity it entails. Mozilla is
>   actively making the bar to entry for Firefox/Firefox for
>   Android/Firefox OS contributions lower, at the expense of Thunderbird
>   contributors. This is a sad state of affairs.
>

+1 as someone who works on the build system, mach, and automation configs.
comm-central is a giant thorn in my side and prevents me from moving faster.


>
> Why not, and counter-counter-arguments:
>
> - It would increase mozilla-central significantly.
> Well, first, it's true, for some value of "significant".
> comm-central is about 131M of .hg/ data, while is about 2309M as of
> writing. That's a 5.7% increase in size of the repository. On the
> other hand, 131M is less than the size mozilla-central grew in the
> last 3 months.
>

On disk size isn't that important, as disk space is cheap. What is
concerning is wire transfer size because that makes it harder for people on
slow internet to clone. And, accordingly to https://hg.cdn.mozilla.net/,
comm-central is only 71MB over the wire. We've already increased
mozilla-central wire size by 150+ MB since ESR 38. Also, there are some
changes in Mercurial 3.6 that will allow us to reduce the wire size by >100
MB.

I don't think this extra size is worth worrying about.


>
> - It sets a bad precedent, other Gecko-based projects might want to
>   merge.
>   - mobile/ set the precedent half a decade ago.
>   - as mentioned above, historically, everything was in the same
> repository, and the split can be argued to be the oddity here
>   - there are barely any Gecko-based projects left that are not in
> comm-central.
>

I think the qualification for in-tree inclusion is what projects we run
automation for.


>
> - It adds burden to developers, needing to support those projects
>   merged from comm-central.
> Just look around in mozilla-central at all the optional things
> that are not visible on treeherder and break regularly. The
> situation wouldn't be different in that sense. But the people