On Thu, Feb 9, 2017 at 10:51 AM, Anthony Ramine <n.ox...@gmail.com> wrote:
> 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. > (Sorry for going offtopic, but I don't think it's that black and white. We do/did have standalone SpiderMonkey source releases for instance. I think a bigger problem was that we had an API from the C era that was (and still is) hard to use correctly (with no or outdated documentation) and it changed all the time, while V8 started from scratch with a cleaner C++ API and had the "new, cool, most advanced JS engine" marketing.) Jan > We can't quantify the missed opportunities when merging things together in > a single repository. > > > 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
