On Sun, Sep 17, 2017 at 12:09 PM, Steve Fink <sf...@mozilla.com> wrote:
> On 9/16/17 6:43 AM, Eric Rescorla wrote: > >> On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >> >> I'd prefer to take a data-driven approach to answering the question of "do >>> we need to support vanilla Git." I wish I had local developer metrics or >>> results from a recent developer survey to feed into a decision. In lieu >>> of >>> that data, I'd encourage users of vanilla Git to make noise on bug >>> 1400470 >>> if you feel you need `mach try` support. >>> >>> This is not a good decision making procedure. First, requiring people to >> volunteer their objections inherently underweights those objections >> because >> it's work to do so. Second, the current situation has incentivized people >> to use cinnabar, so the number of vanilla git users is less than it >> otherwise would be. But this is bad, for the reasons I listed above. The >> right question is: what future do we want to live in, and that's a policy >> question, not one decided by taking a (highly biased) poll of what people >> currently do. >> > > Supporting more tool variants (eg adding bare git to the current two) > requires more resources. Well, if we simply supported vanilla git properly, we wouldn't need cinnabar support, so it's not strictly greater. > In a perfect world, that resource decision would be based on the actual > costs and benefits to the overall organization. My observation is that so > far, we have kept a tight limit on the number of resources dedicated to > this sort of tooling, independent of an objective cost/benefit analysis. > (Which is even somewhat justifiable; tooling, like many other areas, can > easily grow to absorb whatever resources you give it, so it's hard to judge > "enough".) > > This means that I have a lot of sympathy for the tooling people who would > be forced to maintain the wider variation, with no reason to believe that > the necessary resources will be made available. It will just starve out > resources for other tooling, limiting us closer to a common denominator set > of functionality. > You say "common denominator" like it's a bad thing. But using commodity tooling is *good*, not bad, as the recent example of doing something largely custom with mozreview rather than just taking Pharicator more-or-less off the shelf demonstrates. The reason to write new tooling is when you can't get away with commodity tooling. > But that's just a general observation; if you look at this specific case, > it might not be much effort to support native git for richer/future try > pushing. But that's very different from requiring all the tools to support > native git on an equal basis. And it seems reasonable to evaluate the > utility of this specific support via a poll, even one known to be biased. > I don't think that's true, for the reasons I indicated above. Rather, there's a policy decision about whether we are going to have Git as a first-class thing or whether we are going to continue force everyone who uses Git to fight with inadequate workflows. We know there are plenty of people who use Git. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
