Gentoo Archives: gentoo-dev

From: Marius Mauch <genone@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Date: Fri, 11 Nov 2005 17:43:27
Message-Id: 20051111184053.780ed8c9@sven.genone.homeip.net
In Reply to: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two by Ciaran McCreesh
1 On Sat, 5 Nov 2005 00:58:14 +0000
2 Ciaran McCreesh <ciaranm@g.o> wrote:
3
4 > Feedback from people who have something useful to say would be very
5 > much welcomed, assuming of course that they've read the GLEP.
6
7 Things that I think are generally ok as is:
8 - news item format
9 - news item distribution (server side)
10
11 Things that I'd like to be changed/I'm not completely sure about:
12 - filtering of news items:
13 I've already asked a similar question in another mail (in other
14 context) without an answer, but how many news items do people believe
15 will exist at any given time? Depending on the actual implementation it
16 might be required to scan all existing news items which could take some
17 time if there is a large number of them (say, more than a few hundred)
18 It's clear that noone can present accurate numbers, just after some
19 rough estimates here.
20 Also it might be useful for this filtering to be an external tool using
21 portage functions and called by portage (see also below). Although this
22 could be considered an implementation detail as it's mostly transparent
23 for ebuild devs/users.
24
25 - local storage of news items / "read" attribute:
26 I don't really the like the copy-if-new feature and handling at the fs
27 level, I'd use a file that lists the ids of news items (potentially
28 with a timestamp and/or status field). I don't see any benefits of
29 having redundancy here, and accessing the news in $PORTDIR is simple
30 enough. Granted race conditions might be an issue (where the solution
31 complicates tools), but that's so minor I wouldn't really care about
32 it.
33 Another thing that's unclear: "Whenever relevant unread news items are
34 found, emerge will copy or symlink the news file into
35 /var/lib/gentoo/news/."
36 This "Whenever ... are found" is too vague, should this apply to emerge
37 --sync, any emerge operation, any "import portage" call or what? This
38 isn't just an implementation detail.
39 PS: I'd avoid symlinks here at all costs, too easy to break them.
40 Also as Brian and Jason have said already, the system should be able to
41 handle multiple repositories. So to use the current GLEP as example, at
42 least the path should be changed to /var/lib/gentoo/news/porttree
43
44 - quality control:
45 "Any complaints regarding wording or clarity must be addressed before
46 the news item goes live." Playing devils advocate here, but complaints
47 regarding correctness are not mandatory to be adressed?
48 As for using -core, please add a small explanation or at least a
49 reference to the appropriate policy docs (and please save the comments
50 about GuideXML uris ;)
51
52 Things that should definitely be changed:
53 - Integration with existing systems:
54 This definitely should be a requirement for the GLEP to be considered
55 final. It doesn't prevent some thing being implemented sooner than
56 others, but multi-channel distribution (to use a buzzword) is a
57 requirement from where I come from.
58
59 Marius
60
61 --
62 Public Key at http://www.genone.de/info/gpg-key.pub
63
64 In the beginning, there was nothing. And God said, 'Let there be
65 Light.' And there was still nothing, but you could see a bit better.
66 --
67 gentoo-dev@g.o mailing list

Replies