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. 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.
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.
Also, the assumption that you submit try jobs via standard revision
control operations is an artifact of our current implementation. It's
true that many other systems are doing the same thing, but many other
systems don't have anything akin to try syntax. And as history has
proven, selecting an appropriate set of tasks to run is not a trivial
thing, so it kind of makes sense to have *some* sort of special-case
tooling around it.
I agree that the larger policy question is the right one to ask, though.
What future do we want to live in? The git/github juggernaut is hard to
ignore. (Confession: I'm a happy hg user, so the current setup works
fine for me and I don't know enough about the alternatives to understand
the tradeoffs in using cinnabar vs raw git. Heck, over half of my github
checkouts are through hg-git; I don't understand why anyone would use
git in the first place if they didn't have to. Obviously, opinions vary!)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
