> On Feb 9, 2017, at 01:51, Anthony Ramine <n.ox...@gmail.com> wrote: > > I'm not against the decision if we are willing to revert it in the future > (which is why I didn't reply immediately following your reply), but I have a > few things to say nonetheless. > >> Le 8 févr. 2017 à 19:42, Bobby Holley <bobbyhol...@gmail.com> a écrit : >> >> On Wed, Feb 8, 2017 at 2:28 AM, Anthony Ramine <n.ox...@gmail.com> wrote: >> >>> Could you please push the code you wanted to test on your GH's fork, >>> so we can at least see what prompted this discussion? >>> >> >> I haven't split it out yet, because I'm still hoping that the outcome of >> this discussion is that I won't have to. The unified code changes are in >> part 3 of https://bugzilla.mozilla.org/show_bug.cgi?id=1336646 > > How does the discussion mean you don't have to split? All I see is three > patches, none of them making it obvious how the selectors API changed. This > also means that the commit messages will never ever be written from the POV > of selectors, and always from the POV of servo, thus quite limiting any > lingering hope to have external contributors now, given it will not be as > discoverable as before what is happening in the crate at the commit level. > > In general, I posit that Mozilla completely, utterly, lost against V8 in the > embedded department in a huge part because of this mono-repository thing > where everything is muddled together. > > We can't quantify the missed opportunities when merging things together in a > single repository.
A monorepo does not intrinsically infringe on software freedoms and flexibility: engineering culture/decisions and (deficient) tools do. The main reasonable concerns against a monorepo from where I sit are that the VCS and tools around it don't scale or handle the scenario better. We can address this somewhat by exporting/importing directories between a monorepo and standalone repositories. This is the model we're using with Servo in the Firefox repo. That handles the VCS scaling problems. There are still some issues around keeping things in sync (single writable master is critical to avoid divergence) and workflows around things like history rewriting on Pull Requests as part of landing. But these can also be mitigated (and aren't unique to monorepos). > >>> On Wed, Feb 8, 2017 at 3:39 AM, Simon Sapin <simon.sa...@exyr.org> wrote: >>> >>> It’s a trade-off. >>> >> >> Totally. My request here is that we evaluate this tradeoff with some >> consideration for the realities of the crate in question. I'm totally happy >> to bias towards "separate repo" if the tradeoff is at all unclear. >> >> >>> >>> It’s true that historically we’ve been more eager than necessary to put >>> every crate going to crates.io in its own repository. (See for example >>> github.com/servo/webrender_traits, since then merged into webrender.) >>> >>> I understand that juggling multiple repositories makes things complicated >>> for Servo contributors. But I think that it’s not too terrible once you >>> figure out the workflow, and that we can improve it both with tooling (in >>> Cargo replacements/overrides support) and in our own habits/conventions. >> >> >>> On the other hand, keeping / moving back a library in servo/servo that is >>> used outside makes life more difficult for contributors >> >> >> Right. It makes life harder for some people and easier for others. But if >> we evaluate the aggregate pain on both sides, I posit that the tradeoff >> _thus far_ has not been worth it (see below about future contributions). >> >> >>> since they need to clone/checkout a much larger repository, CI takes much >>> longer, is more prone to unrelated intermittent failures, and the CI queue >>> can be more busy. >>> >> >> Won't they need to do this anyway? At least assuming we accept your >> proposal below that: "Whenever a PR to rust-selectors (and other >> repositories where we think that’s appropriate) makes breaking changes, we >> don’t land it until there’s also a corresponding PR to update Servo for >> these changes." > > As Simon says in his own reply, no we never block people because they did a > breaking change that requires action on Servo's side. That's the main reason > why things are split IMO. Servo shouldn't be a special burden for unrelated > contributors. > >>> (Though this has gotten better now that we don’t need anymore to retry >>> more often than not because of intermittent.) >>> >>>> On 07/02/17 22:47, Bobby Holley wrote: >>>> >>>> rust-selectors was split out into a separate crate and repository in 2015. >>>> Since then, there has been one push (with 2 commits) by a contributor that >>>> does not also contribute to servo >>>> >>> >>> But we don’t know how many people will want to contribute in the future, >>> and how many would be discouraged if it’s in servo/servo. >>> >> >> We have two years of historical data. That does not predict the future, >> it's at least some indication of the volume we might expect in the near >> term. >> >> I also think that even if the direct benefits in this particular case are >>> small, doing this is part of being a "good citizen" in the Rust ecosystem. >> >> >>> >>> >>> But now I'm ready to land these changes, and things get tricky. The latest >>>> version of rust-selectors is several breaking versions ahead of the one >>>> used by servo, so now I need to either do these updates for code changes >>>> I'm not familiar with, or block my patch indefinitely until someone else >>>> does it: I can't make progress until that "lock" is released. >>>> >>> >>> In this case, servo/rust-selectors had two breaking changes ahead of Servo: >>> >>> * One added variants to a public enum. Since Servo doesn’t match values of >>> that enum, no change at all was required. >>> >>> * The other changed a parameter in a method of a public trait from Foo to >>> &Foo. The fix was to add & in a few places in Servo. >>> >> >> There were also text expectations that needed adjustment. > > Which you could have updated yourself, after the first failing CI pass. > >>> But yes, you couldn’t know how much effort this update would take until >>> you tried it. You could have asked, though. We have people in multiple time >>> zones who could help with this, some of whom reviewed the relevant changes. >>> >> >> I had a feeling that it might be more than I bargained for. And was I >> wrong? It took 2 people 6 attempts (spread across 2 PRs) and 9 hours to get >> it landed. Anthony and Keith were heroic, but that is certainly a lot of >> friction just to put the tree in a state where I can start trying to land >> my patch. > > Please don't call that heroic, that's just me doing my job. I believe such > janitoring is a mandatory and crucial part of doing FOSS, and it's beyond me > why people would rather do cross-project commits, where the commit messages > often don't make sense when considering one of the moving parts in isolation. > But well, YMMV. > > Also, there is nothing fancy about "spread across 2 PRs", given how easy it > is to make a PR (as opposed to doing stuff in m-c and bugzilla), and KiChjang > could have just amended mine instead of making a new one altogether. > > All in all, I spent like 15 minutes on that, the rest was CI doing its own > time-consuming job and KiChjang changing the expectations on his own PR. > > Regards. > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
