1 |
On Sat, 5 Nov 2005 22:18:14 +0900 Jason Stubbs <jstubbs@g.o> |
2 |
wrote: |
3 |
| > A more reliable way of getting news of critical updates out to |
4 |
| > users is required to avoid repeats of the various recent upgrade |
5 |
| > debacles. |
6 |
| |
7 |
| Examples of the "recent upgrade debacles" aren't needed, but you |
8 |
| should at least state some of the outcomes that occurred, whether it |
9 |
| be unscheduled downtime, data corruption or whatever. |
10 |
|
11 |
I'm trying to avoid throwing in too many unnecessary references, but I |
12 |
guess a couple here would be useful. |
13 |
|
14 |
| |
15 |
| > Preemptive |
16 |
| > Users should be told of changes *before* they break the user's |
17 |
| > system, after the damage has already been done. |
18 |
| |
19 |
| s/after/when/ perhaps? This sentence takes a couple of reads... |
20 |
|
21 |
Ring up another one for me hitting . in Vim forgetting that I'd done a |
22 |
daw after the gq} ... |
23 |
|
24 |
| > Quality control |
25 |
| > There should be some way to ensure that badly written or |
26 |
| > irrelevant messages are not sent out, for example by inexperienced |
27 |
| > developers, those whose English language skills are below par or |
28 |
| > morons. |
29 |
| |
30 |
| "morons" is not needed either. |
31 |
|
32 |
No, but it's funny! |
33 |
|
34 |
| > The following headers are used for filtering. If none of these |
35 |
| > headers are specified, the news item is displayed for all users. |
36 |
| > Otherwise, the news item is displayed if *at least one* header |
37 |
| > matches. |
38 |
| |
39 |
| It would seem more useful if the headers were sorted into the three |
40 |
| classes first. A news item would then only be displayed if a header |
41 |
| from the class matches or the class is empty. This would allow for |
42 |
| rules such as "net-www/apache is installed and the keyword is either |
43 |
| mips or sparc". |
44 |
|
45 |
Hrm. I'll need to think about that. But it's starting to sound nicer |
46 |
than the and/or/none voodoo I'd removed previously. |
47 |
|
48 |
| Isn't keyword just a generalization of profile? Why have both? |
49 |
|
50 |
Simplicity. |
51 |
|
52 |
| > Thus, all proposed news items must be posted to the ``gentoo-dev`` |
53 |
| > or ``gentoo-core`` mailing list, and ``Cc:``\ed to |
54 |
| > ``pr@g.o`` at least 72 hours before being committed |
55 |
| > (exceptions may be made in exceptional circumstances). Any |
56 |
| > complaints regarding wording or clarity **must** be addressed |
57 |
| > before the news item goes live. |
58 |
| |
59 |
| Why gentoo-core? It's a news item; it's purpose is to be made public. |
60 |
|
61 |
Possible security concerns. Hopefully this will never happen. |
62 |
|
63 |
| Why put this in portage at all? Post sync hooks will likely be |
64 |
| available in 2.0.54. If adding hooks were as easy as adding a file to |
65 |
| a portage config directory, would adding the package that does the |
66 |
| above to the system package set be enough to force this new |
67 |
| information dispersal method on users? |
68 |
|
69 |
Performance. I have a bash script which does the installs that could |
70 |
easily be called by a hook, but it has to call portageq quite a bit. |
71 |
Otherwise a hook would be fine... Possibly it's fine anyway? |
72 |
|
73 |
-- |
74 |
Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) |
75 |
Mail : ciaranm at gentoo.org |
76 |
Web : http://dev.gentoo.org/~ciaranm |