On Tue, Sep 19, 2017 at 10:21 AM, Eric Rescorla <e...@rtfm.com> wrote:
> > On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight <amccrei...@mozilla.com> > wrote: > >> On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote: >> >> > Generally no, but this is an unfortunate consequence of Mozilla's >> decision >> > a while ago to pick a VCS which has not turned out to be the dominant >> > choice (not placing blame here, but I think it's clear that's how it's >> > turned out). The result is that a lot of people want to use git and that >> > means git needs to have a first class experience. >> > >> >> I've been using git for years now to develop Firefox, and I feel like it >> is >> a first class experience. There's a one time cost to setting up cinnabar, >> but after that, everything just works, including |mach try| and |mach >> mozreview|. It is still probably less setup than Mercurial users have to >> go >> through to install enough extensions to make hg usable. ;) Sure, there's a >> bit of "wacky custom machinery", but developers using hg also have to deal >> with some of that, so that's more of a Firefox developer problem than a >> git >> Firefox developer problem. >> > > Maybe you have different workflows than I do. > > Specifically, I want to be able to do all of: > > 1. Push to try > 2. Land CLs directly > 3. Push to review (I mostly use phabricator so, that works fine) > 4. Push branches to Github > > It's the combination of 1/2 and 4 that works badly because hg/cinnabar and > github are > basically just separate histories, at least with nss-dev but IIRC with > gecko-dev. > Bobby and I chatted offline and it seems that if you use mozilla/gecko rather than mozilla/gecko-dev that this works properly. If so, then it seems like having well-supported github-based cinnabar clones of all our repos would go a long way towards addressing my issues. -Ekr > > I've also had cinnabar fail badly at various times, and then it's been > pretty unclear what > the service level guarantees for that were. > > -Ekr > > >> >> Andrew >> >> >> >> > -Ekr >> > >> > >> > > Originals to end. >> > > >> > > >> > > On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla <e...@rtfm.com> wrote: >> > > >> > >> On Mon, Sep 18, 2017 at 2:56 AM, James Graham < >> ja...@hoppipolla.co.uk> >> > >> wrote: >> > >> >> > >> > On 18/09/17 04:05, Eric Rescorla wrote: >> > >> > >> > >> > 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. >> > >> >> >> > >> > >> > >> > I don't entirely understand what concrete thing is being proposed >> > here. >> > >> As >> > >> > far as I can tell the git-hg parameter space contains the following >> > >> points: >> > >> > >> > >> > 1. Use hg on the server and require all end users to use it >> > >> > 2. Use git on the server and require all end users to use it >> > >> > 3. Use hg on the server side and use client-side tooling to allow >> git >> > >> > users to interact with the repository >> > >> > 4. Use git on the server side and use client-side tooling to >> allow hg >> > >> > users to interact with the repository >> > >> > 5. Provide some server side magic to present both git and hg to >> > clients >> > >> > (with git, hg, or something else, as the on-disk format) >> > >> > >> > >> > These all seem to have issues relative to the goal of "vanilla git >> > with >> > >> no >> > >> > custom code": >> > >> > >> > >> > 1. Doesn't allow git to be used at all. >> > >> > 2. Requires a multi-year transition away from hg. Probably not >> > popular >> > >> > with hg fans. >> > >> > 3. The status quo. Requires using a library for converting >> between hg >> > >> and >> > >> > git (i.e. cinnabar) or some mozilla-specific custom scripts (the >> old >> > >> > moz-git-tools) >> > >> > 4. Like 3. but with an additional multi-year transition and >> different >> > >> > custom tooling. >> > >> > 5. Allows vanilla git and hg on the client side, but requires >> > something >> > >> > complex, custom, and scary on the server side to allow pushing to >> > either >> > >> > repo. Could be possible if we eliminate ~all manual pushes (i.e. >> > >> everything >> > >> > goes via autoland), but cinnabar or similar is still there in the >> > >> > background. >> > >> > >> > >> >> > >> This is what I meant. And having something complex and scary on the >> > server >> > >> side is (at least to me) obviously better than having something >> complex >> > >> and >> > >> scary (and did I mention constantly out of date) on the client side, >> > >> because it's all in one place and externally just looks like the >> thing >> > the >> > >> client is expecting. Note that we already have half of this because >> we >> > >> have >> > >> one-way synching to gecko-dev on the server side. Perhaps one could >> also >> > >> rip off some of the servo-gecko synching stuff here, but I don't know >> > much >> > >> about how that's architected. >> > >> >> > >> >> > >> Given none of those options seem to fit, the only other possibility I >> > can >> > >> > think of is to skip the general problem of how to interact with the >> > VCS >> > >> for >> > >> > try specifically by making submitting to try not look like a VCS >> push, >> > >> but >> > >> > like some other way of sending a blob of code to a remote machine >> > (e.g. >> > >> > using some process that generates a patch file). But unless there's >> > some >> > >> > extant way to achieve that it seems like it would be replacing >> > >> > known-working code (cinnabar) with new custom code. >> > >> > >> > >> >> > >> > So my best guess is that you mean that all pushes should go via >> > autoland >> > >> > and we should provide read-only hg/git repositories, and try pushes >> > >> should >> > >> > also go via something other than a vcs push. But I'm probably >> missing >> > >> > something. >> > >> >> > >> >> > >> Well, I do think this is the direction we should be moving towards, >> as >> > it >> > >> seems to have a pile of advantages. Indeed, if we're *already* going >> to >> > be >> > >> forcing people to submit to try via mach rather than via vcs push, >> why >> > >> wouldn't we do that for this piece of it now? >> > >> >> > >> -Ekr >> > >> >> > >> >> > >> > >> > >> > _______________________________________________ >> > >> > dev-platform mailing list >> > >> > dev-platform@lists.mozilla.org >> > >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> > >> > >> _______________________________________________ >> > >> dev-platform mailing list >> > >> dev-platform@lists.mozilla.org >> > >> https://lists.mozilla.org/listinfo/dev-platform >> > >> >> > > >> > > >> > _______________________________________________ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
