|Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mark Banner||4/3/14 3:13 AM|
[follow-ups to mozilla.dev.planning]
tl;dr We're proposing to move Thunderbird and SeaMonkey into
mozilla-central to reduce maintenance complexities for build systems,
and for releng. Multiple-app handling in the same repository has
improved greatly, and the general rules would remain the same.
Feedback and discussion is most welcome - we have generally discussed
this within some individuals, but not widely.
We'd like to move Thunderbird and SeaMonkey (i.e. most of the contents
of comm-central) into mozilla-central.
We're looking to complete this in the Gecko 31 cycle, as then we'd be
able to pick it up in the next ESR cycle.
We already have this in preview mode running on the Alder twig.
There are several primary pain points that make things more complicated
for Thunderbird development, and its support for releases from releng.
The overarching reason is that this merge would reduce the amount of
work required to keep Thunderbird building to support security releases
and community development, and allow more focus on other areas.
They reasons we'd like to do this are:
- Requiring that comm-central pulls mozilla-central duplicates the build
system in weird and wonderful ways.
Maintaining the duplicate build system obviously duplicates much of the
work that is already being done in mozilla-central.
- Additionally, it would simplify pieces of m-c build config logic which
are accommodating c-c.
- Due to pulling different repositories, the workarounds for releng are
complex. It requires an almost totally-separate project configuration,
and when build configurations change, these must be manually ported to
the Thunderbird project configuration.
With a similar configuration to Firefox, we could base on the same
configuration with only a few changes to project name, and specific
- Additionally, some benefits from search&replace patches are lost as
the code is in a separate repository.
The merge will include the full c-c history.
We'd obviously keep the same rules - changes that break
Thunderbird/SeaMonkey are not required to be fixed by the Gecko change
that breaks them.
We may relax some of the existing comm-central rules, e.g. Gecko build
system review could apply to the Thunderbird parts for search & replace
patches, rather than requesting separate reviews. Obviously, we'd
confirm with the appropriate areas before this happens.
Now that bug 787449  is fixed, we can easily exclude
Thunderbird/SeaMonkey pushes from triggering gecko builds.
We envision that the existing Thunderbird-Trunk would be kept separate
to the Mozilla-Central one, however, we could consider merging these at
a later date if it makes sense.
The additional directories would currently be approximately:
mozilla-central/ldap (also statically importing the ldap c-sdk).
However, we would be willing to restructure/group those if they are too
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ed Morley||4/3/14 3:36 AM|
On 3 April 2014 11:13:00 BST, Mark Banner <mba...@mozilla.com> wrote:What increase will this mean for the size of the gzipped mozilla-central hg bundle and time for a fresh hg pull of mozilla-central? Will you be using hg convert with a filemap (vs hg remove) to avoid adding the history of other parts of c-c to mozilla-central's hg store? (Just thinking of new contributors who have limited bandwidth)
That said, think it will make it a lot easier for tree-wide changes to not break Thunderbird/SeaMonkey, so I see there are potential wins here :-)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Benjamin Smedberg||4/3/14 6:07 AM|
On 4/3/2014 6:13 AM, Mark Banner wrote:I oppose this plan.
I think it's fine to reconsider the decision we made in 2008 not to
include tbird/seamonkey in mozilla-central, but I don't think the
arguments here are compelling or that the benefits are worth the costs.
Reason #1: confusion about what code belongs to what projects
Currently when hacking on Firefox, it's roughly clear that all the code
in mozilla-central belongs to Firefox in some way, and we have been
effectively removing most of the code that isn't part of Firefox. When
searching through the codebase (either locally or using the online dools
like DXR/MXR) the addition of code which belongs to different products
will significantly harm developer understanding.
Reason #2: Pull/tree size
There is a non-trivial amount of code involved in this change. In terms
of both downloading the source repo as well as the size of a local
checkout, I don't think we should include unnecessary code in the
Reason #3: It's unnecessary
It is not necessary to alter mozilla-central to put all of Thunderbird
in one repository. You can do the merge you are proposing, but keep it
as a separate Thunderbird tree and regularly merge changes from
mozilla-central into your combined tree.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Henri Sivonen||4/3/14 6:28 AM|
On Thu, Apr 3, 2014 at 4:07 PM, Benjamin Smedberg <benj...@smedbergs.us> wrote:I agree that the confusion about what code belongs to Firefox is a
problem and merging c-c into m-c *could* make the confusion worse.
1) the current situation is worse than what you wrote suggests. Way
too often, I encounter pre-Firefox-era legacy cruft in m-c that
appears to be dead code but turns out to be in use by c-c.
2) the confusion could be addressed by requiring
Thunderbird/SeaMonkey-only code to live in a certain directory (or a
small set of directiories).
3) due to issue #1, searches for code deadness need to be done on c-c
(On that topic: I'm still looking for a volunteer for
https://bugzilla.mozilla.org/show_bug.cgi?id=937056 . At some point I
will have whined about this so much that it would have been more
efficient to just do the move myself even though I'm not supposed to
use time for Thunderbird development...)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Bobby Holley||4/3/14 6:28 AM|
On Thu, Apr 3, 2014 at 10:07 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
I strongly second benjamin's points.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 6:41 AM|
On 4/3/2014 5:36 AM, Ed Morley wrote:A full hg bundle of mozilla-central is 637MB. That of the new repository
would be 692MB. In general, comm-central is roughly 10% the size of
mozilla-central at present in terms of both history and file contents. I
believe this extra size would be roughly equivalent to the size of
mozilla-central a year from now if comm-central were not merged, but my
repository growth curves are hazy.
Thunderbird and DXR developer
Source code archæologist
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 7:01 AM|
On 4/3/2014 8:07 AM, Benjamin Smedberg wrote:It's not technically challenging to move all of the newly-added code to
a comm/ subdirectory instead of doing a flat import. That would
centralize most of the obviously-not-in-Firefox code into one directory.
That said, to reiterate Henri's point, there is a surprising amount of
code in mozilla-central that doesn't end up being used in Firefox.
Having filed several bugs for mozilla-central test failures found only
in comm-central, there are definitely cases where the failure is "oh, we
don't use <insert toolkit component here> in Firefox" (a recent example
is the toolkit's downloader). There are also cases where there is
dynamically-dead code in Firefox that is not dynamically dead in
Thunderbird: I think for a time, Thunderbird was the only one using
certain legacy HTML parser APIs.
>As I mentioned earlier, the size is roughly 50-60MB of extra data in the
bundle. The on-disk is 67MB not including the .hg directory and ~200MB
including the .hg directory. All of these numbers are about 10% or less
of the current mozilla-central size (637MB, 922MB, 2.5GB, respectively).
The tree with comm-central included would be roughly the same size as
the tree without comm-central a year from now, based on my prior
recollections of repository growth curves.
>That works much less well than you'd expect. In such a repository, it is
impossible to merge changes from comm-central back into mozilla-central
without introducing c-c's history or rather complicated changeset
manipulation. It also produces a comm-central repository that has the
illusion of atomic changesets: there is no way to make a commit that
does an across-both-trees change such as the atomic refcounting changes
or gps's DIRS introduction.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||clo...@gmail.com||4/3/14 7:31 AM|
On Thursday, April 3, 2014 6:13:00 AM UTC-4, Mark Banner wrote:This sounds great!
This will make it significantly easier to get new Thunderbird contributors set up and hopefully reduce some of the build bustages TB currently suffers. (And also save me a few GB on my hard drive...which is a nice plus.)
Can't wait to put up patches that touch both toolkit and TB things without having to do separate patches and ensuring they land in the right order!
Thanks for working on this Joshua and Mark!
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mark Banner||4/3/14 8:15 AM|
On 03/04/2014 14:07, Benjamin Smedberg wrote:I probably wasn't explicit, but I think the main benefits of this
proposal are going to be to the Thunderbird/SeaMonkey communities. I can
understand that this isn't so compelling to Firefox developers. So let
me explain a bit more:
Ever since we separated the repositories, we have spent significant
amounts of time porting build configuration patches, fire-fighting
bustage when something lands in m-c and needs porting to c-c (including
sometimes regression range finding & bisecting). Obviously fire-fighting
is a larger pain as it distracts us from whatever we were working on.
Although with recent improvements we've now vastly reduced build
configuration porting time, the fire-fighting aspects still take up
large amounts of time which we could spend elsewhere - especially if we
were able to take benefits of search & replace/repository-wide updates
(where developers are willing to include us because we're in the same
repo rather than a separate one). It wouldn't reduce everything, but it
would likely mean we could be down to a bustage every now and again.
I don't see this being a big issue. We've dealt with this for
comm-central ever since 2008, and its easy to see where code lies in
suite/ mail/ or mozilla/browser and realise it is specific to that product.
If we need to put everything under comm/ as Joshua suggests (or some
other directory), that would be fine by me. Generally it feels like the
significant cost here would be first-time users, who we could educate by
means of adequate documentation.
One thing I think this does mean is increased storage size for hmo. We'd
effectively be doubling up the m-* repositories. With IT/releng
currently concerned about the size, that probably isn't good. There may
be resolution on the way, so this might become mute.
It also doubles the repository sizes for developers who do want to work
on FF and/or TB/SM. There may not be many of them, but there are a few -
admittedly I don't know for how many disk/download size is an issue.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Nick Alexander||4/3/14 8:20 AM|
On 2014-04-03, 6:07 AM, Benjamin Smedberg wrote:
> I think it's fine to reconsider the decision we made in 2008 not to
> Reason #1: confusion about what code belongs to what projects> Reason #2: Pull/tree size
>I'd like to add that there exist other apps built on top of Gecko, and
in future there will be more, and that merging every such app into m-c
is not feasible.
I recognize that Thunderbird and SeaMonkey are special, for technical
and historical reasons, but this sets a bad precedent.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ben Hearsum||4/3/14 8:22 AM|
On 04/03/14 11:15 AM, Mark Banner wrote:Perhaps we should move Firefox/B2G/Android to another repo instead, then
we'd all be living in the same world.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 8:53 AM|
On 4/3/2014 10:20 AM, Nick Alexander wrote:I don't think this sets a precedent. If anything, the precedent was set
on April 6, 2011 when the Fennec repository was merged with
mozilla-central. As I recall, the main argument for merging those two
repositories together amounted to a complaint that having the source
code for a product be in two different repositories was too difficult to
maintain. Comm-central is closer in scope to the former mobile-browser
repository than other, external projects in that Mozilla has maintained
comm-central itself and continuing support for comm-central has been a
goal for several classes of mozilla-central developers, particularly for
the build system, although other parts of the codebase have been
influenced by comm-central needs (legacy HTML parser APIs and charset
support comes to mind).
The factors that have compelled us to propose this merge are not
generally applicable to most products that use Gecko.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Nick Alexander||4/3/14 9:21 AM|
On 2014-04-03, 8:53 AM, Joshua Cranmer 🐧 wrote:I didn't know that Fennec was once separate, so thanks for the history
Agreed. Part of my motivation for not tying a product (Fennec,
Thunderbird, SeaMonkey) directly to m-c is that the Fennec team is now
trying to extract a core library for other consumers to embed Fennec.
If Fennec had been maintained as a separate repository, that would have
happened naturally. (At a huge cost in development time and pain. I'm
not saying the decision was incorrect; I didn't even know about it until
Can you elaborate on this point? I'd like to understand this difference
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Dolske||4/3/14 10:01 AM|
On 4/3/14 3:13 AM, Mark Banner wrote:Well, let me stir the pot _and_ ask about the elephant in the room -- if
SeaMonkey and Thunderbird are a burden on releng, why is Mozilla
continuing to support them? Other community forks of Firefox (Tor
Browser, PaleMoon, WaterFox, etc) successfully exist entirely
independently of Mozilla. SM and TB have both had a long time to succeed
on their own terms as community projects, and it's not clear to me that
either are significantly contributing to Mozilla's mission.
Even Mozilla's core products (Firefox for desktop and Android) are in
resource contention with Firefox OS, so I think it's a fair question to
consider these days.
FWIW, I'd also note that Firefox OS is spread across multiple repos. Or
is there a proposal to merge FFOS into m-c as well?
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mark Banner||4/3/14 10:14 AM|
On 03/04/2014 18:01, Justin Dolske wrote:So to clarify, SeaMonkey is not any burden on releng. They have their
own systems maintained by their own members (although as a side note,
they have trouble keeping up with releng).
When Mozilla stopped actively developing Thunderbird, it was agreed with
the community that Mozilla Corp would put in resources to maintain
security and stability releases.
IMO the burden has been a small fraction of the work that releng does,
though I can't give you any figures. I know there is some additional
complexity in the releng systems that have to cope with the special
cases of split repos for c-c.
I don't know much about how FFOS is built, but I believe it is
significantly different - it has the core libraries, aka gecko, plus a
lot of applications around the outside. That's effectively two build
processes - one for the core gecko build, one for the applications. IMO
that's easier to deal with in a multiple repo setup.
For Thunderbird, we are building gecko directly into the app - just like
Firefox - so this is one build step rather than two.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Kyle Huey||4/3/14 10:23 AM|
> dev-planning mailing list
The difference is that desktop/Android/B2G are products that are
important enough to our priorities to invest anywhere from dozens to
hundreds of full time engineering staff in. Thunderbird and Seamonkey
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philipp Kewisch||4/3/14 1:49 PM|
On 4/3/14, 3:07 PM, Benjamin Smedberg wrote:I really think this is not always clear, or lets say its much too easy
to forget. While Firefox/Android/B2G is in the focus, its easy to forget
that the Mozilla Platform should be independent of the concept of a
browser. If you search for things like gBrowser, selectedTab, or
chrome://browser in directories like toolkit/ there are always a small
number of hits outside of tests.
Now importing c-c into m-c won't fix this, but it does make an argument
for separating Firefox/Android/B2G from the Mozilla Platform. For the
same reasons its troublesome for Thunderbird to be separate from m-c, I
don't think it would be smart for Firefox to be separate of it.
On the other hand, importing c-c into m-c helps to make
Firefox/Android/B2G developers more aware of this separation: doing an
mxr search for something in toolkit that is also used in Thunderbird
will passively let the developer know, that the component he is changing
is not only used in a browser environment and should be modified in a
way that is compatible to other consumers of the Mozilla Platform.
For mxr searches it would be nice if they could be ordered in a
different way though: browser products - comm products - platform
directories. I don't see a sensible way of doing this though. We could
give the comm/ folder a name that starts with a later letter of the
alphabet, but thats a bit fickle.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philipp Kewisch||4/3/14 2:07 PM|
On 4/3/14, 7:01 PM, Justin Dolske wrote:IIRC then Firefox OS is split into quite a few repositories, containing
various aspects from apps to user space libraries and kernels. Pulling
everyting for a Geeksphone Peak device was well over 12GB, with about
18GB of compiled data.
Indeed, not all of this should be dumped into m-c, but if the
multi-repository model works for B2G, wouldn't it be consequent to do
the same for Firefox and Android? If I just want to hack on B2G, why do
I need all of Firefox Desktop?
It looks to me that the multi-repository system that B2G uses does not
make it trivial to create nightly builds for different devices from a
releng standpoint, on the other hand this might just be a partnering issue.
What I am saying, if the multi-repository system works out great for
B2G, then maybe this concept should be extended so it works the same for
Firefox Desktop and for that matter also Thunderbird. On the other hand,
the downsides mentioned in other messages still apply and would then
also apply to Firefox Desktop.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/3/14 2:09 PM|
On 4/3/2014 1:01 PM, Justin Dolske wrote:So let me address this,
SeaMonkey is not a burden on Mozilla Releng. It is a burden on SeaMonkey
Thunderbird has been agreed to be a supported (building/machines/etc.)
thing when its day-to-day devs were disconnected from it as a Mozilla
Product. That said it is a burden in terms of priority bumping for
I personally am an Employee of Mozilla in the Releng Role, and care
heavily about this issue as I am the Lead SeaMonkey Releng human as well
(my work on SeaMonkey is purely my volunteer time).
To drive the point home, I've also devoted some pain/time into fixing
some Releng Bugs for Thunderbird as part of my volunteer time, to make
sure that Thunderbird could stay viable for us.
Prior to my work/role in Releng I was also an active/avid comm-central
build system peer, and that was before there was drastic changes in the
mozilla-central build system that were incompatible with what came before.
Let me state, for the record, that keeping up with changes even PRIOR to
the current cadence is VERY hard. this work in merging the two repos
will allow m-c build system changes to emmediately take affect in
comm-apps without need to port anything, and will keep timings intact.
The releng-specific burden/work that this would have prevented lots of
human hours on, for example includes things like a few months ago, a
releng manager, myself, and a few others (including mark) had to debug
buildbot+thunderbird+comm-central+build-system interactions that
completely broke l10n builds, iirc TB beta is still broken, but we had
to do the work back then to also support ESR. The work took more than a
week and was multiple humans interacting on paid time.
Simply having TB as part of m-c would have simplified a lot of our
releng logic around TB builds and made much of the work a non-issue, and
for the little bit that touched c-c makefiles, would have made them more
likely to be noticed when the m-c Makefiles had to change. There is also
occassionally weird bustage due to m-c build system changes when
$topsrcdir != $mozillasrcdir (specifically because m-c is in
I as both community and MoCo releng are FULLY in support of this move,
albeit I gave light to my biases above.
~Justin Wood (Callek)
p.s. If you're curious in truth on why I feel these two products, even
in current form, bolster Mozilla's Mission, feel free to reach out, I'm
happy to skype/vidyo with anyone on that subject.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Benjamin Smedberg||4/3/14 2:34 PM|
On 4/3/2014 4:49 PM, Philipp Kewisch wrote:As a project we're spread thin, and having "a platform" separate from
actual projects is mainly a dream that distracts us from what's
important. The thing that gives our platform its importance is the
products that use it, and we need to redouble our focus.
It is true that for technical reasons we try to keep a separation
between our platform code and the user-facing code on top of it: but
that is necessary for sane engineering, not because we have theoretical
platform purity to uphold.
So overall I disagree with you: the Mozilla platform should not be
thought of separately from the products based on it.
This highlights the core decision we need to make. Should developers be
more or less aware of comm-central when developing out platform.
Our clear priority as a project is not comm-central, and so I don't
think we should be including this code.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Benjamin Smedberg||4/3/14 2:39 PM|
On 4/3/2014 10:01 AM, Joshua Cranmer 🐧 wrote:We should remove that code from mozilla-central/libxul. Our technical
debt is substantial and one of the easiest ways to reduce it is by
removing unneeded code.
It is possible with mercurial queues to easily split patches up across
multiple trees. You can also make atomic commits to comm-central by
making the mozilla-central change and avoid merging that until you've
committed the equivalent comm-central changes.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Neil||4/3/14 3:15 PM|
Henri Sivonen wrote:Wouldn't this be an example of something that would be much easier to
achieve with a unfied repo?
Warning: May contain traces of nuts.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gregory Szorc||4/3/14 3:19 PM|
Fragmenting repositories is not the answer and only creates more problems.
Unified repositories are a good thing:
1. You have a single commit identifier that identifies the state of the
2. You can make large changes across multiple projects atomically
3. The tooling doesn't suck (all solutions for subrepos or multi
repository management are significantly worse than single repo experiment).
Many companies that have encountered this problem have made the
determination that having all code live in one repository and thus
available to everyone all the time is a far greater benefit than to have
people constantly agonizing with the downsides of fragmented repositories.
These companies like the benefits so much that they use scalable version
control systems (like Perforce and Mercurial) that can handle tens or
hundreds of thousands of files and gigabytes of data. (Git doesn't scale
well into this territory. Search "Facebook Git scaling" on Google if you
doubt me - you shouldn't doubt Facebook's engineering team.)
While I concede that Mozilla's needs are slightly different from that of
a large corporation with a repository behind a firewall, the benefits of
unified repositories remain. The drawbacks (large clone times) can
largely be mitigated through extensions (with Mercurial at least).
To use a Mozilla example to support claim #2, I'll use mozbase. mozbase
is a suite of Python packages. It's effectively the "Mozilla standard
library." It used to live in GitHub and was merged to mozilla-central
periodically. People working on Python in the tree would often need or
want to make changes to mozbase. They had to commit to Git, wait for a
merge to m-c, then commit whatever changes were depending on it. The
process was brutally agonizing. Often days would go by between mozbase
merges. Stop energy was everywhere. Now, mozbase lives inside
mozilla-central. In one atomic commit I can update mozbase *and* change
all in-tree consumers in one go. It's faster for everybody and makes
everyone more productive. It keeps Mozilla fast and nimble.
If we split Firefox, Android, etc into separate repositories, I think it
would add way too much overhead and pitfalls for everyone involved and
we'd all be screaming to go back to the old world.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gregory Szorc||4/3/14 3:27 PM|
On 4/3/14, 6:07 AM, Benjamin Smedberg wrote:
> Reason #1: confusion about what code belongs to what projects
> Reason #2: Pull/tree sizeI believe this reason should be ignored on the basis that it's a
solvable and inevitable problem.
If Mozilla deployed the remotefilelog Mercurial extension on
hg.mozilla.org, people could clone mozilla-central *without* having to
pull the full repository data. A fresh clone of mozilla-central would be
several hundred MB of wire transfer less than today.
We could also write a Mercurial extension that distributed a shallow
bundle. We could probably also write an extension that did partial
bundles, pulls, and checkouts.
These are all solvable problems (with Mercurial at least - Git isn't as
flexible). They just require someone to implement. If we wait long
enough, Facebook may be our savior (they wrote remotefilelog). But they
don't care too much about Windows and non-SSH access. Furthermore, there
aren't that many entities scaling version control to the limits we are.
I fear that fixing these problems will need to come out of Mozilla's
budget sooner or later.
The tree size argument also ignores the harsh reality that the tree will
continue to grow over time. We'll be hitting scaling pains with or
without comm-central. By some accounts, we're already there.
Merging mozilla-central into comm-central periodically does seem
somewhat reasonable to me. That would get rid of most of the special
attention needs that comm-central has inflicted upon mozilla-central's
build system. (I would love to excise those.) But the "atomic commit"
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Dolske||4/3/14 3:59 PM|
On 4/3/14 3:15 PM, Neil wrote:Not clear to me, but I'd say it definitely is an example of the costs
carried by our core-focus products due to the quasi-supported state of
SM+TB. To stir the pot again, the simplest thing to do here would be to
remove the code, and let SM+TB be responsible for adding it back to a
place if they need to keep using it. Yes, I know that sucks for SM/TB
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 4:13 PM|
On 4/3/2014 4:39 PM, Benjamin Smedberg wrote:My point is that the current situation of separate repositories ends up
being a poor guide already to the true Firefox/Fennec/B2G versus
not-those code repositories, and no one has (to my knowledge) complained
that this is the problem. Moving comm-central into mozilla-central is
not in any way, shape, or form changing the rules that commits to
mozilla-central are not required to keep Thunderbird et al functioning;
therefore, it does not affect technical debt at all. Indeed, if
anything, the solution as proposed may help reduce technical debt by
letting people afraid to remove APIs that have use in Thunderbird remove
them more easily (one person has already suggested he might do this over
>That sounds like the words of someone who has never had to deal with
developing a repository in this kind of situation. A normal comm-central
developer would generally be using the comm-central side of the merge
and would need to remember to update to the mozilla-central side before
pushing. It takes just one person being forgetful to end up with the
comm-central side pushed to mozilla-central. It's a recipe for disaster
in other ways too: patches that affect both non-c-c and c-c code would
still apply equally, and you're relying on all the contributors
remembering to split them up.
It also makes the maintenance burden much more complicated: it would no
longer be possible to bisect the mozilla-central changes to find the
causes of bugs that break Thunderbird code. (Note that such bugs can
also be broken Firefox code that are masqueraded by the way tests are
run--I can think of two or three times that has happened). One of the
goals of the merge is to reduce the maintenance burden to continue the
Thunderbird support to which Mozilla is committed while requiring less
Mozilla resources to maintain that support.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Hommey||4/3/14 4:30 PM|
remotefilelog only works when you have low latency access to the cache
Git has shallow clones, so it has the problem solved already.
> >Reason #3: It's unnecessary
> Merging mozilla-central into comm-central periodically does seem somewhatThe "atomic commit" issue will likely remain whether TB and SM files are
in mozilla-central or not. Albeit probably less often.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Hommey||4/3/14 4:38 PM|
On Thu, Apr 03, 2014 at 03:19:41PM -0700, Gregory Szorc wrote:Which you also have if you use submodules/subrepositories
which you also can if you use submodules/subrepositories
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
Arguably, they had problems with mercurial too. They just ended up
working on fixing them, which they could equally have done in git except
it's not written in python.
The fact is, they either had to fix those performance issues, or suffer
having to break down their stuff in pieces and improve the workflow with
submodules/subrepositories. The latter is likely more work, especially
the "break it down" part.
Except now, it's the other users of mozbase that aren't in m-c that suffer.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 4:54 PM|
On 4/3/2014 11:21 AM, Nick Alexander wrote:
>> The factors that have compelled us to propose this merge are not1. The mailnews code was originally fully integrated into the Mozilla
build system since before even the public CVS repository was created.
2. Mailnews code more or less requires being linked into libxul. As a
result, this means that Thunderbird can't extricate itself from the
mozilla-central build system.
3. Mozilla-central has historically had to made accommodations
specifically for comm-central, most notably in the build system. Moving
comm-central into mozilla-central would allow us to remove those
accommodations. I don't think such accommodations have been extended to
4. Mozilla has agreed to continue supporting Thunderbird for the
5. Mozilla's source tree has historically not been mozilla-central but
the combination of mozilla-central and comm-central, at least as far as
some things like "is this used in the tree" or "tree-wide mass rewrites"
have been concerned.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 7:35 PM|
On 4/3/2014 5:27 PM, Gregory Szorc wrote: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:
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
I think the benefits of having atomic commits are rather underrated,
having been forced to deal with non-atomic commit situations not only in
comm-central but my research group's repositories.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/3/14 7:38 PM|
On 4/3/2014 6:30 PM, Mike Hommey wrote:The "atomic commit" issue is the inability to make a change that
simultaneously touches both comm-central and mozilla-central code. That
would go away if comm-central were merged in mozilla-central. The
related issue of not all changesets being able to produce a working
Thunderbird build would not go away, although it would hopefully be
reduced in situations such as "I need to add touch all package
manifests" or "I renamed this API globally."
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ishikawa||4/3/14 9:56 PM|
I think the merge would help reduce the load of build system support
once the merge happens and underlying support scripts become stable.
That would also make the newcomer to TB development to
help community-driven support because
- today, the build support is very fragile: mach command does not
work very well (without scary warning, for example) for C-C tree.
- already mentioned in the thread, but for C-C developres,
-- keeping track of TWO hg repositories is a pain when one
uses tryserver: the scarce documentation does not make sense until
you face a strange failure and then the complex underlying framework
dawns on you :-(
-- meaning that simply creating a working development system on local PC
It is a really difficult situation. On one hand, tryserver use is rather
you get the hang of creating contrived patch sets to reflect the local
change to M-C portion of
copy under C-C (residing C-C/mozilla), and tryserver itself suffered a lot
of build breakage
spring and early summer last year probably to the difficulty of
maintaining complex underlying framework (tryserver did not work very well
in the first half of 2013,
to the point, I have not used it lately.)
If merging C-C to M-C alleviates even a small portion of the support issues,
it is a win to mozilla community as a whole.
Also, the reduced threshold for novice developers to set up
local development environment or the better ease of using tryserver (I hope)
may invite more homebrew develoers of a sort. (Maybe I am pipe-dreaming?)
Yes, there is demand and life behind TB.
Just the other day, a friend of mine talked of helping someone converting
from outlook (because of the platform change, I think), and he says the only
choice he could think of was TB.
Fixing outstanding issues in TB is a very important goal of user community
of TB and
anything that makes it easy is a win.
(Yes, I use TB for work and want it to be a "rock-solid mail client (tm)"
that is available on cross-platform fashion.)
I support this move.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Hommey||4/3/14 10:32 PM|
On Thu, Apr 03, 2014 at 09:35:10PM -0500, Joshua Cranmer ? wrote: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 (!))
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Nicholas Nethercote||4/3/14 10:44 PM|
On Thu, Apr 3, 2014 at 9:13 PM, Mark Banner <mba...@mozilla.com> wrote:
> [follow-ups to mozilla.dev.planning]
>Unsurprisingly, one's reaction to this proposal mirrors one's answer
to the question "do I care at all about TB/SM?"
I can see this change would make life a *lot* easier for TB/SM
developers, and it would make life slightly more difficult for Firefox
developers. But there are a lot more Firefox developers and Firefox is
a more important product. So who wins?
I'm not expressing an opinion one way or the other about the proposal,
but just trying to clarify the contours of the discussion.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philip Chee||4/4/14 12:01 AM|
On 03/04/2014 21:28, Henri Sivonen wrote:
> (On that topic: I'm still looking for a volunteer for
> https://bugzilla.mozilla.org/show_bug.cgi?id=937056 . At some point I
> will have whined about this so much that it would have been more
> efficient to just do the move myself even though I'm not supposed to
> use time for Thunderbird development...)
Well yes, but if c-c gets merged then this will simplify the bug as then
we could just do a hg mv followed by a hg rename. Which is why I was
waiting for a decision to merge or not to merge C-C.
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philip Chee||4/4/14 12:08 AM|
On 04/04/2014 00:21, Nick Alexander wrote:Also more recently MetroFx was landed on m-c in one large blob.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/4/14 12:30 AM|
I think we also explicitly think about the infrastructure support
(which may be missing when one speaks of "developers" as people writing the
IMHO, this burden on the infrastructure support in current situation is NOT
SMALL at all, and
that is why the original proposal came about.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/4/14 2:34 AM|
On (2014年04月04日 16:30), ishikawa wrote:I meant to say "we also NEED TO explicitly ..."
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||fqu...@mozilla.com||4/4/14 3:42 AM|
On Fri, Apr 4, 2014 at 7:44 AM, Nicholas NethercoteThis is also the way I perceived the answers here.
Indeed! As someone who's doing Thunderbird work as a volunteer, I'm
really looking forward to this merge.
I understand that people who care only about Firefox are concerned
that this change _may_ make their life slightly more difficult, but
I'm not sure I see what the actual issues are.
The concerns that have been raised so far:
- merging c-c into m-c would increase the size of m-c. Joshua has
shown data indicating that this increase is equivalent to 4 months of
m-c checkins at the current rate. I think this is small enough to make
this concern a non-issue.
- possible confusion when mxr'ing in mozilla-central. As someone who
does Firefox development work, I've sometimes been confused by results
that were for metro, because they were in browser/ and have paths
similar to those of files I was looking for. I don't think I could be
confused by files in a folder named "mail/".
Whether Mozilla should keep supporting Thunderbird with releng is IMHO
a completely different discussion. As far as I understand it, the
current state is that Mozilla Corporation has committed to keep the
product building and to provide security updates in the foreseeable
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ben Hearsum||4/4/14 4:35 AM|
Your response is pretty much what I was trying to get at (which I did
poorly, sorry about that).
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.
+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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/4/14 6:29 AM|
Interestingly enough, the --apparent-size for mozilla-central without
comm-central is 1165MB while the one for mozilla-central with
comm-central is 1249MB.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Zack Weinberg||4/4/14 7:08 PM|
On 2014-04-03 9:07 AM, Benjamin Smedberg wrote: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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/7/14 4:05 PM|
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)
Phillip Kewisch: yes
Zack Weinberg: Yes
Phillip Chee: 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)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Trevor Saunders||4/7/14 4:22 PM|
On Mon, Apr 07, 2014 at 07:05:19PM -0400, Justin Wood (Callek) wrote:istr hearing Brendan needs to approve new top level dirs, so if true it
would seem to be him :-)
so would I for what little its worth ;)
> ~Justin Wood (Callek)
> dev-planning mailing list
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Nick Alexander||4/7/14 4:49 PM|
On 2014-04-07, 4:05 PM, Justin Wood (Callek) wrote:<snip>
> nalexander: NO
Based on the further discussion and history, I'll amend my -1 to a
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/7/14 5:22 PM|
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
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
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
There was some discussion in IRC about this, and there were some people
who indicated support/opposition there without responding to the mailing
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Bobby Holley||4/7/14 8:51 PM|
On Mon, Apr 7, 2014 at 5:22 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>wrote:
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?
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
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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Matthew N.||4/8/14 12:34 AM|
On 4/7/14, 5:22 PM, Joshua Cranmer 🐧 wrote: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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philipp Kewisch||4/8/14 1:56 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 7:14 AM|
On 4/7/2014 10:51 PM, Bobby Holley wrote: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
> I don't think that's true. Even if the code were in comm/, anyone hackingYou 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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Zack Weinberg||4/8/14 7:26 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Bobby Holley||4/8/14 7:35 AM|
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com>wrote:
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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gavin Sharp||4/8/14 9:21 AM|
On Tue, Apr 8, 2014 at 7:14 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
> You mean just like anyone hacking on source code would need to know that theThose 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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 9:33 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Martin Thomson||4/8/14 9:42 AM|
On 2014-04-08, at 09:33, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote: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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gijs Kruitbosch||4/8/14 9:55 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 9:57 AM|
On 4/8/2014 11:42 AM, Martin Thomson wrote: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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gavin Sharp||4/8/14 10:43 AM|
On Tue, Apr 8, 2014 at 9:33 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote: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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Johnny Stenback||4/8/14 11:41 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 12:05 PM|
On 4/8/2014 1:41 PM, Johnny Stenback wrote: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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 12:09 PM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Benjamin Smedberg||4/8/14 12:24 PM|
On 4/7/2014 7:05 PM, Justin Wood (Callek) wrote:
> So to further along, whom of this list gets to make the decision, ifI will assert that this is my decision to make unless I am overruled by
The tradeoff here is a little complex, but I'm going to articulate some
* Firefox, Firefox for Android, and B2G are the first priorities of the
* 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
* 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
Given those, we will not include comm-central in mozilla-central at the
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/8/14 1:04 PM|
On 4/8/2014 3:24 PM, Benjamin Smedberg wrote: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
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
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)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gijs Kruitbosch||4/8/14 3:13 PM|
On 08/04/2014 20:24, Benjamin Smedberg wrote: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.
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.
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 6:45 PM|
On 4/8/2014 2:24 PM, Benjamin Smedberg wrote:
> The tradeoff here is a little complex, but I'm going to articulateI 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.
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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Blake Winton||4/8/14 8:27 PM|
On 2014-04-08, 18:13, Gijs Kruitbosch wrote: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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/8/14 8:42 PM|
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)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gavin Sharp||4/8/14 9:37 PM|
On Tue, Apr 8, 2014 at 3:13 PM, Gijs KruitboschI 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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Doug Turner||4/8/14 9:47 PM|
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
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/8/14 10:04 PM|
On 4/8/2014 11:47 PM, Doug Turner wrote: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 sureSubmodules 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.
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).
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Hommey||4/8/14 10:18 PM|
On Tue, Apr 08, 2014 at 11:27:16PM -0400, Blake Winton wrote: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/. That can
be achieved with or without merging c-c in m-c.
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
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/9/14 12:15 AM|
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
> The hit of humans seeing comm-apps exist is one of policy when coupled withIf 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 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
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 :-(
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/9/14 12:25 AM|
On (2014年04月09日 14:04), Joshua Cranmer 🐧 wrote:This is a good point. Currently, there is no way to run bisect effectively
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
the build infrastructure and such, and such relief should not be
But again, this can be only be emphasized by people who know the
infrastructure inside out.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gijs Kruitbosch||4/9/14 1:45 AM|
On 09/04/2014 05:37, Gavin Sharp wrote: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.
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. :-)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ben Hearsum||4/9/14 6:12 AM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Chris AtLee||4/9/14 6:29 AM|
On 09:12, Wed, 09 Apr, Ben Hearsum wrote: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.
I could see us using the same technique for manging the m-c:c-c
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gervase Markham||4/9/14 9:58 AM|
On 08/04/14 20:24, Benjamin Smedberg wrote: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
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"?
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gregory Szorc||4/9/14 1:49 PM|
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Matthew N.||4/9/14 4:24 PM|
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:>> 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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Philip Chee||4/9/14 11:05 PM|
On 09/04/2014 12:47, Doug Turner wrote: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.
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
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.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Robert Kaiser||4/10/14 8:17 AM|
Philip Chee schrieb:
> I want to point out that in the past KaiRo has filed Firefox bugs toI'm not sure on "the right way", though a secondary review by SeaMonkey
reviewers has sometimes brought forward some actual bugs, and we did
actually port the fixes back, so the code is the same now. A numbers of
times it's been coding style differences enforced by SeaMonkey
reviewers. And other times, like with sanitize, we ported code that was
supposed to land in Firefox but never did (making it a .jsm) - in many
cases, what I ported years ago is now an old version of Firefox code,
though, and badly would need a pile of other patches to be ported on top.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Zack Weinberg||4/10/14 10:13 AM|
-----BEGIN PGP SIGNED MESSAGE-----
On 04/08/2014 03:24 PM, Benjamin Smedberg wrote:
> Zack has mentioned that some of his patches got hung up because ofFor concreteness: the only one still not resolved is bug 650960. (See
specifically comments 18 through 27. Subsequent discussion is all
related to a part of the patch that I thought could land separately,
but there turned out to be no point without the rest of it.)
That is in fact an attempt to remove code which everyone agrees is bad
(at least from a UI perspective) and for which a sane replacement
exists -- considering only Firefox. However, the replacement is not
available in comm-central apps. Under current policy I think I
would've been technically entitled to go ahead and land the patch, but
I don't think it would have been courteous to do so.
I think that if comm-central were merged into moz-central it would be
*dramatically* easier to unjam this bug, because there would no longer
be an artificial boundary discouraging people from adopting new
toolkit functionality in SM and TB. I could just do it myself if no
one got to it first.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
-----END PGP SIGNATURE-----
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gavin Sharp||4/10/14 3:40 PM|
On Wed, Apr 9, 2014 at 1:45 AM, Gijs KruitboschLike I tried to say in my previous post, "get rid of toolkit
completely" is not a goal in and of itself. We should stop dedicating
effort to creating a generic cross-platform app runtime and toolkit,
and we should not let toolkit-purity issues hamper us from making
Firefox better. Both of those things fall short of "actively work to
kill toolkit and anyone who depends on it", which I don't think is
In general, we should take those shortcuts where we can. Devil is in
the details. Please raise and encourage others to raise these specific
"toolkit is making my life difficult" cases on firefox-dev and we can
I wasn't suggesting that it's a slippery slope - I agree with you that
it isn't. I was just using an extreme example, because I was talking
about the extremes. I think taking just one step "down the slope" is
probably too far, though.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Neil||4/11/14 12:37 AM|
Zack Weinberg wrote:
> (How about we ... ban compiled-code XPCOM components that aren't
> linked into libxul? Half kidding.)
Firefox actually ships at least one "external" compiled-code XPCOM
Warning: May contain traces of nuts.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Henri Sivonen||4/11/14 5:54 AM|
On Tue, Apr 8, 2014 at 10:24 PM, Benjamin Smedberg
...In the case of the code I want to remove from m-c, not accommodating
c-c at the time of removal by just letting c-c burn and expecting c-c
devs to figure it out would be both be terribly
impolite/confrontational and contrary to the commitment to provide
maintenance update to Thunderbird.
That is to say, I don't think it's realistic to just remove code from
m-c and let c-c burn in fundamental ways (like IMAP not working or
non-ASCII letters in email being broken). When that's not realistic,
the ease of moving code from m-c to c-c becomes relevant. It would be
easier in a single-repo setting. The current setup means that it takes
even more developer time to do removals, since you not only need to
make the m-c removal patch but you need to deal with the weirdness of
m-c patches on TB try, etc.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Zack Weinberg||4/11/14 8:47 AM|
-----BEGIN PGP SIGNED MESSAGE-----
On 04/11/2014 03:37 AM, Neil wrote:My knee-jerk reaction is that we should stop doing that, but perhaps
there is a compelling reason?
-----END PGP SIGNATURE-----
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||alta88[nntp]||4/11/14 10:02 AM|
This decision is being made at the wrong pay grade, with the wrong micro
The reasons given are contrived to create goal seeked bullet points from
an existing bias. An honest cost-benefit has not been performed; some
of the hidden costs have already been mentioned.
What cost has not been considered is the inevitable headline "Mozilla
Reneges on Promise to Support Thunderbird; Remaining Developers Abandon It.
Some opponents of this plan have posted here with the Thunderbird UA;
this is puzzling - perhaps switching to a new mail client is a lesser
productivity sink than the tremendous problem of seeing /comm in an mxr
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Benjamin Smedberg||4/11/14 10:20 AM|
On 4/9/2014 12:58 PM, Gervase Markham wrote:I still believe that the best and fastest solution here is to merge m-c
into comm-central so that there is a single tree with all the sources
but don't push that merge to mozilla-central. In terms of local
development with MQ at least, it is pretty trivial to split patches into
two pieces, the part that touches comm/ and the part which doesn't. I
know jcranmer still has concerns about this, but it doesn't seem to me
any more complicated than the existing two-repo structure. And as a
bonus, we could still decide to merge the repos in the future. The only
technical issue I can think of is you probably want a server hook to
prevent people committing gecko changes only into comm-central.
In the other case, we would need the following things:
* exclude the comm/ tree in the local checkout by default
* make DXR/MXR index the Firefox-only sources by default
* make sure that comm-only commits don't trigger Firefox builds (on
* make sure that local bisection tools ignore comm-only commits
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/11/14 12:51 PM|
On 4/11/2014 1:20 PM, Benjamin Smedberg wrote:Only that the merge to comm-only completely eliminates the ability to
bisect. Its hard today, but still possible, in your suggestion its not.
Given the disk space/usage evaluation by jcranmer I don't actually see
why this is a requirement nor can I see how it can be *easily* possible
in todays mercurial versions, can you elaborate please.
I can easily do this for MXR, unsure of what it takes for DXR.
We already have instrumentation in buildbot to support this, and I'd go
one step further than browser/ or b2g/ checkins don't trigger
Considering the vast array of local bisection tools, and how bisection
actually works, I don't forsee this as a real tangible goal, nor
necessarily a good one.
Bisects that mark comm-only commit (a) as good will easily be able to
traverse to/from non-gecko commits using their appropriate bisection
logic that can properly narrow down to the correct commit.
~Justin Wood (Callek)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Trevor Saunders||4/11/14 1:24 PM|
On Fri, Apr 11, 2014 at 03:51:47PM -0400, Justin Wood (Callek) wrote:The tools seriously suck for this, but I don't think its *impossible*.
Imagine you have a commit merging in m-c that you know introduced a bug.
now you have a bunch of commits to bisect over, and in principal you
have a commit for which comm/ should build with all of the commits in
m-c. Now take $x to be a commit in m-c you wish to test and $y to be a
commit for which comm/ should build with m-c from $x. you can then run
git checkout $x; git checkout $y -- comm/ then you can test $x with
It seems pretty possible to me, you just have to filter out certain
commits before you pick the one you want to test. Now that can be a
foot gun, but it could be pretty generally useful too e.g. consider
commits that only change docs.
> dev-planning mailing list
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/11/14 1:55 PM|
No, its not, we have build system things that need to change throughout
the tree, configure, etc.
So if we have a branch point that is m-c-only and hundreds of commits,
and a single merge point that builds c-c we can't bisect inside those
Sure, if local devs choose to filter out, its the "by default" that is
hard. And which tools (note ben used the plural) here that bothers me,
which tools. how do we ensure the people ben cares about get updated,
etc. etc. etc.?
~Justin Wood (Callek)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Dolske||4/11/14 2:36 PM|
On 4/11/14 10:02 AM, alta88[nntp] wrote:It's been nearly 2 years since Thunderbird was transitioned to a
community project. AFAIK there was never any explicit timeframe for how
long quasi-official support would continue. I'm not proposing we drop it
today, but 2 years is a long time in the software world... It would be
entirely reasonable for Mozilla to now reconsider how much longer (if
any) it will continue to resource TB.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gregory Szorc||4/11/14 2:51 PM|
It depends how you are doing the "merge." Can't you merge every single
changeset from m-c into c-c? i.e. instead of overlaying m-c @ tip
periodically, you essentially perform an |hg export -r
lastchangeset::tip | hg import -|? The "convert" hg extension can manage
this for you. While you may push hundreds of changesets at a time,
you'll have a 1:1 mapping of commits (albeit with different hashes) for
you to bisect over. You run into problems with automation bustage (you
probably want to hold off "merging" m-c into c-c while c-c is burning).
But I think the problems are manageable.
This method is still a little crummy due to the way m-c merges work. If
I have my way, autoland will enable a more linear m-c and we'll do away
with integration repositories and merge commits almost completely (I
want m-c to have a perfectly linear history with no merges and no
backouts). I don't expect that to happen within a year though.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Hommey||4/11/14 5:24 PM|
On Fri, Apr 11, 2014 at 01:20:58PM -0400, Benjamin Smedberg wrote:
> In the other case, we would need the following things:
> * make DXR/MXR index the Firefox-only sources by default
> * make sure that comm-only commits don't trigger Firefox builds (on* make sure that only comm-only commits trigger Thunderbird builds
(otherwise, Thunderbird builds are going to suck a lot more infra than
they do today)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/11/14 7:30 PM|
On 4/11/2014 4:51 PM, Gregory Szorc wrote:I know you're trying to help, but I'd like to ask you to step back for
moment and ask if you would be willing to impose this kind of repository
management requirements on normal Firefox development. The development
ergonomics of comm-central is presently already in much worse situations
than most mozilla-central developers would be willing to tolerate, and I
think mozilla-central developers are far more willing to mandate
completely unergonomic procedures for comm-central than they would
tolerate on mozilla-central. In contrast, very many of the people
advocating poor ergonomics for comm-central are trying to push for
better developer ergonomics in mozilla-central.
This thread is getting very hard for me to participate in, since (to me)
my concerns are not being addressed or even acknowledged, and my
frustration is reaching the point where it is hard to remain civil. This
isn't meant to be directed at anyone in particular (at least, I'd like
to believe so).
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gavin Sharp||4/12/14 8:20 AM|
On Fri, Apr 11, 2014 at 10:30 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:I think "completely unergonomic" is an exaggeration in this case, but
I definitely am willing to tolerate comm-central development being
"less ergonomic" if that has significant positive impact on Firefox. I
don't think that's unreasonable, given bsmedberg's base axioms.
("significant" and "completely" are subjectivity-introducing
modifiers, which really goes to the heart of the disagreement here. It
seems unlikely that discussion alone will bring closer the two
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Justin Wood (Callek)||4/12/14 4:56 PM|
To me this was an obvious given, but I'd love the ability to trigger
jobs on arbitrary csets that didn't get jobs triggered on (piggybacking
support on other tree-sanity measures releng does, not writing new
one-off stuff, fwiw)
~Justin Wood (Callek)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gervase Markham||4/14/14 1:53 AM|
On 11/04/14 22:36, Justin Dolske wrote:Given what happened last time when rumours of TB's death began to
circulate, can we all avoid raising that spectre again in an
If you feel strongly that we should reconsider our level of support for
TB, probably the safest first route is an email to the Thunderbird
leads, so at least they know you are starting a discussion.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Nicholas Nethercote||4/14/14 1:52 PM|
On Sat, Apr 12, 2014 at 7:36 AM, Justin Dolske <dol...@mozilla.com> wrote:No it's not.
The technical aspects of this decision have been discussed to death,
so I won't say anything about that. I am surprised, however, by how
heartless the discussion has been.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Boris Zbarsky||4/16/14 10:38 AM|
On 4/16/14 1:06 PM, Florian Quèze wrote:
> There's a huge difference between "not being well-supported" (which I
> think Patrick has perfectly accepted) and having people actively
> advocating to make your work needlessly difficult.
The key point of disagreement here seems to be about the word "needlessly".
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Boris Zbarsky||4/16/14 11:21 AM|
On 4/16/14 2:15 PM, Blake Winton wrote:
> Could we all agree on "disproportionately" instead?
I could. I'm pretty sure others in this thread wouldn't...
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Kent James||4/16/14 11:39 AM|
On 4/16/2014 9:47 AM, Ted Mielczarek wrote:
> On 4/16/2014 11:25 AM, clo...@gmail.com wrote:
>> I understand Thunderbird and SeaMonkey may not be important to you, but it is important to me! (And others who contribute to the Thunderbird/SeaMonkey community, including employees who contribute on their spare time.) When Mozilla stopped directly supporting development of Thunderbird it was widely announced that "Thunderbird is dead!". We, as part of the Mozilla community, have been fighting to prove this wrong. Could you please respect our efforts? Merging c-c into m-c will help us focus our efforts on building a great product instead of spending significant effort on keeping a dying one on life-support. (And prove to all that "Thunderbird is dead!" was just a sensational headline.)
>I'm sorry that your goals as a Mozillian
> no longer match up with the goals of Mozilla-the-organization, but
> that's just what it is.
I'm curious if there is anyone active in Mozilla who believes that
keeping Thunderbird under the Mozilla umbrella for the foreseeable
future is a good thing, excluding people who currently spend (or
previously spent) a significant portion of their Mozilla time in
comm-central. This implies a willingness to occasionally experience some
inconvenience and/or cost on behalf of supporting Thunderbird (and
related projects including SeaMonkey, Lightning, and InstantBird).
The impression I have had for the last few years (which has been
confirmed in this thread) is that Mozilla would be delighted to divest
itself completely of comm-central projects, if they could do so without
damaging their core Mozilla brand and Firefox products. But there is
fear that the user fallout from abandoning those products would cause
more damage to Firefox than the cost of keeping them, so comm-central
languishes as the unwanted child of Mozilla.
Is that an accurate impression?
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ms2ger||4/16/14 12:27 PM|
On 04/16/2014 08:39 PM, Kent James wrote:I do.
|RE: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Mike Connor||4/16/14 12:48 PM|
IMost of the data I've seen is that the overwhelming trend for email is
toward mobile, with most estimates putting mobile email clients at over
50% of the market. Web is another huge portion (20-30%). Of the
remainder, there's a lot of thick client usage in business (mostly
Outlook, and mostly tied to Exchange for calendar/GAL integration), but
relatively small outside of that.
Given that, and the fact that we're not exactly setting the world on fire
with innovation in the e-mail space, I don't think we derive a significant
amount of outside credibility for maintaining Thunderbird at this stage.
I believe that a "traditional" desktop email client continues to be a
significant part of many people's overall experience and use of the
internet. Providing such a client is an important part of maintaining
Mozilla's credibility as a community that is more than simply "the company
that makes Firefox", and cares about protecting and improving the whole of
its users' online experience.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Blake Winton||4/16/14 11:15 AM|
Could we all agree on "disproportionately" instead?(By which I mean "the amount of pain caused on one end is far smaller
than the amount of relief on the other end, even taking into account the
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ehsan Akhgari||4/16/14 2:48 PM|
On 2014-04-16, 4:57 PM, Adam Roach wrote:
> On 4/16/14 13:39, Kent James wrote:
>> comm-central. This implies a willingness to occasionally experience> *raises hand*
Since we're doing a show of hands, I do too.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Karl Thiessen||4/16/14 2:20 PM|
Adam Roach <a...@mozilla.com> writes:Yes, emphatically. A mail client that does no advertising and yet is
relatively user-friendly is indispensable in dealing with the modern
Internet. I don't see how we fulfill 'user controls her own experience'
--Karl Thiessen, Mozilla Cloud Services QA.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Pascal Chevrel||4/16/14 4:09 PM|
Le 17/04/2014 00:31, Boris Zbarsky a écrit :
> On 4/16/14 2:39 PM, Kent James wrote:> I'd be in that group.
I am in that group too, not from a developer perspective as I am not a
developer, but from an l10n community perspective. Teams that maintain
both Firefox and Thunderbird have more localizers and the skills to
maintain Thunderbird are the same as the ones to maintain Firefox, which
means that we have access to a wider pool of volunteers interested in
Mozilla and that happily work together. Sometimes it means that the
localizers mostly focused on Firefox will give a hand for Thunderbird or
Seamonkey l10n, but most of the time it is the other way around given
that there is more to do on the Firefox/Firefox OS side in terms of UI
changes, documentation and marketing.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Jonathan Kew||4/16/14 12:26 PM|
On 16/4/14 19:39, Kent James wrote:
> This implies a willingness to occasionally experience someIt may be accurate for some people within Mozilla, but is certainly not
a universal attitude.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Patrick Cloke||4/16/14 5:15 PM|
On 4/16/2014 4:25 PM, Trevor Saunders wrote:
> On Wed, Apr 16, 2014 at 12:48:34PM -0700, Mike Connor wrote:> Remember though that most if not all of the popular web clients aren't
> open source, and maybe that's something we should care about or try to
> fix. Also if everyone starts using one web client it isn't that hard to
> imagine that client changing from email to its own proprietery messaging
I'd argue that this is already happening in the messaging space
(although not exactly in email):
1. Facebook "Chat" (which is somewhere between email and instant
messaging) is a closed silo that cannot be accessed from outside
(actually, I think it can, but it's an incoming blackhole only).
2. Google Talk recently switched to "Google Hangouts", although XMPP
access still works, they've stopped federating to other XMPP servers
(this would be like me being unable to email an outlook.com address from
my gmail.com address!) and switched the backend of all their Google
Hangouts applications to a proprietary protocol.
3. I actually think someone (maybe Joshua would know) told me that
Google uses a different backend once things get "into" gmail as opposed
to the standard system of servers.
I think figuring out client usage is pretty hard though (as has been
alluded to in other branches of this thread).
> I think its good for it to be solid and open but not particularly
This is pretty off-topic, but I think there's a way to do innovative
right, which Thunderbird has not always accomplished. I think the
Thunderbird community has many good ideas, but progress is slow. Anyway,
we'd like to make it so that staying solid and open is the easy part and
we can go about making the improvements we have planned!
Thanks for the thoughts. :)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||David Bruant||4/16/14 12:57 PM|
Le 16/04/2014 18:47, Ted Mielczarek a écrit :
> On 4/16/2014 11:25 AM, clo...@gmail.com wrote:> I understand where you're coming from, but Mozilla can't be all things
> to all people. We have to focus our limited resources where they'll do
> the most good.
I could not agree more (but feel like we may have a different a
definition of "we").
> We have, as an organization decided
This is the tipping point.
It looks like what is usually meant by "the community" isn't really part
of this organization that made these decisions, that has been making
lots of decisions recently.
There are lots of smart people within "the community". It's unfortunate
discussions about "investing in sustainability" were kept behind closed
doors even from the community (as far as I know, I really hope I'm
missing information). And I'm really just picking one example out of many.
(and I'll just note discretly how outrageous it is that Mozilla
"sustainability" is reduced to making money...)
This is shameful. How come Mozilla-the-organisation and mozillians ended
up so far away from one another? How come we can't agree on how to reify
the Mission? How did we end up in someone writing an email saying that
maintaining Thunderbird proved anyone anything wrong?
Am I the only one thinking that there is something deeply wrong in this
misalignment of priorities?
This seems to be all rooted in miscommunications of all sorts.
A solution might start by better communicating on the decision making
process. Heck, maybe have all mozillians be fully part of these? That
would be a start in having no one feel decisions are made upon them.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Boris Zbarsky||4/16/14 3:31 PM|
On 4/16/14 2:39 PM, Kent James wrote:
> I'm curious if there is anyone active in Mozilla who believes that
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/16/14 1:12 PM|
On 4/16/2014 2:48 PM, Mike Connor wrote:Be wary of this data. The design of email is such that it isn't really
possible to passively track statistics, like it is with web browsers.
The most common source of such data is web bugs in mass-mailings, which
Thunderbird (and some other clients) disable by default for privacy
concerns. I think I once saw a GMail administrator off-handledly mention
statistics of the clients they use for IMAP, and I definitely do recall
that Thunderbird is a major client for GMail.
> Given that, and the fact that we're not exactly setting the world on fireI believe there exist various kinds of innovation we can push that we
haven't been given the resources to do so (email security is a great
example here). It's worth noting that, e.g., our email
auto-configuration has been picked up by other clients.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Bob Clary||4/16/14 4:12 PM|
On 04/16/2014 11:39 AM, Kent James wrote:Ditto for me too.
Purely as a user, I vote for keeping Thunderbird under the umbrella.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||fqu...@mozilla.com||4/16/14 10:06 AM|
On Wed, Apr 16, 2014 at 6:47 PM, Ted Mielczarek <t...@mielczarek.org> wrote:
> This means that contributors such as yourself that are still interested
> in Thunderbird will not be well-supported by Mozilla. You're going to
> have to accept that as reality.
advocating to make your work needlessly difficult. The latter is what
has happened in this thread and, I think, the reason why Patrick was
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Trevor Saunders||4/16/14 1:25 PM|
On Wed, Apr 16, 2014 at 12:48:34PM -0700, Mike Connor wrote:
Remember though that most if not all of the popular web clients aren't
> remainder, there's a lot of thick client usage in business (mostly
> Given that, and the fact that we're not exactly setting the world on fire
I think its good for it to be solid and open but not particularly(and all of this ignores the fact that a large number of people who work
for Mozilla use Thunderbird and that is probably some amount of reason
to care on its own)
> > I'm curious if there is anyone active in Mozilla who believes that
> Yes.> _______________________________________________
> dev-planning mailing list
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Adam Roach||4/16/14 1:57 PM|
On 4/16/14 13:39, Kent James wrote:
> I'm curious if there is anyone active in Mozilla who believes that*raises hand*
Principal Platform Engineer
+1 650 903 0800 x863
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/16/14 10:56 AM|
On 4/16/2014 11:47 AM, Ted Mielczarek wrote:> the most good. We have, as an organization, decided that Thunderbird is
> not something that we want to expend significant effort on anymore.
> This means that contributors such as yourself that are still interested> have to accept that as reality. I'm sorry that your goals as a Mozillian
> no longer match up with the goals of Mozilla-the-organization, butWhen Mozilla announced that it would end paid support for Thunderbird
development, the announcement was understood to not mean that it would
be ending support for Thunderbird community. I acknowledge and accept
that Thunderbird has been a second-class citizen of Mozilla for at least
7 years and probably will continue to be for as long as I work on it.
Unfortunately, they way I see most of the responses in this thread, the
goal is not to acknowledge Thunderbird's second-class nature but rather
to force Thunderbird development to be so invisible to the Mozilla
community that Thunderbird developers cease to be members of the Mozilla
community. Quite frankly, these sentiments are hard for me to read as
anything other than a betrayal of trust that Thunderbird users and
community members have placed in Mozilla and a continued personal
insult, which makes this thread the most emotionally bruising
conversation I have been in for years. Your reply, while probably well
meaning, is to me just another "Go away, we don't want you here."
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gary Kwong||4/16/14 3:22 PM|
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||clo...@gmail.com||4/16/14 8:25 AM|
On Monday, April 14, 2014 4:52:53 PM UTC-4, Nicholas Nethercote wrote:I agree, the technical bits here seem to have solutions suggested by Joshua and others, but the non-technical parts of this discussion have left me feeling disheartened and confused with the Mozilla community.
I find it ironic/amusing/sad/upsetting that a few threads above this is a thread entitled "Contributor pathways, engagement points and bug mentoring" while in this thread I see community contributors being blocked at every turn!
Here I don't see people attempting to foster a community by putting their best foot forward. I see people trying to get their *job* done; with an attitude of "if this doesn't help me, get it outta my way!" I don't think this is the right way to grow a community. I don't think this is how Mozilla HAS grown it's community. I don't think it's in line with what Mozilla expects from it's community members (both employees and volunteers!)
Personally, I dislike the amount of Mozilla *Corporation* goals focus in this thread. Can we have a discussion as part of a larger community? Why must it focus on Corporate goals? I'm not part of the corporation, I don't really care what its goals are or are not. I care about Mozilla, I care about providing high-quality, free, open source software to improve the experience of the Internet for everyone. And no, I'm not talking about Firefox. I'm talking about Thunderbird. I understand that Mozilla's goals are currently Firefox and Firefox OS, but these are not my personal goals.
At the Summit I had a few conversations with people about "on-boarding" new employees and getting them to understand how the community works and that interacting with the community in a positive manner is an important part of Mozilla. I don't remember the exact context, but part of it was that it is important that new employees don't think of it as "How can I /use/ the community?", for that implies taking advtange of them, but "How can I work with the community?"
Please don't see this as an "employees vs. volunteers" argument. I believe that I'm expected to live up to these same goals. If I, as a volunteer, can help an employee achieve his goals; I'm -more than willing-, no...I'm EXPECTED to do that. I think this is a two-way relationship that must be fostered. It has seemed to me that over the past couple of years that I've been hanging around here there's been less and less focus on the community and more and more on the Corporation.
Thanks for reading,
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ted Mielczarek||4/16/14 9:47 AM|
On 4/16/2014 11:25 AM, clo...@gmail.com wrote:
> I understand Thunderbird and SeaMonkey may not be important to you, but it is important to me! (And others who contribute to the Thunderbird/SeaMonkey community, including employees who contribute on their spare time.) When Mozilla stopped directly supporting development of Thunderbird it was widely announced that "Thunderbird is dead!". We, as part of the Mozilla community, have been fighting to prove this wrong. Could you please respect our efforts? Merging c-c into m-c will help us focus our efforts on building a great product instead of spending significant effort on keeping a dying one on life-support. (And prove to all that "Thunderbird is dead!" was just a sensational headline.)
I understand where you're coming from, but Mozilla can't be all things-Ted
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/16/14 10:09 PM|
On 4/16/2014 7:15 PM, Patrick Cloke wrote:In the case of discussion forums, open systems have basically ceased to
exist. Newsgroups have generally died down as a discussion forum
(although it's worth noting that Thunderbird captures roughly 10-50% of
the market there, depending on segment). Mailing lists seem to be dieing
down as well. Google Groups is, well, a broken piece of shit for which
the existence of an API to access it is the second-most requested API on
Google . Course discussions at my university and apparently many
others have moved to something called Piazza, which also lacks an API to
access its contents.
It's worth noting that Thunderbird is by far the best leverage that
Mozilla has in this regard, with over 16 million users and established
credence in various standardization and discussion forums.
 I once, when forced to use a group for a class discussion, built
something to scrape the website for the data. Unfortunately, with the
new UI, even this doesn't really work.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ludovic Hirlimann||4/17/14 12:39 AM|
I fall into that category - in the last 6 month have been active
promoting gpg in europe as there is demand for it (since the snwoden
revelation). Our users are asking for it. They are quite happy that we
still deliver Thunderbird and do understand that they can't expect new
features - but they love and *want* the product. Having these loyal
users helps all the goals the org has.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ludovic Hirlimann||4/17/14 12:43 AM|
On 17/04/2014 02:15, Patrick Cloke wrote:
>> I think its good for it to be solid and open but not particularlyAlso to innovate in email you can't only tackle client software you need
to touch servers too and we don't directly. We do indirectly because of
our huge userbase.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gervase Markham||4/17/14 7:11 AM|
On 16/04/14 19:39, Kent James wrote:I admit I am not inconvenienced by its presence, but a working capable
open source desktop (i.e. offline-capable) email client is a
non-negotiable for me to get my daily Mozilla work done, and I've not
found any as good as Thunderbird. The disruption caused to
Thunderbird maintenance and development by its departure from Mozilla
might well be fatal, and that would be a massive negative for me.
 Even if it does have a few bugs I've now been hitting for the best
part of a decade... :-)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Camilo Viecco||4/17/14 7:29 AM|
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Wesley Hardman||4/17/14 8:36 AM|
Also realize that people often use more than one client. For example on different emails I use:
- Outlook, Outlook, mobile
- Outlook, mobile
- Thunderbird, mobile
- webmail, mobile
Mobile having 50% of the market makes perfect sense; regardless of whether you use Outlook, Thunderbird, or webmail, many people will still use a mobile client.
I have never been fond of webmail and always prefer a desktop client. Without support for Exchange / ActiveSync, it is hard to switch to Thunderbird. I would love to be able to use Thunderbird not only as an Outlook replacement, but on Android as well.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/17/14 8:36 AM|
I am contributing TB bug fixes since I use TB for my office work
and personal messaging.
I switched to TB around 2003-4 time frame from Emacs's email subsystem
(RMAIL mostly) since there were now many attachments in formats
understood by Windows executables, and I thought GUI-based
mail client is not such a bad thing after all.
TB was, and still is the only cross-platform open-source mail client
with sizable user base IMHO.
Anyway, I was bitten by some serious data loss bugs over the years, and
tried to fix them. I want TB to be a "rock solid mail client (tm)" :-)
I have not contribute to Firefox side much BECAUSE
I thought that there would ENOUGH eyeballs for web browser
which has been the "IN" thing.
FF does not need another community contributor when there are so many
people working on it. I think I was not mistaken on this side.
Now, the following may push my credibility a bit.
But here it goes.
A year and half ago, I was advised to run tests of Firefox locally as
well as TB necause the bug in core portion of the mozilla software that
affects TB may affect FF as well, and the bug is likely to be worked on
quicker if it is reported as Firefox bug as opposed to TB/SeaMonkey bug
Since then I have observed the situation and I think this advice IS right.
So I tried to compile FF and run tests locally, and immediately I
noticed a compilation error that is triggered by a non-standard
mozconfig (and it occurred in imported software lib.)
I am more than happy to run FF tests locally if it is easy once I can
get it compile using my preferred mozconfig (I just tried full debug
build and explicitly defined -DDEBUG on my compiler line.).
The thorny issue for running FF tests on local PC
for TB-centric community contributor like me is that
because of the split of C-C from M-C, trying to contribute to Firefox
side of testing basically requires the totally separate object tree (for
FF) if I am not mistaken, which is a burden on a tight PC resources on
local PC. (I am using linux VM images to develop patches for TB because
it is so much easy to develop and debug under Posix environment such as
And the command scripts simply do not work cross-application (TB and
FF). The great |mach| command does not work well with TB now.
So believe me, if C-C and M-C is merged and scripts issues are taken
care of to lessen the burden of infrastructure supporters,
I think there would be a few die-hard TB contributors who would
regularly run FF tests as well as TB tests on their local machines, and
report the problems that affect FF bugs as FF bugs :-)
I personally know that the error parsing of logs have not been that
great both in TB (and FF also from what I read in bugzilla) and the test
harness have missed MANY instances of potentially serious errors without
flagging them as something to be worth looking into. I thought of fixing
some of these casually when I noticed these, but they turned out to be
much more complicated to my surprise. Many people pitched in to fix the
So I think making it easier for C-C contributor to run FF tests (by
merging C-C and M-C) will contribute to BUG HUNTING based on local test
runs for FF development as well.
All right, I may be stretching my point too much.
But please understand that
I, as a TB contributor, really want to make it easy to run FF tests
using my C-C tree so that I can report more bugs/issues in core portion.
(I run TB test runs regularly locally, and I just wish running FF tests
locally using C-C tree more easily. Even simple build command scripts
can't be shared easily right now.)
My understanding was that C-C merge with M-C was going to make this
simultaneous compilation and testing much easier in the long run.
As I mentioned earlier that check-ins in now M-C side breaking
C-C sides will be tolerated by many TB community contributors if such
breakage can be fixed quickly (but of course we can't tell easily in
advance.). This has been the case for TB for some time (basically
whoever merges M-C changes to C-C tree have been kind enough to hide
this behind our back.) So I take that is life as usual.
PS: BTW, I have no idea what TB will be like if it is
no longer inside official mozilla tree.
(I mean, there was an opinion voiced of not removing TB from
the main new bugzilla submission page when the bugzilla web UI was
re-designed last year(?). So TB icon still stays on the entry page.
I can hardly guess the form which TB would take once it is detached from
main mozilla development. Maybe a main community repository git host
with occasional check-in of M-C portion of the code? Too bad, such a
model will probably make it impossible to send the bug fix/feedback to
the core M-C portions from TB contributor in a timely manner at all.)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Steve Wendt||4/17/14 11:04 AM|
On 4/17/2014 8:36 AM, Wesley Hardman wrote:IMAP + Lightning + Exchange EWS provider covers a lot:
It would still be nice to have Lightning and the popular providers
(GMail, Exchange) built in, but that's never gotten any traction...
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Daniel Veditz||4/17/14 12:10 PM|
On 4/16/2014 11:39 AM, Kent James wrote:Thunderbird is indispensable for me personally, and philosophically I
believe Mozilla ought to support an open mail+news+calendar (and chat,
while we're at it) client.
There have always been people who think anything other than Firefox is a
distraction. Now there are a lot of people who think anything other than
FirefoxOS is a distraction (giving the first group a slight taste of
second class status). Since the Mozilla Corporation has been hiring for
those roles there are naturally a lot of people with those perspectives.
It's up to us old timers to stubbornly refuse to go away.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Fabrice Desré||4/18/14 11:51 AM|
On Thu, 17 Apr 2014 12:10:01 -0700, Daniel Veditz wrote:Yes, but does that need to be Thunderbird? I would rather like to see
people contribute to gaia's email and calendar apps to make them top
It's not about going away, it's about moving to new horizons ;)
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Steve Wendt||4/18/14 12:02 PM|
On 4/18/2014 11:51 AM, Fabrice Desré wrote:
> I would rather like to see people contribute to gaia's email andProving the point?
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Boris Zbarsky||4/18/14 12:09 PM|
On 4/18/14 2:51 PM, Fabrice Desré wrote:Can I install and run the gaia app as a separate process on desktop?
Does it support nntp?
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Joshua Cranmer||4/18/14 12:37 PM|
On 4/18/2014 1:51 PM, Fabrice Desré wrote:Mobile email clients and desktop email clients are extremely different
methodologies, much more than mere UI concerns. Parts of the backend
code can be shared between Gaia and Thunderbird (and, in the long run,
probably most of the protocol and parsing code will end up being
shared). Even if Gaia becomes a top-notch email client, it's unlikely to
be terribly well-received by people who want to use desktop email clients.
Disclaimer: I'm the idiot who is rewriting Thunderbird's MIME parser
into a better and improved JS version which will eventually go into Gaia
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Fabrice Desré||4/18/14 1:10 PM|
On Fri, 18 Apr 2014 15:09:11 -0400, Boris Zbarsky wrote:Not without a bit of hackery for now because they are certified apps.
Once installed they run in their own process and with their own profile.
> Does it support nntp?
No, alas. Still need to use Pan!
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Andrew Sutherland||4/18/14 1:57 PM|
On 04/18/2014 02:51 PM, Fabrice Desré wrote:
>> Thunderbird is indispensable for me personally, and philosophically ISpeaking as a Gaia email app developer, the Gaia email app is not a
realistic alternative to Thunderbird at this time nor will it be in the
near future given the current level of allocated MoCo engineering
resources and community involvement. And that's ignoring the fact that
a desktop Thunderbird alternative needs an entirely different UI from
the Gaia phone UI.
Particularly problematic for community involvement is that we have a
limited ability to accept contributions that are not implementing
features as planned by product management and UX. For example, NNTP
support would almost certainly not be accepted as a UI-surfaced feature
at this time because it would increase UI complexity and testing surface
area unacceptably. (It probably could be accepted into the back-end,
however, since our architecture could keep it out of Gaia proper.)
Additionally, the Gaia email app has no extension mechanism. While the
back-end has been architected so that we could probably expose equal API
access to other apps via an Inter-App Communication API bridge or
ServiceWorker mechanism (when supported by the platform), that's nowhere
near comparable to Thunderbird's extensive extension capabilities.
Having said all of that, I would love if we could advance the Gaia email
app and its backend and implement a desktop UI, but we need to be
realistic. To seriously have Gaia email compete with Thunderbird would
require doubling the current 2-3 full-time engineers allocated and at
least 6 months. There would likely also need to be commensurate
additional focused platform resources to ensure that the many APIs not
yet exposed to workers would be exposed so that we could migrate to a
SharedWorker to support extensions.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||ISHIKAWA,chiaki||4/18/14 4:00 PM|
One reason I like about thunderbird is its cross-platform support.
So as others mentioned, the desktop (be it windows, POSIX [linux,
freebsd, solaris, OSX, etc.])
users still want to keep thunderbird around.
Mobile usage on small device and desktop (including note PC of course)
are very different as pointed out by others.
Yes, if backend and some modules can be shared, so much the better.
BTW, if Apples mailer on osx is open sourced and becomes cross-platform,
I may want to use it :-)
But "cross-platform" is important for me, and it seems to be very
important for other users of TB as well as the UI configurability from
what I observed reading postings of TB questions to a large Japanese BBS.
Lots of discussion center around how to change the "theme".
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||WaltS48||4/18/14 6:36 PM|
On 04/18/2014 02:51 PM, Fabrice Desré wrote:
> On Thu, 17 Apr 2014 12:10:01 -0700, Daniel Veditz wrote:I can use Gaia's email and calendar app on my openSUSE 13.1 64-bit KDE
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Fabrice Desré||4/19/14 5:33 PM|
On Fri, 18 Apr 2014 21:36:30 -0400, WaltS48 wrote:You can from a b2g desktop build, but not (yet) as standalone
I never said to anyone "switch today from TB to gaia's productivity apps"
- I just believe this is a more promising future than maintaining
And all the use cases that people raise to argue against gaia's apps are
just inputs for what needs to be done, not blockers to me. Yes we need a
good "large screen" UI, yes we need some kind of extensibility, yes we'll
need keyboard shortcuts, filters, threads, s/mime & PGP etc. Let's do
that on top of the web platform!
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Ms2ger||4/19/14 11:08 PM|
And until then, let's not go out of our way to make life suck for
|Re: Fwd: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Jeremy Morton||4/22/14 3:11 AM|
On 03/04/2014 11:15, Mark Banner wrote:
> [Forwarding to correct newsgroups for TB & SM, please follow-up to
> -------- Forwarded Message --------
> Subject: Proposal: Move Thunderbird and SeaMonkey to mozilla-central
> Date: Thu, 03 Apr 2014 11:13:00 +0100
> From: Mark Banner <mba...@mozilla.com>
> Followup-To: mozilla.dev.planning
> [follow-ups to mozilla.dev.planning]
> tl;dr We're proposing to move Thunderbird and SeaMonkey into
> mozilla-central to reduce maintenance complexities for build systems,
> and for releng. Multiple-app handling in the same repository has
> improved greatly, and the general rules would remain the same.
> Feedback and discussion is most welcome - we have generally discussed
> this within some individuals, but not widely.
Wouldn't this make it harder to fully fork SeaMonkey if Mozilla really
screw things up and make it hard to maintain the SM interface, come
Wouldn't this make it harder for SM devs to check things in? With its
own repo, SM's repo retains more of a degree of independence.
Jeremy Morton (Jez)
|Re: Fwd: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Robert Kaiser||4/22/14 8:31 AM|
Jeremy Morton schrieb:
> Wouldn't this make it harder to fully fork SeaMonkey if Mozilla reallyNo. It doesn't mean that more *code* would be shared.
No, not likely.
|Re: Proposal: Move Thunderbird and SeaMonkey to mozilla-central||Gregory Szorc||8/8/14 10:15 AM|
On 4/11/14 10:20 AM, Benjamin Smedberg wrote:
> On 4/9/2014 12:58 PM, Gervase Markham wrote:
>> I am not going to dispute bsmedberg's assertion that, absent Brendan,
>> he's the primary decision maker. But it would be awesome if he could
>> outline what steps might be taken to "get to yes" on this issue. Do
>> you need a DXR patch so it has a checkbox for "include Thunderbird"?
>> Something else? Gerv
> I still believe that the best and fastest solution here is to merge m-c
> into comm-central so that there is a single tree with all the sources
> but don't push that merge to mozilla-central. In terms of local
> development with MQ at least, it is pretty trivial to split patches into
> two pieces, the part that touches comm/ and the part which doesn't. I
> know jcranmer still has concerns about this, but it doesn't seem to me
> any more complicated than the existing two-repo structure. And as a
> bonus, we could still decide to merge the repos in the future. The only
> technical issue I can think of is you probably want a server hook to
> prevent people committing gecko changes only into comm-central.
> In the other case, we would need the following things:
> * exclude the comm/ tree in the local checkout by default
> * make DXR/MXR index the Firefox-only sources by default
> * make sure that comm-only commits don't trigger Firefox builds (on
> * make sure that local bisection tools ignore comm-only commits
There are forces at work to add partial clones and partial checkouts as
core features in Mercurial. Those features shift the burden of
completion of the above list of "blockers" into purely Mozilla's hands.
I don't know what the timetable of this support will be.