Mike Hoye wrote: > > 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.
It's hardly fair to say that "we've been talking about this stuff for years now" when this is the very first time it's been posted. There was no public notification of the intention of doing away with splinter/MozReview. Sure, there may have been talks but were they public and not just hidden in some obscure thread? > > 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. Not exactly a good analogy there, considering icebergs can also sink ships. So this discussion has been pretty much invisible from people who use the tools and only for the select few. > 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), Yes. I did participate in that. Though I'm not entirely sure what came off that discussion. > - 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 Oh hell yeah. This truck/bus factor is a definite PITA, and I applaud any effort in fixing this. > - the much more pernicious set of hidden costs we incur from _failing_ > to standardize on certain tools and processes. I agree as well. > > 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. Oh... hell yeah. You've mentioned quite a lot of pain points in the whole process, and I certainly agree with them. However, it would've been a better process if there was some sort of public declaration of intention of moving to a tool which would streamline the whole review and commit process. While there may have been a smattering of discussions here of commit policies, there wasn't a concise, for lack of a better word, glue to point out that there was going to be this change. The point is this. We have bugzilla and having a review process that enable people to review patches without needing to jump to another tool, would be more effective than needing to jump from one tool (bugzilla) to another one. If Phabricator does the job well, then so be it. Thank you for your clarifications, Mike. Edmund _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
