1 |
On Tue, 2004-10-12 at 16:57 -0400, Jeffrey Forman wrote: |
2 |
> (1) A single point of distribution is just a bad idea imho. Imagine a |
3 |
> critical patch that MUST GET OUT IMMEDIATELY (differing opinions of |
4 |
> 'must get out now' apply). You get thousands, even tens of thousands of |
5 |
> people hitting patches.g.o and you can wave goodbye to that machine. |
6 |
|
7 |
Except for the idea would be to use a few machines as |
8 |
"patches.gentoo.org" not a single machine. I think you missed that |
9 |
point in my posting. |
10 |
|
11 |
> (2) The distribution network is there for a reason. Let me be the first |
12 |
> one to admit that it isnt perfect. Once you place something on |
13 |
> /space/distfiles-local, it hits two machines before it hits the world, |
14 |
> taking between an hour and four hours (theoretically) to go public. |
15 |
> Latency is involved in whichever solution we can propose, short of |
16 |
> giving everyone write access to our master mirror. |
17 |
|
18 |
Remember that we're talking patch files and only as a temporary store |
19 |
until the files hit the main mirror infrastructure. |
20 |
|
21 |
> (3) Whether we use distfiles mirrors, or the rsync rotation to |
22 |
> distribute patches, this has not been decided upon. The idea was |
23 |
> broached for a couple minutes earlier today but not even a preliminary |
24 |
> solution was conjured. |
25 |
|
26 |
Actually, we had a decent idea, which Kurt then asked someone to write |
27 |
up, so I did. The idea would be to use the rsync servers, which was the |
28 |
reason I originally put information about something like /space/patches- |
29 |
local as we do *not* want it to mirror distfiles, only the critical |
30 |
patches that we say *have to get out quickly* and we don't want to wait |
31 |
for the normal distfiles mirroring to take place. Anything other than |
32 |
this pretty much makes the whole system useless and adds a *ton* over |
33 |
extra overhead that we were never discussing. |
34 |
|
35 |
> Infra has complete control over the rsync.g.o rotation, so coming up |
36 |
> with ways to improve it that way can be worked out. I am sure this will |
37 |
> be a topic during the next dev meeting, if not listed, I will definitely |
38 |
> mention it. |
39 |
|
40 |
That's what this was supposed to be... ;] |
41 |
|
42 |
> On Tue, 2004-10-12 at 16:10, Nicholas Jones wrote: |
43 |
> > And rewritten for clarity: |
44 |
> > |
45 |
> > 1. developer creates an ebuild which needs a patch |
46 |
> > 2. SRC_URI="mirror://gentoo/patchname http://patches.gentoo.org/patchname" |
47 |
> > 3. Uploads files to dev.gentoo.org:/space/distfiles-local |
48 |
> > 4. developer commits ebuild(s) to cvs |
49 |
> > |
50 |
> > Infra notes: |
51 |
> > |
52 |
> > Immediate availability via the "secondary" host while the primary |
53 |
> > host has yet to receive the files. Once the file is present on the |
54 |
> > primary mirrors it may be deleted from the secondary. |
55 |
> > |
56 |
> > Ensuring that the patch host is not the primary mirror will be a |
57 |
> > concern, but a script can be devised to ensure duplication of |
58 |
> > the patchname and that a primary mirror is listed prior to it. |
59 |
> > |
60 |
> > The host for the files should not be accessable for any reason |
61 |
> > except direct filename downloads. No listings (to discourage |
62 |
> > setting it as a mirroring source). |
63 |
> > |
64 |
-- |
65 |
Chris Gianelloni |
66 |
Release Engineering - Operational/QA Manager |
67 |
Games - Developer |
68 |
Gentoo Linux |