On 7/16/17 11:10 PM, Edmund Wong wrote:
Joe Hildebrand wrote:
I'm responding at the top of the thread here so that I'm not singling out any
particular response.
We didn't make clear in this process how much work Mark and his team did ahead
of the decision to gather feedback from senior engineers on both Selena and my
teams, and how deeply committed the directors have been in their support of
this change.
Really? So? What exactly is your point?
This sarcasm is unwarranted.
Given that we've been talking about this stuff for years now, I think
it's very clear that we haven't come to this point by "somebody at the
top issuing an edict that they want something modern"; the decision to
commit to Phabricator was ultimately announced on May 11th, and that
decision wasn't made unilaterally or lightly.
We've been discussing how to improve our tooling and processes in open
forums for years now, most frequently on dev-platform. Despite that,
it's true that a lot of the major influences of this decision have been
mostly invisible to people who aren't involved in the day to day work on
infrastructure and tooling, in the way that icebergs are mostly invisible.
Some of the things that haven't made it into this thread that have
influenced this decision include:
- a real and pressing requirement to update our commit access policies
and practices, and backstop them with reliable tooling (a discussion you
participated in, as I recall),
- the significant engineering burdens (including opportunity cost and
bus-factor risk) of being the sole owner/user of a major piece of
infrastructure software that's not our core product, and
- the much more pernicious set of hidden costs we incur from _failing_
to standardize on certain tools and processes.
It's a very serious drag on product development and contributor
participation if everyone - paid senior engineers and new contributors
alike - needs to use _this_ tool and process and coding style (and and
and) to participate in one part of the project, and _that_ etc. etc. to
participate in another. Or, sometimes, even other corners of the same
codebase.
Each of those on their own is a huge deal, probably big enough to
warrant a major change in our tooling and processes. And it's true that
we haven't done a great job of explicitly spelling out what a big deal
they are, and how much they've informed our decision-making. But while
we support - and will always support - user choice in our products,
there aren't enough engineering hours in a year for us to support a
bunch of different ways of shipping, securing, measuring and improving
the tools and processes that provide those choices _to_ our users.
So, yes, we could have done a better job of communicating here and
making our process more transparent, but I'm very confident that this
decision will make life a lot better for Mozilla's casual contributors
and broader community as much as for Mozilla's full-time engineers. If
you'd like to dig into the details of "why" I'd be happy to do so. And
if we can do that without unnecessary snark, all the better.
- mhoye
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
