Proposal: Move Thunderbird and SeaMonkey to mozilla-central

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

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

Joshua Cranmer 🐧
On 4/8/2014 12:43 PM, Gavin Sharp wrote:
> 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.
In my experience of comm-central development, most changes to APIs that
would break comm-central are either mechanical transitions or API
changes for which the comm-central uses are important and end up
blocking the API change in mozilla-central. It's not clear to me that
the overhead that would be introduced would be distinctly measurable.

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

Benjamin Smedberg
In reply to this post by Justin Wood (Callek)-2
On 4/7/2014 7:05 PM, Justin Wood (Callek) wrote:
>
>
> So to further along, whom of this list gets to make the decision, if
> no-one whom do we escalate to for an explicit yes/no?
>

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

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

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

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

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

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

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

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

This is human nature.

This leads me to some basic conclusions:

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

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

--BDS

_______________________________________________
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 Justin Wood (Callek)-2
On 4/8/2014 3:24 PM, Benjamin Smedberg wrote:
>
> * The organization of our source code should reflect our project
> priorities.

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

We have xulrunner in m-c.

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

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

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

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

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

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

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

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

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

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

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

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

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

~Justin Wood (Callek)
_______________________________________________
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 Justin Wood (Callek)-2
On 08/04/2014 20:24, Benjamin Smedberg wrote:
> The tradeoff here is a little complex, but I'm going to articulate some
> base axioms:
>
> * Firefox, Firefox for Android, and B2G are the first priorities of the
> Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.
> * The organization of our source code should reflect our project
> priorities.

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

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

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

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

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

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

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

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

~ Gijs
_______________________________________________
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
On 4/8/2014 2:24 PM, Benjamin Smedberg wrote:

> The tradeoff here is a little complex, but I'm going to articulate
> some base axioms:
>
> * Firefox, Firefox for Android, and B2G are the first priorities of
> the Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.
> * The organization of our source code should reflect our project
> priorities.
>

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

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

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

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

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

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

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

Blake Winton
In reply to this post by Gijs Kruitbosch ("Hannibal")
On 2014-04-08, 18:13, Gijs Kruitbosch wrote:

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

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

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

Later,
Blake.

_______________________________________________
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
On 4/8/2014 11:27 PM, Blake Winton wrote:

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

For what its worth I am from Releng, but I also double as a SeaMonkey
Council member, so bear that in mind.

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

I won't repeat that in this post though.

~Justin Wood (Callek)
_______________________________________________
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 Gijs Kruitbosch ("Hannibal")
On Tue, Apr 8, 2014 at 3:13 PM, Gijs Kruitbosch
<[hidden email]> wrote:
> Which is why I believe this assumption doesn't hold. What's more, as a
> Firefox desktop frontend developer, I actually think I would be *more*
> productive if there were concrete non-Firefox-toolkit-using code in m-c, not
> only because of atomic patches for toolkit + some consumers, but also
> because of concrete examples of how toolkit stuff gets used elsewhere.

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

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

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

Gavin
_______________________________________________
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

Doug Turner-4
In reply to this post by Mark Banner-4
I would rather see /browser and /mobile removed from mozilla-central
making this repo exclusive to 'gecko development'.  So, I disagree
with your proposal and would not support this move.

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

Lastly and somewhat related - people use code search to figure out how
to do something.  I would hate for them to find bits of
old/incorrect/crufty SeaMonkey code (which has a LOC / Contributing
Engineer ratio approaching INF).  I am not sure if Thunderbird is
similar but I suspect so.
_______________________________________________
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 Mark Banner-4
On 4/8/2014 11:47 PM, Doug Turner wrote:
> I would rather see /browser and /mobile removed from mozilla-central
> making this repo exclusive to 'gecko development'.  So, I disagree
> with your proposal and would not support this move.

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

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

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

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

Mike Hommey
In reply to this post by Blake Winton
On Tue, Apr 08, 2014 at 11:27:16PM -0400, Blake Winton wrote:

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

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

Mike

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

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

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

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

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

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

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

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

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


Chiaki Ishikawa
_______________________________________________
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

ISHIKAWA,chiaki
In reply to this post by Joshua Cranmer 🐧
On (2014年04月09日 14:04), Joshua Cranmer 🐧 wrote:
> since it eliminates the ability to bisect on mozilla-central-induced
> failures.

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

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

TIA


_______________________________________________
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 Gijs Kruitbosch ("Hannibal")
On 09/04/2014 05:37, Gavin Sharp wrote:

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

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

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

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

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

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

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

~ Gijs
_______________________________________________
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

Ben Hearsum-2
In reply to this post by Blake Winton
On 04/08/14 11:27 PM, Blake Winton wrote:

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

I'm part of MoCo RelEng. Here's my thoughts from that perspective,
though I don't really have a strong preference either way:

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

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

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

- Ben
_______________________________________________
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

Chris AtLee-3
On 09:12, Wed, 09 Apr, Ben Hearsum wrote:

>I'm part of MoCo RelEng. Here's my thoughts from that perspective,
>though I don't really have a strong preference either way:
>
>There's no doubt that Thunderbird automation is in worse shape than
>Firefox automation - both of which are maintained by MoCo RelEng.
>
>I haven't been involved as deeply in it, but I know that B2G's
>repositories have caused some challenges for multiple reasons:
>externally hosted, git (instead of hg), as well as being split across
>many many (60+) repositories. I don't have a good sense for how painful
>the multiple repositories have been vs. the other parts.
One approach that we've used to manage this complexity is to include
references to the various B2G repos inside m-c. In a way we're managing
our own submodules via external tooling. E.g. b2g/config/gaia.json
refers to the repository and revision of gaia to use, and we also have
fully specified XML manifests for all of the B2G devices in tree, e.g.
https://hg.mozilla.org/mozilla-central/file/7160658c4be3/b2g/config/emulator/sources.xml

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

Cheers,
Chris

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

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

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

Gervase Markham
In reply to this post by Justin Wood (Callek)-2
On 08/04/14 20:24, Benjamin Smedberg wrote:
> * Firefox, Firefox for Android, and B2G are the first priorities of the
> Mozilla project.
> * We have a secondary commitment to provide security and maintenance
> updates to Thunderbird.

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

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

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

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

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

Gerv

_______________________________________________
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

Gregory Szorc-3
In reply to this post by Ben Hearsum-2
On 4/4/14, 4:35 AM, Ben Hearsum wrote:

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

What do people need to do?

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

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

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

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

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

The cited problems seem to be minor from my perspective. They don't seem
to overrule the importance of optimizing the Firefox development
workflow, where 1% changes in developer productivity multiplied by
hundreds of salaried developers amounts to millions of dollars and
faster development times.
_______________________________________________
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 Philipp Kewisch-2
On 4/8/14, 1:56 AM, Philipp Kewisch wrote:

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

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

MattN
_______________________________________________
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

Philip Chee
In reply to this post by Mark Banner-4
On 09/04/2014 12:47, Doug Turner wrote:

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

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

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
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-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345678