1 |
William Hubbs posted on Fri, 30 Jan 2015 17:06:29 -0600 as excerpted: |
2 |
|
3 |
> as a separate thread from my last message, I would like to pose a |
4 |
> question. |
5 |
> |
6 |
> When should ewarns vs news items be used to inform users about changes? |
7 |
> I'm not asking for a policy, just thoughts about when one or the other |
8 |
> should be used. |
9 |
|
10 |
1) New items, unlike ewarns, tend to be high visibility, available BEFORE |
11 |
the install, warn-once. |
12 |
|
13 |
2) We have far more complaints about not enough news items than about too |
14 |
many. (Have there been /any/ complaints about too many? This point has |
15 |
been made by others in previous news item guidance threads.) |
16 |
|
17 |
3) Ewarns, by contrast, are too common, too noisy, and too often |
18 |
repeated, thus they are all too often ignored. (The new I think it's |
19 |
eclass support for what amounts to a warn-once, then put it in a |
20 |
readme.gentoo or whatever, I forgot the details, should eventually help |
21 |
here, but it's likely to be awhile, given old habits on both the dev and |
22 |
user sides and the existing noisy ewarn environment.) |
23 |
|
24 |
4) The fact that news items have a far more formal approval process than |
25 |
ewarns, involving far more people than just the maintainer that an ewarn |
26 |
involves, is a naturally limiting factor. |
27 |
|
28 |
|
29 |
5) Following from the above four points, an informal guideline of if in |
30 |
doubt as the maintainer and you're willing to deal with the additional |
31 |
hassle of a news item, do it, seems reasonable. If we ultimately see too |
32 |
many of them, there's going to be push-back either at the user level or |
33 |
at the pre-approval list-posting level, but at least here I've seen |
34 |
absolutely zero evidence of that so far, rather to the contrary, so the |
35 |
danger seems to remain in too few rather than too many news items. |
36 |
|
37 |
6) Obviously changes in system-critical packages are more likely to |
38 |
warrant priority news items than some corner-case that neither the system |
39 |
nor any other package depends on. However, keep in mind that the |
40 |
display-if-installed and other limiting headers dramatically limit the |
41 |
"doesn't apply to me" noise-factor of news items, so provided these |
42 |
limiting headers are used as intended, even narrow-interest-package |
43 |
maintainers can be more liberal with news items, since only those to whom |
44 |
it applies should be notified about it in the first place. |
45 |
|
46 |
|
47 |
For the specific case in question, we're talking openrc and nfs. Given |
48 |
openrc's central nature on a default gentoo system, how broken a system |
49 |
can be if a boot service isn't configured correctly, and the above "if in |
50 |
doubt, news-item-it" guideline, IMO a new item for pretty much any major |
51 |
change might be considered. Certainly this one for nfs, since it could |
52 |
break bootup for those affected if they don't pay attention. |
53 |
|
54 |
To give it some concrete numbers, given the broken-boot consequences of a |
55 |
user's failure to act on many things openrc, if there's change enough to |
56 |
support it, I don't believe even several openrc related news items a |
57 |
year, even 1-2/quarter on average, would be too many. |
58 |
|
59 |
Tho of course as openrc maintainer, the additional hassle factor you'll |
60 |
experience pushing all those extra news items thru the approval process |
61 |
counts too, and if you'd rather deal with the bug reports and simply |
62 |
point them at the ewarns and say there's the warning, if it's broken |
63 |
because you didn't read it, you get to keep the pieces, qa or no qa, I |
64 |
can't imagine most responsible developers /or/ users disagreeing. You're |
65 |
the maintainer and it's your time either way, pushing the news items or |
66 |
dealing with the bugs, and as long as that remains the case, you decide. |
67 |
=:^) |
68 |
|
69 |
-- |
70 |
Duncan - List replies preferred. No HTML msgs. |
71 |
"Every nonfree program has a lord, a master -- |
72 |
and if you use the program, he is your master." Richard Stallman |