On Fri, Oct 31, 2014 at 02:03:35PM -0400, Ehsan Akhgari wrote: > On 2014-10-31 12:51 PM, Gregory Szorc wrote: > >As has been said on this list before, switching canonical to Git just > >isn't going to happen. Valid reasons have been given before. But here's > >a new one: we don't need to. > > > >I think it's fair to say that the pain point for Firefox Git developers > >*today* is that they need to run Mercurial locally. That introduces > >overhead, new commands to learn and run, etc. As you mention, setting up > >a server to receive Git data/pushes eliminates a lot of problems. > > > >I thought about deploying something like Fog Creek's Kiln (software that > >speaks the wire protocol for both Mercurial and Git and does conversion > >behind the scenes). However, the more I think about it, the more this > >idea terrifies me. > > FWIW I think that solution is needlessly complicated. > > > The moment you do that you are catering to the lowest > >common denominator (or at least it becomes easy to fall into that trap). > >This likely penalizes Mercurial users because we can't extend Mercurial > >as much and thus can't capture as many productivity wins. > > I do think that we should continue to cater towards the lowest common > denominator. And what I mean by that is to not use hg features which will > be impossible to support in git and vice versa. But I'm not sure what > things you were talking about here specifically. Having discussions about > the lowest common denominator in the abstract is hard!
agreed > >All problems in computer science can be solved by another level of > >indirection. The problem here is that Git users need to push to the > >canonical Mercurial repositories (inbound, try, etc). You will be > >hearing me say this a lot in the months ahead, but "Autoland changes > >everything." > > I don't understand how. Doesn't Autoland still require you to push your > changes somewhere? If that somewhere is an hg repo we're back to square > one. > > >With Autoland in place, there is a level of indirection between the user > >and landing: a landing queue. In my utopian end state for Autoland, no > >user - whether they use Git or even Mercurial - are pushing directly to > >the canonical repositories. Only the Autoland agent performs that role. > > FWIW I think that's a bit too eutopian. I have no hopes of eliminating all > of the need for pushing stuff manually. "Land this thing at some point in > the near future" is a very common use case but it's far from being the only > one. I agree, but I wouldn't be suprised to see a world in which only sherriffs need to push directly, or close enough we can maybe not care. > >Suddenly the publishing workflow becomes unidirectional and this whole > >syncing problem with Hg<->Git SHA-1 maps becomes abstracted away into > >the implementation of Autoland. We can stand up Git servers to allow Git > >native ingestion, without burdening Git users with the knowledge, > >overhead, or cognitive dissonance of Mercurial. > > Not sure if I follow. Are you suggesting that git users push to their own > vanilla git server, and then autoland comes around some time later, converts > that into hg, and tries to transplant the result? Why is that better than > just having a git server that pushes to an hg server before accepting a > push? That seems to both address the use case of pushing to Autoland's hg > repo, and also the use cases that do not involve Autoland. to somedegree these are kind of the same right? the big difference between both of these and a normal server is that you push a history, but don't expect you'll pull the same thing because you expect what you push will be rebased. > >That end state would solve a lot of problems. But a few remain. Notably, > >collaboration between Mercurial and Git users would still be problematic > >(it likely always will be). > > Yes, agreed. agreed, but that seems like a problem for the git / hg communities to solve for their users. > >It also means the server-side infrastructure becomes more complex and > >harder to maintain. To achieve the tight cohesion necessary to present a > >fully optimized and seamless workflow, all these services likely need to > >be running as part of the same logical system, sharing the same > >underlying data store, without syncing being a major issue. Do I think > >this is the right and inevitable solution? Yes, I do. Ideal, no. (Ideal > >would be to support one system - and tell the users of the other to take > >a hike. If I had my way, that one system would be Mercurial because it > >is easier to extend and can lead to better productivity. But short of a > >mandate that makes a lot of people upset and has extremely high costs to > >implement, this ideal isn't going to happen.) > > Since you keep mentioning this (and *without meaning to start a flame war*), > let this be on the record that I think mercurial's extensibility etc don't > really matter for a user of the VCS, unless they work in a very specialized > environment (such as the big silicon valley tech companies that have used hg > in the past few years). Productivity is subjective, and not an objective > property of either git or mercurial. The reason I and others go through this > pain right now to avoid having to use hg more is increased productivity. > So, I'd appreciate if you didn't make it sounds like mercurial is all about > user productivity and git isn't. :-) > > >Unless a major decision is made, we're trending towards more complexity > >on the server to support Git ingestion. > > Are we though? Cause for the past recent years, our approach towards git > users has been very close to "take a hike". Is there now a push towards > treating them better? (Genuinely asking, since I haven't heard anything > about an organizational drive towards treating git users better recently.) > > > Again, I think that is the > >correct outcome. A problem is we don't have the resources to instantly > >make that happen. As much as I want to have a flag day where Try is > >fixed and Git users get native ingestion, it isn't going to happen at > >the same time. We have a pressing need to fix Try. We need to fix Try > >first, *then* make the Git users happier [through native ingestion]. > >And, doing Git hosting right involves merging (or at least strongly > >coordinating) a lot of systems managed by different groups > >(hg.mozilla.org, git.mozilla.org, vcs2vcs, autoland, mozreview, release > >automation, etc). Fortunately, recent org changes have made that easier > >(this should all fall under Laura Thomson), so it isn't the pipe dream > >it once was. > > > >I *think* the Git users will eventually be able to eat cake. But it may > >take a bit. It's not going to happen overnight. It certainly isn't going > >to happen before the replacement Try infrastructure is deployed. What > >I'm looking for is a path forward that placates the Git crowd until we > >have the organizational will and resources to tackle Git ingestion. If > >that means I or someone else must write Git tools to support the new > >systems, so be it. I'll happily choose that outcome over bloating scope > >to cover increased server complexity in the short term. I just need to > >be sure the solution is tolerable by Git users. > > I think everyone understand that as a git user, they're a second class > citizen at best, so this won't be surprising. But I'd like to talk about > two specific points: > > 1. Are the changes that you're planning to make to the try server inherently > incompatible with git? An example of such an incompatibility would be for > example changing the wire format of the protocol to send in data that is > only available on the client and not transmittable through git push. I don't think I understand your question here. > 2. What if anything should we do differently in the mean time? since as far as I know we all more or less use mercurial (possibly through scripts) just deal with whatever changes the mercurial people have to deal with. > Both of these questions would be easier to answer if you explain your plans > in more detail. :-) very much agreed it would be easier to evaluate a concrete plan. Trev > > Cheers, > Ehsan > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
