On 2015-10-26 7:17 PM, Philipp Kewisch wrote:
On 10/23/15 11:09 PM, Eric Rescorla wrote:
It may well be that having c-c code in m-c decreases friction overall,
since it saves time for the people that know they're allowed to break TB
but choose to help it anyway. However, the cost of redirected work for
contributors that _don't_ know they're allowed to break TB is real. That is
the tradeoff that needs to be weighed IMO.
What Bobby said here seems very important. In the cost/benefit analysis,
the impact on Firefox needs to be weighted very heavily. In particular,
breaking TB should not cause failures either on try or on commit, and
changes to pieces of Gecko should not be held up on their impact on TB.
If we get this right on the tooling side, I don't think it will be a
concern. For contributors that are regular Mozillians, I think it has
been clearly communicated that making changes in Firefox and Toolkit
does not require fixing Thunderbird/Seamonkey.
This is I think the crux of the issue. "Making changes in Firefox
doesn't require fixing Thunderbird/SeaMonkey" is far away from the truth
in practice.
Over the years I have gained a *ton* of experience in code that
interfaces with both Firefox and Thunderbird/SeaMonkey. I can't really
think of a single instance where I made a change in that code and it
broke something in Thunderbird and the breakage was magically fixed
without my involvement.
What happens in practice is people file bugs and ping you and unless
we're talking about a very simple API change that is obvious to mirror
in c-c, nobody will do anything about the regression unless if the
Firefox developer looks at it. So it's a choice between actively
ignoring people (which is really being rude to them, which is not an
option I would personally take) or having to do some work (which often
involves reading and understanding the c-c code, debugging it, and so on.)
Now, as an employee of MoCo, I am told to spend 0 time on these issues.
Therefore, I try to be responsible, and nice, and spend my spare time
to fix them. (Saying this part with the best possible intentions) And
you've seen how I have been treated elsewhere in the thread, in the
sub-thread that I stopped participating in. This situation is really
not sustainable for a healthy community.
To me it's completely clear that the rule on paper that we have for not
worrying about c-c has failed in practice. I think any technical
decision based on the imaginary idea that people can just ignore TB/SM
code is doomed to fail.
In the past I have supported moving c-c into m-c. I was the person who
filed <https://bugzilla.mozilla.org/show_bug.cgi?id=787208> three years
ago. I still think that this decision makes perfect sense from a
technical point of view. Every time that we have merged a satellite
repository into m-c the result has been a net win for the ongoing
technical work.
But there is also the policy side of things. At Mozilla we typically
make rules by documenting existing practices, but this is one of those
cases where existing practices differ wildly with the rules. I used to
think that it's OK to just ignore the policy side of things and focus on
the technical work, but from my personal experience the result of doing
that is different individuals spend varying amounts of efforts on c-c
issues (varying from 0 to substantial amounts of time) and they're all
treated as if everyone's spending 0 amount of time, because that's what
the rules say.
This leaves a pretty bad taste on a personal level. But at the project
level, it is detrimental to the health of our communities, and as a
result to the quality of Thunderbird and SeaMonkey (and thirdly Firefox).
I have come to the conclusion that it's been a mistake to ignore the
policy side of things in these discussions. I honestly don't know what
the right solution is, but I think that reducing this issue to just the
technicality of where the source code lives is not a good way to go forward.
Best regards,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
