It’s a trade-off.
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 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.
(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.
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.
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.
The reason the update was not in Servo yet was that I wanted to land it
with tests that are not written yet. It is landed now (with an open
issue for the tests). Thanks to Nox and KiChjang for doing it while I
was sleeping.
So here is a proposal to avoid this situation in the future:
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.
What do you think?
And then I still want to run my combined (servo+rust-selectors)
changes through servo try before landing and publishing the
rust-selectors change, which means that I need to go push a special
branch,
You’ll need a branch anyway to make a PR.
and fuss with with the cargo manifests to reference the temporary
branch, and then push that to servo/servo, and then trigger a try
push,
I think we can and should improve tooling here. One command to add a
replacement/override, one command to start a try build.
[...] and then publish to crates.io, [...]
I think we should make Travis-CI publish to crates.io when we merge a
version number change to master.
--
Simon Sapin
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
