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
