Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Proposal: patches.gentoo.org
Date: Tue, 12 Oct 2004 23:20:11
Message-Id: 1097623243.3073.4.camel@localhost
In Reply to: Re: [gentoo-dev] Proposal: patches.gentoo.org by Jeffrey Forman
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

Attachments

File name MIME type
signature.asc application/pgp-signature