Simon took the "big sign" approach, which seems fine to me: https://github.com/servo/rust-selectors
In a few months, gps' tooling may give us the ability to keep the separate repo synced up automatically, which would let us have our cake and eat it too. bholley On Fri, Feb 10, 2017 at 4:00 PM, Jack Moffitt <j...@metajack.im> wrote: > 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
