Proposal: Move Thunderbird and SeaMonkey to mozilla-central

classic Classic list List threaded Threaded
143 messages Options
123456 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Joshua Cranmer 🐧
On 4/4/2014 12:32 AM, Mike Hommey wrote:

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

Interestingly enough, the --apparent-size for mozilla-central without
comm-central is 1165MB while the one for mozilla-central with
comm-central is 1249MB.

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Zack Weinberg-2
In reply to this post by Mark Banner-4
On 2014-04-03 9:07 AM, Benjamin Smedberg wrote:

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

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

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

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Justin Wood (Callek)-2
In reply to this post by Mark Banner-4
SUMMARY [based on my interpretation of responses in this thread]:

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

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

(Who):

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

If I got any of those wrong please tell me.

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

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

~Justin Wood (Callek)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

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

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

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

so would I for what little its worth ;)

Trev

>
> ~Justin Wood (Callek)
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Nicholas Alexander
In reply to this post by Justin Wood (Callek)-2
On 2014-04-07, 4:05 PM, Justin Wood (Callek) wrote:
> SUMMARY [based on my interpretation of responses in this thread]:
>
> As if this was a pure-vote based on responses:
>
> 11 - YES Merge c-c into m-c
> 5 - No Don't Merge It in
> 2 - Abstained (No Decision Specified)
>
> (Who):

<snip>

> nalexander: NO

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

Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Joshua Cranmer 🐧
In reply to this post by Justin Wood (Callek)-2
I'd like to see this resolved within the next 24 hours. To summarize the
current state of affairs, as I see it:

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

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

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

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

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

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


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

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Bobby Holley-2
On Mon, Apr 7, 2014 at 5:22 PM, Joshua Cranmer 🐧 <[hidden email]>wrote:

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

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

Why does this need to be rushed?


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

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

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

I think it's still too much considering the prioritization of TB/SM.
mozilla-central should not contain a significant amount of non-tier-11
code.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Matthew N.
In reply to this post by Joshua Cranmer 🐧
On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote:
> 1. Conflation of Firefox code with not-Firefox code.

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

MattN
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Philipp Kewisch-2
On 4/8/14, 9:34 AM, Matthew N. wrote:
> On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote:
>> 1. Conflation of Firefox code with not-Firefox code.
>
> I'd like tooling such as MXR to be updated to exclude whatever
> directories would be added from comm-central so I don't have to spend
> extra time ignoring them. Ideally they would be under one top-level
> directory to make this easy.

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

Philipp

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Joshua Cranmer 🐧
In reply to this post by Joshua Cranmer 🐧
On 4/7/2014 10:51 PM, Bobby Holley wrote:

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

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

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Zack Weinberg-2
In reply to this post by Matthew N.
On 2014-04-08 3:34 AM, Matthew N. wrote:
> On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote:
>> 1. Conflation of Firefox code with not-Firefox code.
>
> I'd like tooling such as MXR to be updated to exclude whatever
> directories would be added from comm-central so I don't have to spend
> extra time ignoring them. Ideally they would be under one top-level
> directory to make this easy.

I'd be fine with a "ignore code not part of Firefox" checkbox, but
getting comm-central code to show up on default MXR searches is
precisely why I *support* this proposal.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Bobby Holley-2
In reply to this post by Joshua Cranmer 🐧
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <[hidden email]>wrote:

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


I'm more or less talking about refactorings that would break comm/, and the
confusion over what is tier-1. I'm not adamant about it, but the concern
stands.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Gavin Sharp-3
In reply to this post by Joshua Cranmer 🐧
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <[hidden email]> wrote:
> You mean just like anyone hacking on source code would need to know that the
> rules are very different for nsprpub/, security/manager/, or any of the
> other semi-autonomous or imported libraries into mozilla-central?

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

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Joshua Cranmer 🐧
In reply to this post by Joshua Cranmer 🐧
On 4/8/2014 11:21 AM, Gavin Sharp wrote:
> On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <[hidden email]> wrote:
>> You mean just like anyone hacking on source code would need to know that the
>> rules are very different for nsprpub/, security/manager/, or any of the
>> other semi-autonomous or imported libraries into mozilla-central?
> Those are very different - they're not consumers of Gecko. If you're
> changing Gecko, you are not responsible for fixing Thunderbird or
> SeaMonkey consumers. Having the TB/SM code in mozilla-central implies
> that you do (or at the very least introduces confusion). That's a
> problem.

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Martin Thomson
On 2014-04-08, at 09:33, Joshua Cranmer 🐧 <[hidden email]> wrote:

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

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

This might not be a huge burden given the contribution others already make.  But it’s not free.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Gijs Kruitbosch ("Hannibal")
In reply to this post by Joshua Cranmer 🐧
On 08/04/2014 17:42, Martin Thomson wrote:
> On 2014-04-08, at 09:33, Joshua Cranmer 🐧 <[hidden email]> wrote:
>
>> I don't think it does. I suspect that most developers rely on the results returned by tbpl to indicate whether or not they have broken code. By not hosting TB and SM in the same tbpl views as Firefox builds, most developers would be unaware (and thus generally wouldn't care) if TB/SM were broken.
>
> Let’s be very clear in what you are asking here.  You are asking Firefox developers to contribute their time and efforts to maintaining Thunderbird and Spider Monkey.
>
> This might not be a huge burden given the contribution others already make.  But it’s not free.

Err, no. For one, it's SeaMonkey, not spidermonkey. I realize we have a
lot of monkeys, but it's an important distinction. :-)

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

~ Gijs
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

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

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Gavin Sharp-3
In reply to this post by Joshua Cranmer 🐧
On Tue, Apr 8, 2014 at 9:33 AM, Joshua Cranmer 🐧 <[hidden email]> wrote:
> I don't think it does. I suspect that most developers rely on the results
> returned by tbpl to indicate whether or not they have broken code.

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

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Johnny Stenback-3
In reply to this post by Joshua Cranmer 🐧
If you want an answer to whether or not we will to this in the next 24
hours then the answer is absolutely no.

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

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

On 04/07/2014 05:22 PM, Joshua Cranmer 🐧 wrote:

> I'd like to see this resolved within the next 24 hours. To summarize the
> current state of affairs, as I see it:
>
> The only substantive objections raised to this merge were the three
> points mentioned by bsmedberg, to which all other dissenters (both in
> this newsgroup and on IRC) have essentially concurred. These three are:
> 1. Conflation of Firefox code with not-Firefox code.
> 2. Repository size
> 3. Unnecessary.
>
> My responses to these three points boil down to the following:
> 1. Not a big issue, but alternative 2 should solve any issues here.
> 2. The additional heft added to mozilla-central would not be large in
> the context of normal mozilla-central development.
> 3. bsmedberg posed an alternative that I concede would solve the build
> issue, but that would cause maintenance and support experiences to worsen.
>
> There was another point brought up (I hesitate to call it an objection)
> that asked what this merge would mean for precedent. My response is that
> a) precedent is effectively set by the old mobile-browser repository and
> b) comm-central is not a precedent which non-Mozilla-developed
> applications can expect to follow.
>
> Effectively, I propose two alternatives in the merge:
> Alternative 1: Merge comm-central into mozilla-central as a flat merge
> (as proposed in the top of the thread)
> Alternative 2: Merge comm-central into a subdirectory of mozilla-central
> named 'comm/'
>
> I prefer the first alternative, mostly because it involves less work to
> do a flat merge and preparatory work commenced under the assumption that
> it would happen like so, but I would be more than willing to do the work
> to merge under alternative 2 instead.
>
> I'm CC'ing Brendan Eich and Bsmedberg explicitly because those are the
> people to whom I'm mostly directing the question of finally resolving
> this proposal.
>
>
> On 4/7/2014 6:05 PM, Justin Wood (Callek) wrote:
>> SUMMARY [based on my interpretation of responses in this thread]:
>>
>> As if this was a pure-vote based on responses:
>>
>> 11 - YES Merge c-c into m-c
>> 5 - No Don't Merge It in
>> 2 - Abstained (No Decision Specified)
>
> There was some discussion in IRC about this, and there were some people
> who indicated support/opposition there without responding to the mailing
> list.
>

--
jst
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central

Joshua Cranmer 🐧
In reply to this post by Joshua Cranmer 🐧
On 4/8/2014 1:41 PM, Johnny Stenback wrote:
> It seems very clear to me that this will increase the amount of time
> engineers who work on tier-1 products end up having to spend on
> non-tier-1 projects, meaning it would decrease the amount of time they
> spend on tier-1 projects. Therefore I do not support this change.

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

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123456 ... 8