Let's allow until Friday afternoon for feedback to come in, but I
don't think it makes sense to delay this decision.
jack.
On Wed, Feb 8, 2017 at 12:23 PM, Simon Sapin wrote:
> On 08/02/17 19:42, Bobby Holley wrote:
>>
>> Won't they need to do this anyway? At least assuming we accept your
>> pro
On 08/02/17 19:42, Bobby Holley wrote:
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 P
On Wed, Feb 8, 2017 at 2:28 AM, Anthony Ramine 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.
Le 08/02/2017 à 12:39, Simon Sapin a écrit :
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 fo
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
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?
Regards.
> Le 7 févr. 2017 à 22:47, Bobby Holley a écrit :
>
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://l
6 matches
Mail list logo
