[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: rfc: news items vs ewarns
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2015-01-31 8:25:49
Message-ID: pan$467ed$5eb43bb3$71c10cb4$4d693a8e () cox ! net
[Download RAW message or body]

William Hubbs posted on Fri, 30 Jan 2015 17:06:29 -0600 as excerpted:

> as a separate thread from my last message, I would like to pose a
> question.
> 
> When should ewarns vs news items be used to inform users about changes?
> I'm not asking for a policy, just thoughts about when one or the other
> should be used.

1) New items, unlike ewarns, tend to be high visibility, available BEFORE 
the install, warn-once.

2) We have far more complaints about not enough news items than about too 
many.  (Have there been /any/ complaints about too many?  This point has 
been made by others in previous news item guidance threads.)

3) Ewarns, by contrast, are too common, too noisy, and too often 
repeated, thus they are all too often ignored.  (The new I think it's 
eclass support for what amounts to a warn-once, then put it in a 
readme.gentoo or whatever, I forgot the details, should eventually help 
here, but it's likely to be awhile, given old habits on both the dev and 
user sides and the existing noisy ewarn environment.)

4) The fact that news items have a far more formal approval process than 
ewarns, involving far more people than just the maintainer that an ewarn 
involves, is a naturally limiting factor.


5) Following from the above four points, an informal guideline of if in 
doubt as the maintainer and you're willing to deal with the additional 
hassle of a news item, do it, seems reasonable.  If we ultimately see too 
many of them, there's going to be push-back either at the user level or 
at the pre-approval list-posting level, but at least here I've seen 
absolutely zero evidence of that so far, rather to the contrary, so the 
danger seems to remain in too few rather than too many news items.

6) Obviously changes in system-critical packages are more likely to 
warrant priority news items than some corner-case that neither the system 
nor any other package depends on.  However, keep in mind that the
display-if-installed and other limiting headers dramatically limit the 
"doesn't apply to me" noise-factor of news items, so provided these 
limiting headers are used as intended, even narrow-interest-package 
maintainers can be more liberal with news items, since only those to whom 
it applies should be notified about it in the first place.


For the specific case in question, we're talking openrc and nfs.  Given 
openrc's central nature on a default gentoo system, how broken a system 
can be if a boot service isn't configured correctly, and the above "if in 
doubt, news-item-it" guideline, IMO a new item for pretty much any major 
change might be considered.  Certainly this one for nfs, since it could 
break bootup for those affected if they don't pay attention.

To give it some concrete numbers, given the broken-boot consequences of a 
user's failure to act on many things openrc, if there's change enough to 
support it, I don't believe even several openrc related news items a 
year, even 1-2/quarter on average, would be too many.

Tho of course as openrc maintainer, the additional hassle factor you'll 
experience pushing all those extra news items thru the approval process 
counts too, and if you'd rather deal with the bug reports and simply 
point them at the ewarns and say there's the warning, if it's broken 
because you didn't read it, you get to keep the pieces, qa or no qa, I 
can't imagine most responsible developers /or/ users disagreeing.  You're 
the maintainer and it's your time either way, pushing the news items or 
dealing with the bugs, and as long as that remains the case, you decide. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


[prev in list] [next in list] [prev in thread] [next in thread]