On 11/02/17 01:09, Bobby Holley wrote:
Simon took the "big sign" approach, which seems fine to me:
https://github.com/servo/rust-selectors
Yes, as mentioned in another part of this thread:
I’ve pushed a new branch to https://github.com/servo/rust-selectors and
made it the default. It only has
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, J
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
> On Feb 9, 2017, at 01:51, Anthony Ramine 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 a écrit
I think the complexity of the wpt-style setup is overkill, but I think
we could do something to alleviate the community participation issue.
We could perhaps keep the rust-selectors repo around and following the
Servo in-tree one. PRs could still be done by external contributors
the rust-selectors
> 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.
I don't think anyone is disagreeing with you on this point. The plan
is as it always has been - to spl
Could we do the same thing for rust-selectors? And should we?
On Thu, Feb 9, 2017 at 9:27 AM James Graham wrote:
> On 09/02/17 16:18, Michael Howell wrote:
> > WPT still has its own repo; the Servo repo just does an occasional
> > bidirectional sync. The equivalent for rust-selectors would be if
On 09/02/17 16:18, Michael Howell wrote:
WPT still has its own repo; the Servo repo just does an occasional
bidirectional sync. The equivalent for rust-selectors would be if the
rust-selectors repo was kept and just occasionally synced with Servo (like
Servo is doing for M-C, anyway).
Sure, but
WPT still has its own repo; the Servo repo just does an occasional
bidirectional sync. The equivalent for rust-selectors would be if the
rust-selectors repo was kept and just occasionally synced with Servo (like
Servo is doing for M-C, anyway).
On Thu, Feb 9, 2017 at 8:21 AM James Graham wrote:
On 09/02/17 09:51, Anthony Ramine wrote:
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
I do know that there was once a discussion between the folks behind
greenkeeper.io and Rustaceans to support Rust/crates.io as well.
I can check with those people to see if that went anywhere or what would
be needed to make it happen.
On Wed, Feb 08, 2017 at 06:23:47PM +0100, David Bruant wrote:
On Thu, Feb 9, 2017 at 10:51 AM, Anthony Ramine 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
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 a écrit :
>
> On Wed, Feb 8, 2017 at 2:28 AM, Anthony Ramine wrote:
>
On 08/02/17 22:31, Jack Moffitt wrote:
Let's allow until Friday afternoon for feedback to come in, but I
don't think it makes sense to delay this decision.
I approved https://github.com/servo/servo/pull/15447 and it has already
landed. Oh well.
I’ve pushed a new branch to https://github.com/
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
20 matches
Mail list logo
