On 9/16/17 6:43 AM, Eric Rescorla wrote: > 2. There are a lot more people writing code for Firefox than developing the > internal tools, so in general, costs on those people should be avoided.
On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla <e...@rtfm.com> wrote: > 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. > I might be reading the first statement wrong: I see that as an argument to avoid putting more costs on the people who develop and maintain internal tools, because it's a smaller group. If this is an accurate reading, then the second paragraph appears to be contradictory: moving the pain and complexity around git from all Firefox developers onto this smaller group will increase costs for that smaller group. From my perspective, gecko-dev conversions have largely been as smooth as can be expected for the past number of years, but we're seeing more timeouts, and it may only be a matter of time before we either need to sink significant internal tools development time into the conversion script, or we hit an issue that causes significant downtime. If I'm reading wrong, and you're saying we need to avoid putting costs on the larger Firefox development group, then the two statements are non-contradictory. I do think expecting supporting 2 VCSes as seamlessly as one is a large ask of the smaller team; do many other software projects support multiple official VCSes and workflows? 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
