To followup, the core team is in favor of this change, and since it already landed, there's nothing more to do.
I do think it's useful to decide what to do about the old repo. Do we put a big sign on it pointing to servo/servo? Or do we keep up synced to take PRs? jack. On Thu, Feb 9, 2017 at 10:40 AM, Gregory Szorc <gsz...@mozilla.com> wrote: > > >> 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 _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
