From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EYNxt-0006KL-3E for garchives@archives.gentoo.org; Sat, 05 Nov 2005 13:20:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA5DJ0b7024878; Sat, 5 Nov 2005 13:19:00 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA5DH0Sp027964 for ; Sat, 5 Nov 2005 13:17:00 GMT Received: from zh034158.ppp.dion.ne.jp ([222.3.34.158] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EYNul-0008Vi-GE for gentoo-dev@lists.gentoo.org; Sat, 05 Nov 2005 13:16:59 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id A199424816D; Sat, 5 Nov 2005 22:18:14 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two Date: Sat, 5 Nov 2005 22:18:14 +0900 User-Agent: KMail/1.8.92 References: <20051105005814.0de0d8ff@snowdrop.home> In-Reply-To: <20051105005814.0de0d8ff@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200511052218.14564.jstubbs@gentoo.org> X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id jA5DH0Sp027964 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id jA5DJ0ch024878 X-Archives-Salt: b4415ae0-6180-4a01-824b-f27bd1b82d2a X-Archives-Hash: 93ec7f6f319a3124b8f3b7a645525f31 > A more reliable way of getting news of critical updates out to users is > required to avoid repeats of the various recent upgrade debacles. Examples of the "recent upgrade debacles" aren't needed, but you should a= t=20 least state some of the outcomes that occurred, whether it be unscheduled= =20 downtime, data corruption or whatever. > Preemptive > =C2=A0 =C2=A0 Users should be told of changes *before* they break the u= ser's system, > =C2=A0 =C2=A0 after the damage has already been done. s/after/when/ perhaps? This sentence takes a couple of reads... > No user subscription required > =C2=A0 =C2=A0 It has already been demonstrated [#forums-whining]_ that = many users do > =C2=A0 =C2=A0 not read the ``gentoo-announce`` mailing list or ``RSS`` = feeds. Could you use "complaints" instead of "whining" or whatever will represen= t=20 what the users are doing from an unbiased point of view please? > Quality control > =C2=A0 =C2=A0 There should be some way to ensure that badly written or = irrelevant > =C2=A0 =C2=A0 messages are not sent out, for example by inexperienced d= evelopers,=20 > =C2=A0 =C2=A0 those whose English language skills are below par or moro= ns. "morons" is not needed either. > The following headers are used for filtering. If none of these headers = are > specified, the news item is displayed for all users. Otherwise, the new= s > item is displayed if *at least one* header matches. It would seem more useful if the headers were sorted into the three class= es=20 first. A news item would then only be displayed if a header from the clas= s=20 matches or the class is empty. This would allow for rules such as=20 "net-www/apache is installed and the keyword is either mips or sparc". > ``Display-If-Installed:`` > =C2=A0 =C2=A0 A dependency atom or simple package name (for example, > =C2=A0 =C2=A0 `` =C2=A0 =C2=A0 package specified installed, the news item should be disp= layed. >=20 > ``Display-If-Keyword:`` > =C2=A0 =C2=A0 A keyword [#glep-22]_ name, for example ``mips``. If the = user is on the=20 > =C2=A0 =C2=A0 arch in question, the news item should be displayed. > > ``Display-If-Profile:`` > =C2=A0 =C2=A0 A profile path, for example ``default-linux/sparc/sparc64= /server``. If=20 > =C2=A0 =C2=A0 the user is using the exact profile in question, the news= item should be > =C2=A0 =C2=A0 displayed. This header may be used to replace ``deprecate= d`` files in=20 > =C2=A0 =C2=A0 the future. Isn't keyword just a generalization of profile? Why have both? > Thus, all proposed news items must be posted to the ``gentoo-dev`` or > ``gentoo-core`` mailing list, and ``Cc:``\ed to ``pr@gentoo.org`` at le= ast > 72 hours before being committed (exceptions may be made in exceptional > circumstances). Any complaints regarding wording or clarity **must** be > addressed before the news item goes live. Why gentoo-core? It's a news item; it's purpose is to be made public. > Client Side > ''''''''''' >=20 > Whenever relevant unread news items are found, ``emerge`` will copy or > symlink the news file into ``/var/lib/gentoo/news/``. >=20 > Notification that new relevant news items will be displayed via the > ``emerge`` tool in a similar way to the existing "configuration files n= eed > updating" messages: >=20 > :: >=20 > =C2=A0 =C2=A0 * Important: 3 config files in /etc need updating. > =C2=A0 =C2=A0 * Type emerge --help config to learn how to update config= files. >=20 > =C2=A0 =C2=A0 * Important: there are 5 unread news items. > =C2=A0 =C2=A0 * Type emerge --help news to learn how to read news files. >=20 > The unread news message will also be displayed immediately after an > ``emerge sync``. >=20 > Portage may also warn of unread news items using, for example, a red fl= ashy > before actions such as merging a package. >=20 > Portage must keep track of news items which have already been installed= to > avoid repeatedly reinstalling a deleted news item. Why put this in portage at all? Post sync hooks will likely be available = in=20 2.0.54. If adding hooks were as easy as adding a file to a portage config= =20 directory, would adding the package that does the above to the system pac= kage=20 set be enough to force this new information dispersal method on users? > Once a news item is 'installed', third party tools (or a traditional Un= ix > pager and ``rm``) can be used to display and view the news files. An=20 > ``eselect`` [#eselect]_ module shall be created as the 'suggested' disp= lay=20 > tool; other display tools (for example, a news to email forwarder, whic= h=20 > would be ideal for users who sync on a cron) are left as options for th= ose=20 > who desire them -- the simple file format make this relatively simple. This is just more reasoning that nothing should be added to portage at al= l... -- Jason Stubbs --=20 gentoo-dev@gentoo.org mailing list