On Tue, Dec 22, 2015 at 1:46 PM, Yehuda Katz wrote:
> I want to make sure that I understand the core constraints here:
>
>1. Gecko wants to be able to reliably do builds (especially urgent
>ones) without relying on the uptime of third party services.
>2. Gecko's build bots do not have
On Tue, Dec 22, 2015 at 2:46 PM, Yehuda Katz wrote:
> I want to make sure that I understand the core constraints here:
>
>1. Gecko wants to be able to reliably do builds (especially urgent ones)
>without relying on the uptime of third party services.
>2. Gecko's build bots do not have
I want to make sure that I understand the core constraints here:
1. Gecko wants to be able to reliably do builds (especially urgent ones)
without relying on the uptime of third party services.
2. Gecko's build bots do not have any access to the Internet.
3. Servo will continue to make
On Tue, Dec 22, 2015 at 7:02 AM, Simon Sapin wrote:
> On 22/12/15 03:55, gsz...@mozilla.com wrote:
>
>> The *only* way to prevent [race conditions] is for there to be a
>> single source of truth.
>>
>
> Yes, I think that’s an important point.
>
>
> An alternative is to make mozilla-central the ca
On Mon, Dec 21, 2015 at 6:55 PM, wrote:
> On Thursday, December 17, 2015 at 3:29:17 PM UTC-8, Bobby Holley wrote:
> > I had a long conversation about the two-way sync stuff at Orlando with
> Alex
> > and some of the Servo folks.
> >
> > We concluded that, long-term, we need to let Gecko hackers c
Reposting this without the extraneous mailing lists. Please reply to this
one.
On Tue, Dec 22, 2015 at 9:23 AM, Bobby Holley wrote:
> On Mon, Dec 21, 2015 at 2:47 PM, Alex Crichton
> wrote:
>
>> I think one important aspect here is to separate out the concerns of
>> vendoring code in-tree vs wh
On Mon, Dec 21, 2015 at 2:47 PM, Alex Crichton
wrote:
> I think one important aspect here is to separate out the concerns of
> vendoring code in-tree vs where that code is developed. It sounds like
> Gecko has lots of technical requirements about why and how code lives
> in-tree, but the more imp
On Dec 22, 2015 4:17 AM, "James Graham" wrote:
>
> On 22/12/15 03:52, Yehuda Katz wrote:
>
>> In my opinion, #3 is best addressed with support for automated mirroring
of
>> both crates.io and git dependencies. Mega-corps like LinkedIn use
mirroring
>> services for Rubygems, npm, and maven to ensur
On 22/12/15 03:55, gsz...@mozilla.com wrote:
The *only* way to prevent [race conditions] is for there to be a
single source of truth.
Yes, I think that’s an important point.
An alternative is to make mozilla-central the canonical repository.
Facebook has [...]
When it comes time to merge a
On Thursday, December 17, 2015 at 3:29:17 PM UTC-8, Bobby Holley wrote:
> I had a long conversation about the two-way sync stuff at Orlando with Alex
> and some of the Servo folks.
>
> We concluded that, long-term, we need to let Gecko hackers commit to the
> vendored code and have that code autom
I think one important aspect here is to separate out the concerns of
vendoring code in-tree vs where that code is developed. It sounds like
Gecko has lots of technical requirements about why and how code lives
in-tree, but the more important bit here is how it changes over time.
What Yehuda was sa
I think one important aspect here is to separate out the concerns of vendoring
code in-tree vs where that code is developed. It sounds like Gecko has lots of
technical requirements about why and how code lives in-tree, but the more
important bit here is how it changes over time.
What Yehuda w
On 22/12/15 03:52, Yehuda Katz wrote:
In my opinion, #3 is best addressed with support for automated mirroring of
both crates.io and git dependencies. Mega-corps like LinkedIn use mirroring
services for Rubygems, npm, and maven to ensure high-availability. This
maintains the normal developer wor
Thanks. This is great!
Responses inline.
Yehuda Katz
(ph) 718.877.1325
On Mon, Dec 21, 2015 at 6:19 PM, Gregory Szorc wrote:
> On Mon, Dec 21, 2015 at 2:29 PM, Bobby Holley
> wrote:
>
> > On Mon, Dec 21, 2015 at 2:21 PM, Yehuda Katz wrote:
> >
> >> On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holl
On Mon, Dec 21, 2015 at 2:29 PM, Bobby Holley wrote:
> On Mon, Dec 21, 2015 at 2:21 PM, Yehuda Katz wrote:
>
>> On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley
>> wrote:
>>
>> > I don't think this is going to fly in Gecko, unfortunately.
>> >
>> > Gecko is a monolithic repo, and everything needs
On Mon, Dec 21, 2015 at 4:56 PM, Yehuda Katz wrote:
>
> On Mon, Dec 21, 2015 at 4:31 PM, Bobby Holley
> wrote:
>
>> I CCed them upthread, but then the subsequent reply dropped them. ;-)
>>
>> I would suggest starting a new, explicit thread with a summary of what's
>> been discussed thus far (rat
On Mon, Dec 21, 2015 at 4:31 PM, Bobby Holley wrote:
> I CCed them upthread, but then the subsequent reply dropped them. ;-)
>
> I would suggest starting a new, explicit thread with a summary of what's
> been discussed thus far (rather than asking them to jump into this one),
> and CCing dev-serv
I CCed them upthread, but then the subsequent reply dropped them. ;-)
I would suggest starting a new, explicit thread with a summary of what's
been discussed thus far (rather than asking them to jump into this one),
and CCing dev-servo.
That being said, my guess is that it's going to be a mostly
On Mon, Dec 21, 2015 at 4:17 PM, James Graham
wrote:
>
> It is not immediately apparent to me if that is sufficient to meet the
> Gecko requirements, but again, having this conversation on a list without
> gps, ted, glandium and other build peers seems rather counterproductive
> since they know b
On 21/12/15 22:45, Yehuda Katz wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Dec 21, 2015 at 2:28 PM, Josh Matthews
wrote:
On 2015-12-21 5:21 PM, Yehuda Katz wrote:
On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley
wrote:
I don't think this is going to fly in Gecko, unfortunately.
Gecko is a
Yehuda Katz
(ph) 718.877.1325
On Mon, Dec 21, 2015 at 2:28 PM, Josh Matthews
wrote:
> On 2015-12-21 5:21 PM, Yehuda Katz wrote:
>
>> On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley
>> wrote:
>>
>> I don't think this is going to fly in Gecko, unfortunately.
>>>
>>> Gecko is a monolithic repo, and
On Mon, Dec 21, 2015 at 2:21 PM, Yehuda Katz wrote:
> On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley
> wrote:
>
> > I don't think this is going to fly in Gecko, unfortunately.
> >
> > Gecko is a monolithic repo, and everything needs to be vendored in-tree
> (a
> > non-negotiable requirement from
On 2015-12-21 5:21 PM, Yehuda Katz wrote:
On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley wrote:
I don't think this is going to fly in Gecko, unfortunately.
Gecko is a monolithic repo, and everything needs to be vendored in-tree (a
non-negotiable requirement from the build peers). This means th
On Mon, Dec 21, 2015 at 2:14 PM, Bobby Holley wrote:
> I don't think this is going to fly in Gecko, unfortunately.
>
> Gecko is a monolithic repo, and everything needs to be vendored in-tree (a
> non-negotiable requirement from the build peers). This means that we'll
> already need an automated p
On Mon, Dec 21, 2015 at 1:52 PM, wrote:
> Developing against external packages (including ones shared with Servo)
> and pulling in changes as needed can be an easier process than you expect,
> and the alternatives (forking or syncing) have much more serious
> consequences.
>
> The basic idea is t
Developing against external packages (including ones shared with Servo) and
pulling in changes as needed can be an easier process than you expect, and the
alternatives (forking or syncing) have much more serious consequences.
The basic idea is that you work with shared dependencies from crates.i
On 18/12/15 00:04, Valentin Gosu wrote:
[http] timeout = 0, which prevents
downloading any resources from crates.io. [1]
Serious question: does timeout = 0 stop HTTP requests from being made in
the first place, or do they fail because you happen to be more than 500
miles from an S3 server?
On Thu, Dec 17, 2015 at 5:08 PM, Lars Bergstrom
wrote:
> - How do we handle commit access? Having the upstream maintainers
> (none of whom might be current Gecko peers) correctly identified and
> doing reviews in bugzilla to ensure m-c pushes can be upstreamed seems
> challenging.
>
Auto-upstrea
Thanks for doing this investigation, Valentin!
I'm a little bit worried about the mechanics of auto-upstreaming:
- How do we handle commit access? Having the upstream maintainers
(none of whom might be current Gecko peers) correctly identified and
doing reviews in bugzilla to ensure m-c pushes can
On 17/12/15 23:04, Valentin Gosu wrote:
From what I understand servo's mach has a command for two-way sync between
web-platform-tests and upstream.
It does, but let's be clear that the implementation there isn't end-user
quality and is simplified byd specific policies in web-platform-tests
I had a long conversation about the two-way sync stuff at Orlando with Alex
and some of the Servo folks.
We concluded that, long-term, we need to let Gecko hackers commit to the
vendored code and have that code automatically upstreamed. Similarly,
upstream fixes need to be automatically merged int
31 matches
Mail list logo
