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

New BMO SSL certificate coming 2015/10/29

[Mark Côté]

BMO's SSL certificate expires on 2015/10/30, so please be advised we
will be installing a new one around 13:30 UTC on 2015/10/29 (9:30 am
EDT/6:30 am PDT).

The new fingerprint will be

7c:7a:c4:6c:91:3b:6b:89:cf:f2:8c:13:b8:02:c4:25:bd:1e:25:17

`mach hgsetup` will be patched as soon as the new cert is installed
(https://bugzilla.mozilla.org/show_bug.cgi?id=1218903).

If you are thinking "hey didn't BMO's fingerprint just recently change",
then yes, you are correct.  We recently upgraded the cert from SHA-1 to
SHA-2, which we did by reissuing the same certificate, hence a new
fingerprint but the same expiry date.

Mark
___
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