Contents of /xml/htdocs/proj/en/glep/glep-0042.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.9 - (show annotations) (download)
Mon Mar 6 03:12:08 2006 UTC (9 years, 7 months ago) by ciaranm
Branch: MAIN
Changes since 1.8: +7 -6 lines
File MIME type: text/plain
glep 42 updates

1 GLEP: 42
2 Title: Critical News Reporting
3 Version: $Revision: $
4 Author: Ciaran McCreesh <ciaranm@gentoo.org>
5 Last-Modified: $Date: $
6 Status: Draft
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Created: 31-Oct-2005
10 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2006, 6-Mar-2006
12 Abstract
13 ========
15 This GLEP proposes a new way of informing users about important updates and news
16 related to the tree.
18 Motivation
19 ==========
21 Although most package updates are clean and require little user action,
22 occasionally an upgrade requires user intervention. Recent examples of the
23 latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1``
24 database format changes.
26 There are currently several ways of delivering important news items to our
27 users, none of them particularly effective:
29 * Gentoo Weekly News
30 * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists
31 * The Gentoo Forums
32 * The main Gentoo website
33 * RSS feeds of Gentoo news
34 * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst``
36 A more reliable way of getting news of critical updates out to users is required
37 to avoid repeats of various prior upgrade debacles. This GLEP proposes a
38 solution based around pushing news items out to the user via the ``rsync`` tree.
40 .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages
41 which are displayed post-install. That is a separate issue which is handled
42 by ``elog`` [#bug-11359]_.
44 Requirements
45 ============
47 An adequate solution must meet all of the following requirements:
49 Preemptive
50 Users should be told of changes *before* they break a system, not after the
51 damage has already been done. Ideally, the system administrator would be
52 given ample warning to plan difficult upgrades and changes, rather than only
53 being told just before action is necessary.
55 No user subscription required
56 It has already been demonstrated [#forums-apache2]_ that many users do not
57 read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution that
58 requires subscription has no advantage over current methods.
60 No user monitoring required
61 It has already been demonstrated [#forums-apache2]_ that many users do not
62 read news items posted to the Gentoo website, or do not read news items
63 until it is too late. A solution that relies upon active monitoring of a
64 particular source has no advantage over current methods.
66 Relevant
67 System administrators who do not use a particular package should not have to
68 read news items which affect purely that package. Some news items may be of
69 relevance to most or all users, but those that are not should not be forced
70 upon users unnecessarily.
72 Lightweight
73 It is not reasonable to expect all users to have an MTA, web browser, email
74 client, cron daemon or text processing suite available on their system.
75 Users must not be forced to install unreasonable extra software to be able
76 to read news items.
78 No privacy violations
79 Users of the solution should not be required to provide information about
80 their systems (for example, IP addresses or installed packages).
82 Multiple delivery method support
83 Some users may wish to view news items via email, some via a terminal and
84 some via a web browser. A solution should either support all of these
85 methods or (better still) make it simple to write clients for displaying
86 news items in different ways.
88 The following characteristics would be desirable:
90 Internationalisable
91 Being able to provide messages in multiple languages may be beneficial.
93 Quality control
94 There should be some way to ensure that badly written or irrelevant messages
95 are not sent out, for example by inexperienced developers or those whose
96 English language skills are below par.
98 Simple for developers
99 Posting news items should be as simple as is reasonably possible.
101 Simple for users
102 Reading relevant news items should be as simple as is reasonably possible.
104 Compatibility with existing and future news sources
105 A news system would ideally be able to be integrated with existing news
106 sources (for example, Forums, GWN, the main Gentoo website) without
107 excessive difficulty. Similarly, easy interoperation with any future news
108 sources should not be precluded.
110 Specification
111 =============
113 Overview
114 --------
116 News items are published and delivered to users as follows:
118 1. A news item is written. The format to be used is described below.
120 2. The news item is reviewed, following the process described in
121 `News Item Quality Control`_.
123 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository.
124 From here, it is merged with the rsync tree. This is described in `News Item
125 Distribution`_.
127 4. Users fetch the news item when they sync. This ensures that the news items in
128 question are pushed to the user before the user accidentally makes an
129 unwanted change. No changes to the existing rsync process are required by
130 this GLEP.
132 5. The package manager filters the news item and, if it is relevant, marks the
133 news item for reading. The package manager should also display a notice
134 informing the user that there are unread news items.
136 6. The news item is handled by the user's choice of news item reader. See `News
137 Item Clients`_.
139 Required Portage Enhancements
140 -----------------------------
142 The following extensions to Portage are required:
144 * Every repository (including overlays) will require a unique identifier. It is
145 assumed that an identifier will be a string consisting of characters from
146 ``a`` to ``z``, ``A`` to ``Z``, ``0`` to ``9``, ``+`` (plus), ``-`` (hyphen)
147 ``_`` (underscore).
149 * Portage must provide a way for external programs to obtain a list of all
150 repository identifiers for a given system. It is assumed that this will be in
151 the form of a ``portageq`` command (e.g. ``portageq get_repo_ids``).
153 * Portage must provide a way for external programs to obtain the base path for
154 a repository with a given ID. It is assumed that this will be in the form of
155 a ``portageq`` command (e.g. ``portageq get_repo_root gentoo-x86``).
157 * Portage must extend ``portageq has_version`` to support restrictions to a
158 given repository ID.
160 * Portage must extend ``portageq`` to implement a command which returns whether
161 or not the profile used for a given repository ID is exactly the given profile
162 (e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3
163 gentoo-x86``).
165 These extensions are assumed during the following specification.
167 News Item Identities
168 --------------------
170 Each news item will have a unique identifier. This identifier will be in the
171 form ``yyyy-mm-dd-short-name``, where ``yyyy`` is the year (e.g. ``2005``),
172 ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
173 (``01`` through ``31``). The ``short-name`` is a very short name describing the
174 news item (e.g. ``yoursql-updates``), consisting only of the characters ``a-z``,
175 ``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
177 News Item Directories
178 ---------------------
180 Each news item will be represented by a directory whose name is the same as the
181 news item's identifier.
183 The directory will contain a file named ``yyyy-mm-dd-short-name.en.txt``, which
184 contains the text of the news item, in English, in the format described below.
186 If a news item is translated, other files named ``yyyy-mm-dd-short-name.xx.txt``
187 (where ``xx`` is the ISO 639 [#iso-639]_ two letter country code, and the date
188 remains the same as the original news item) will also be provided. However, only
189 the English version of a news item is authoritative. This anglocentricity is
190 justified by precedent [#glep-34]_.
192 News Item Files
193 ---------------
195 A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for
196 compatibility with and for the same reasons as existing Gentoo documentation
197 [#docs-policy]_ and the tree [#glep-31]_.
199 News items must be signed with a detached GPG signature.::
201 gpg --armour --detach-sign ????-??-??-*.??.txt
203 This GLEP does not specify the type or strength of signature to be used, nor
204 does it discuss how, if at all, a centralised keychain will be provided. These
205 issues should be handled as part of the signing policy discussions.
207 A news item file's content will consist of an RFC 822 style header [#rfc-822]_
208 followed by the main body of the message as plain text. This GLEP defines
209 various optional and mandatory headers. Future GLEPs may propose new headers —
210 tools handling these news items must ignore any unrecognised header.
212 News Item Headers
213 '''''''''''''''''
215 The following headers describe the purpose and format of the news item:
217 ``Title:``
218 A short (maximum 44 characters) descriptive title. Mandatory.
220 ``Author:``
221 Author's name and email address, in the form ``Real Name <email@address>``.
222 Mandatory; multiple author headers may be specified if appropriate.
224 ``Translator:``
225 For translated news items, the translator's name and email address. Multiple
226 translator headers may be specified if appropriate.
228 ``Content-Type:``
229 Must be ``text/plain``. Mandatory.
231 ``Posted:``
232 Date of posting, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
233 compatibility with GLEP 45 [#glep-45]_. Translations should use the date
234 of the original news item. Mandatory.
236 ``Revision:``
237 Initially 1. Should be incremented every time a change is made to the news
238 item. Changes that require a re-read of the news item (i.e., most changes
239 that are not spelling or formatting related) should instead use a new news
240 item. Mandatory.
242 ``News-Item-Format:``
243 Must be ``1.0``. Future revisions to the format may increment the minor
244 number for backwards-compatible changes, or the major number for major
245 changes.
247 The following headers are used for filtering:
249 ``Display-If-Installed:``
250 A dependency atom (for example, ``<dev-lang/php-5_alpha`` or
251 ``net-www/apache``). If the user has the package specified installed from
252 the repository from which the news item was obtained, the news item should
253 be displayed.
255 ``Display-If-Keyword:``
256 A keyword [#glep-22]_ name, for example ``mips`` or ``x86-fbsd``. If the
257 user is on the keyword in question, the news item should be displayed.
259 ``Display-If-Profile:``
260 A profile path, for example ``default-linux/sparc/sparc64/server``. If the
261 user is using the exact profile in question, the news item should be
262 displayed. This header may be used to replace ``deprecated`` files in the
263 future.
265 .. Note:: When performing package moves, developers must also update any
266 relevant ``Display-If-Installed`` headers in news files.
268 The algorithm used to determine whether a news item is 'relevant' is as
269 follows:
271 * For each ``Display-If-`` header type which occurs at least once:
273 + The news item is not relevant if none of the headers of this type are
274 successfully matched.
276 * Otherwise the news item is relevant.
278 In particular, if no ``Display-If-`` header is specified, a news item will be
279 relevant for all users.
281 This algorithm was chosen because it makes conditions like "display this news
282 item for ``YourSQL`` users who are on ``sparc`` or ``x86-obsd`` relatively
283 simple to specify — it is believed that these kinds of condition are far more
284 likely to occur than "display this news item for people using ``YourSQL``, or
285 for people on ``sparc`` or ``x86-obsd``\" or "display these news items for
286 people who use ``YourSQL`` and who are on both ``sparc`` and ``x86-obsd``\".
288 News Item Body
289 ''''''''''''''
291 The header section must be followed by a blank line, then the main body of the
292 text.
294 The text body should be wrapped at 72 characters. No fancy formatting or tab
295 characters should be used — the news item may be being displayed directly to a
296 terminal. Paragraphs should be separated by a blank line.
298 Hyperlinks may be used to refer to further information (for example, an upgrade
299 guide). However, the main body of the news item should be descriptive and not
300 simply a "read this link" text. It is assumed that the user will have access to
301 a web browser *somewhere*, but not necessarily on the box which is being
302 administrated — this will be the case on many servers and routers, for example.
304 Example News Item
305 '''''''''''''''''
307 `This hypothetical news item`__ could be used for an upgrade to the
308 ``YourSQL`` database format which breaks forward compatibility.
310 .. __: glep-0042-extras/example-news-item.txt
312 News Item Quality Control
313 -------------------------
315 There have been complaints regarding the comprehensibility of some upgrade
316 notices and news items in the past. This is understandable — not every Gentoo
317 developer speaks English as a first language. However, for the sake of clarity,
318 professionalism and avoiding making us look like prats, it is important that any
319 language problems be corrected before inflicting a news item upon end users.
321 Thus, at least 72 hours before a proposed news item is committed, it must be
322 posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to ``pr@gentoo.org``
323 (exceptions may be made in exceptional circumstances). Any complaints — for
324 example regarding wording, clarity or accuracy — **must** be addressed before
325 the news item goes live.
327 News items must only be for **important** changes that may cause serious upgrade
328 or compatibility problems. Ordinary upgrade messages and non-critical news items
329 should remain in ``einfo`` notices. The importance of the message to its
330 intended audience should be justified with the proposal.
332 .. Important:: The filtering system means that it is appropriate to send out
333 news items which are aimed at users of an uncommon package or architecture.
334 Thus, the justification should be in the form "this message is important to
335 YourSQL users because ...", not "YourSQL is important because ...".
337 News Item Distribution
338 ----------------------
340 Server Side
341 '''''''''''
343 News items are to be made available via the standard rsync tree. This removes
344 any need for polling of a remote source.
346 A new repository will be created for news items. The type (CVS or Subversion),
347 location and access controls on this repository are beyond the scope of this
348 GLEP.
350 .. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86``
351 tree. This was changed following advice from Infrastructure
352 [#ramereth-repo]_. Both solutions have the same end result.
354 This repository will contain directories named ``yyyy/mm/``, where ``yyyy`` is
355 the current year and ``mm`` is the current month number (01 for January through
356 12 for December). This separation will help keep news items more manageable.
358 The contents of this repository will automatically be merged with the main rsync
359 tree, placing the items in a ``metadata/news/`` directory. The method used for
360 merging these items and the frequency at which it will occur is beyond the scope
361 of this GLEP; a similar setup is already used for merging GLSAs into the rsync
362 tree.
364 The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory layout. The
365 news item directories will all be immediately under the ``metadata/news/``
366 directory.
368 Client Side
369 '''''''''''
371 Whenever relevant unread news items are found, the package manager will create a
372 file named ``/var/lib/gentoo/news/news-${repoid}.unread`` (if it does not
373 already exist) and append the news item identifier (eg
374 ``2005-11-01-yoursql-updates``) on a new line.
376 All news item related files should be root owned and in the ``portage`` group
377 with the group write (and, for directories, execute) bits set. News files should
378 be world readable.
380 Notification that new relevant news items will be displayed via the
381 ``emerge`` tool in a similar way to the existing "configuration files need
382 updating" messages:
384 ::
386 * Important: there are 5 unread news items.
387 * Type emerge --help news to learn how to read news files.
389 Checks for new news messages should be displayed:
391 * After an ``emerge sync``
392 * After an ``emerge --pretend``
393 * Before an ``emerge <target>`` (which may also include a red warning message)
395 The package manager does not need to know how to launch the user's choice of
396 news client. This is consistent with the way configuration file updates are
397 handled.
399 The package manager may use a timestamp check file to avoid having to process
400 news items unnecessarily.
402 The package manager must keep track of news items that have already been added
403 to the unread list to avoid repeatedly marking a deleted news item. This could
404 be handled via a ``news-${repoid}.skip`` file containing the IDs of news items
405 that have already been added to a ``news-${repoid}.unread`` file, but this
406 method is not required by this GLEP.
408 Users who really don't care about news items can use ``rsync_excludes`` to
409 filter out the ``metadata/news/`` directory.
411 News Item Clients
412 -----------------
414 Once a news item is marked for reading, third party tools (or traditional core
415 Unix tools) can be used to display and view the news files.
417 When a news item is read, its name should be removed from the
418 ``news-${repoid}.unread`` file. If a news client acts as an interactive reader
419 rather than a gateway, it should then add the name to a ``news-${repoid}.read``
420 file in the same directory with the same file format.
422 An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display
423 tool; other display tools (for example, a news to email forwarder, which would
424 be ideal for users who sync on a ``cron``) are left as options for those who
425 desire them.
427 News Item Removal
428 -----------------
430 News items can be removed (by removing the news file from the main tree) when
431 they are no longer relevant, if they are made obsolete by a future news item or
432 after a long period of time. This is the same as the method used for ``updates``
433 entries.
435 Integration with Existing Systems
436 =================================
438 It would be simple to convert these news items into the format used for news
439 items on the Gentoo website or posts for the ``gentoo-announce`` mailing list.
441 There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the
442 forums. A similar tool can be used for these news items.
444 Backwards Compatibility
445 =======================
447 Backwards compatibility is not a concern here. Existing tools will simply ignore
448 the ``news/`` directory.
450 Reference Implementation
451 ========================
453 TODO
455 Credits
456 =======
458 The idea behind notifying users of news updates via Portage comes from Stuart
459 Herbert [#stuart-blog]_.
461 Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
462 Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec
463 Warner for input. Some of the ideas presented here are theirs, others go
464 completely against their suggestions.
466 Example Files
467 =============
469 `example-news-item.txt <glep-0042-extras/example-news-item.txt>`_
470 An example news item.
472 References
473 ==========
475 .. [#bug-11359] Bugzilla Bug 11359
476 "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
477 https://bugs.gentoo.org/show_bug.cgi?id=11359
478 .. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al.,
479 http://www.gentoo.org/doc/en/xml-guide.xml
480 .. [#eselect] eselect modular framework for configuration and
481 administration utilities,
482 http://www.gentoo.org/proj/en/eselect/index.xml
483 .. [#forums-glsa] Forums user GLSA,
484 http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648
485 .. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy",
486 http://forums.gentoo.org/viewtopic-t-384368.html
487 .. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
488 userlands/kernels/archs", Grant Goodyear,
489 http://www.gentoo.org/proj/en/glep/glep-0022.html
490 .. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
491 McCreesh,
492 http://www.gentoo.org/proj/en/glep/glep-0031.html
493 .. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
494 http://www.gentoo.org/proj/en/glep/glep-0034.html
495 .. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron
496 Walker,
497 http://www.gentoo.org/proj/en/glep/glep-0036.html
498 .. [#glep-45] GLEP 45: "GLEP date format", Henrik Brix Andersen,
499 http://www.gentoo.org/proj/en/glep/glep-0045.html
500 .. [#iso-639] ISO 639 "Code for the representation of names of languages"
501 .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
502 Albertson,
503 http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2
504 .. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages"
505 .. [#rfc-3629] RFC 3629: "UTF-8, a transformation format of ISO 10646"
506 http://www.ietf.org/rfc/rfc3629.txt
507 .. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert,
508 http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism
510 Copyright
511 =========
513 This document has been placed in the public domain.
515 .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

  ViewVC Help
Powered by ViewVC 1.1.20