On 2015-10-23 2:17 PM, Joshua Cranmer 🐧 wrote:
It's a relatively easy matter to fix the first; the second is harder to
do for all contributors. I've been told it's a coming feature, but I've
been told this for a while.
I also wonder why you have a peculiar insistence that comm-central code
must not appear to any contributor, given the continued existence of
"stuff that Firefox doesn't care about" in mozilla-central, such as
support for tier-3 platforms (do we still have QT code in the tree) or
xulrunner. The mere presence of code in a codebase has proven to be
horribly insufficient to guarantee that people care about maintaining
it--history has time and time and time again shown that any code that
doesn't impact Treeherder results *WILL* get broken. (Easiest case in
point: try building without unified files.)
What matters more about what code remains in the tree and what code
doesn't is whether it's maintained. We have in the past removed code
for these tier3 ports and products when they have been unmaintained
(example: bug 969757) and we should be doing more of that.
What are the long term plans for the Thunderbird and SeaMonkey community
to maintain their code, if it gets merged into m-c? On tb-planning I
see ongoing discussions about moving to other platforms such as
Electron, or the broader doubts about how Thunderbird wants to deal with
future upcoming changes such as the current add-ons?
Without long term plans for the code being maintained, we should not
move it into m-c.
Except that to demand contributors don't care about comm-central would
be to demand of your employees that they should be jerks to the wider
open-source community.
As pointed out by others, this is completely untrue, and I personally
think that framing the problem like this isn't the most helpful.
Please note that even if we move the code into m-c, we will continue to
break it (unintentionally) so Thunderbird will still see regressions
caused by "upstream" changes that they need to deal with.
> Merging comm-central into mozilla-central, with
the exception of the time spent doing the actual merge work, would
reduce the amount of time that core contributors would have to spend
worrying about comm-central in the short and medium-terms for sure.
I don't think one could assert this or the opposite.
From my perspective, your insistence on the bar to entry for Firefox
development (or, rather, explicitly deprioritizing Thunderbird and
Seamonkey) seems like a weak ad-hoc justification. How can you justify
letting core contributors take the time to review patches for systems
that Mozilla will never officially support--mingw, OpenBSD, iOS--while
saying that they shouldn't be taking the time to review patches for
systems that Mozilla officially supports?
Speaking as someone who has reviewed quite a few such patches, and also
as someone who has tried to bend over backwards and sideways to serve
Thunderbird's needs, there is a huge difference between the two. The
patches to maintain tier3 platforms are typically written by the
maintainers for such platforms and for the most part are tiny and simple
patches, but the outcome c-c breaking because of an m-c changes are
sometimes in form of complaints and not patches to fix the issues.
Now, where the code is in theory non-consequential towards the behavior
of people in response to an upstream breakage. So let's focus on the
implications of where the code lives, and not conflate that with the
frictions between the communities.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
