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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.8 - (show annotations) (download)
Thu Mar 2 00:19:39 2006 UTC (12 years, 11 months ago) by ciaranm
Branch: MAIN
Changes since 1.7: +17 -27 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-2005
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 matches a certain base path
162 (e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3 gentoo-x86``).
164 These extensions are assumed during the following specification.
166 News Item Identities
167 --------------------
169 Each news item will have a unique identifier. This identifier will be in the
170 form ``yyyy-mm-dd-short-name``, where ``yyyy`` is the year (e.g. ``2005``),
171 ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
172 (``01`` through ``31``). The ``short-name`` is a very short name describing the
173 news item (e.g. ``yoursql-updates``), consisting only of the characters ``a-z``,
174 ``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
176 News Item Directories
177 ---------------------
179 Each news item will be represented by a directory whose name is the same as the
180 news item's identifier.
182 The directory will contain a file named ``yyyy-mm-dd-short-name.en.txt``, which
183 contains the text of the news item, in English, in the format described below.
185 If a news item is translated, other files named ``yyyy-mm-dd-short-name.xx.txt``
186 (where ``xx`` is the ISO 639 [#iso-639]_ two letter country code, and the date
187 remains the same as the original news item) will also be provided. However, only
188 the English version of a news item is authoritative. This anglocentricity is
189 justified by precedent [#glep-34]_.
191 News Item Files
192 ---------------
194 A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for
195 compatibility with and for the same reasons as existing Gentoo documentation
196 [#docs-policy]_ and the tree [#glep-31]_.
198 News items must be signed with a detached GPG signature.::
200 gpg --armour --detach-sign ????-??-??-*.??.txt
202 This GLEP does not specify the type or strength of signature to be used, nor
203 does it discuss how, if at all, a centralised keychain will be provided. These
204 issues should be handled as part of the signing policy discussions.
206 A news item file's content will consist of an RFC 822 style header [#rfc-822]_
207 followed by the main body of the message as plain text. This GLEP defines
208 various optional and mandatory headers. Future GLEPs may propose new headers —
209 tools handling these news items must ignore any unrecognised header.
211 News Item Headers
212 '''''''''''''''''
214 The following headers describe the purpose and format of the news item:
216 ``Title:``
217 A short (maximum 44 characters) descriptive title. Mandatory.
219 ``Author:``
220 Author's name and email address, in the form ``Real Name <email@address>``.
221 Mandatory; multiple author headers may be specified if appropriate.
223 ``Translator:``
224 For translated news items, the translator's name and email address. Multiple
225 translator headers may be specified if appropriate.
227 ``Content-Type:``
228 Must be ``text/plain``. Mandatory.
230 ``Posted:``
231 Date of posting, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for
232 compatibility with GLEP 45 [#glep-45]_. Translations should use the date
233 of the original news item. Mandatory.
235 ``Revision:``
236 Initially 1. Should be incremented every time a change is made to the news
237 item. Changes that require a re-read of the news item (i.e., most changes
238 that are not spelling or formatting related) should instead use a new news
239 item. Mandatory.
241 ``News-Item-Format:``
242 Must be ``1.0``. Future revisions to the format may increment the minor
243 number for backwards-compatible changes, or the major number for major
244 changes.
246 The following headers are used for filtering:
248 ``Display-If-Installed:``
249 A dependency atom (for example, ``<dev-lang/php-5_alpha`` or
250 ``net-www/apache``). If the user has the package specified installed from
251 the repository from which the news item was obtained, the news item should
252 be displayed.
254 ``Display-If-Keyword:``
255 A keyword [#glep-22]_ name, for example ``mips`` or ``x86-fbsd``. If the
256 user is on the keyword in question, the news item should be displayed.
258 ``Display-If-Profile:``
259 A profile path, for example ``default-linux/sparc/sparc64/server``. If the
260 user is using the exact profile in question, or a subprofile of this
261 profile, the news item should be displayed. This header may be used to
262 replace ``deprecated`` files in the future.
264 .. Note:: When performing package moves, developers must also update any
265 relevant ``Display-If-Installed`` headers in news files.
267 The algorithm used to determine whether a news item is 'relevant' is as
268 follows:
270 * For each ``Display-If-`` header type which occurs at least once:
272 + The news item is not relevant if none of the headers of this type are
273 successfully matched.
275 * Otherwise the news item is relevant.
277 In particular, if no ``Display-If-`` header is specified, a news item will be
278 relevant for all users.
280 This algorithm was chosen because it makes conditions like "display this news
281 item for ``YourSQL`` users who are on ``sparc`` or ``x86-obsd`` relatively
282 simple to specify — it is believed that these kinds of condition are far more
283 likely to occur than "display this news item for people using ``YourSQL``, or
284 for people on ``sparc`` or ``x86-obsd``\" or "display these news items for
285 people who use ``YourSQL`` and who are on both ``sparc`` and ``x86-obsd``\".
287 News Item Body
288 ''''''''''''''
290 The header section must be followed by a blank line, then the main body of the
291 text.
293 The text body should be wrapped at 72 characters. No fancy formatting or tab
294 characters should be used — the news item may be being displayed directly to a
295 terminal. Paragraphs should be separated by a blank line.
297 Hyperlinks may be used to refer to further information (for example, an upgrade
298 guide). However, the main body of the news item should be descriptive and not
299 simply a "read this link" text. It is assumed that the user will have access to
300 a web browser *somewhere*, but not necessarily on the box which is being
301 administrated — this will be the case on many servers and routers, for example.
303 Example News Item
304 '''''''''''''''''
306 `This hypothetical news item`__ could be used for an upgrade to the
307 ``YourSQL`` database format which breaks forward compatibility.
309 .. __: glep-0042-extras/example-news-item.txt
311 News Item Quality Control
312 -------------------------
314 There have been complaints regarding the comprehensibility of some upgrade
315 notices and news items in the past. This is understandable — not every Gentoo
316 developer speaks English as a first language. However, for the sake of clarity,
317 professionalism and avoiding making us look like prats, it is important that any
318 language problems be corrected before inflicting a news item upon end users.
320 Thus, at least 72 hours before a proposed news item is committed, it must be
321 posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to ``pr@gentoo.org``
322 (exceptions may be made in exceptional circumstances). Any complaints — for
323 example regarding wording, clarity or accuracy — **must** be addressed before
324 the news item goes live.
326 News items must only be for **important** changes that may cause serious upgrade
327 or compatibility problems. Ordinary upgrade messages and non-critical news items
328 should remain in ``einfo`` notices. The importance of the message to its
329 intended audience should be justified with the proposal.
331 .. Important:: The filtering system means that it is appropriate to send out
332 news items which are aimed at users of an uncommon package or architecture.
333 Thus, the justification should be in the form "this message is important to
334 YourSQL users because ...", not "YourSQL is important because ...".
336 News Item Distribution
337 ----------------------
339 Server Side
340 '''''''''''
342 News items are to be made available via the standard rsync tree. This removes
343 any need for polling of a remote source.
345 A new repository will be created for news items. The type (CVS or Subversion),
346 location and access controls on this repository are beyond the scope of this
347 GLEP.
349 .. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86``
350 tree. This was changed following advice from Infrastructure
351 [#ramereth-repo]_. Both solutions have the same end result.
353 This repository will contain directories named ``yyyy/mm/``, where ``yyyy`` is
354 the current year and ``mm`` is the current month number (01 for January through
355 12 for December). This separation will help keep news items more manageable.
357 The contents of this repository will automatically be merged with the main rsync
358 tree, placing the items in a ``metadata/news/`` directory. The method used for
359 merging these items and the frequency at which it will occur is beyond the scope
360 of this GLEP; a similar setup is already used for merging GLSAs into the rsync
361 tree.
363 The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory layout. The
364 news item directories will all be immediately under the ``metadata/news/``
365 directory.
367 Client Side
368 '''''''''''
370 Whenever relevant unread news items are found, the package manager will create a
371 file named ``/var/lib/gentoo/news/news-${repoid}.unread`` (if it does not
372 already exist) and append the news item identifier (eg
373 ``2005-11-01-yoursql-updates``) on a new line.
375 All news item related files should be root owned and in the ``portage`` group
376 with the group write (and, for directories, execute) bits set. News files should
377 be world readable.
379 Notification that new relevant news items will be displayed via the
380 ``emerge`` tool in a similar way to the existing "configuration files need
381 updating" messages:
383 ::
385 * Important: there are 5 unread news items.
386 * Type emerge --help news to learn how to read news files.
388 Checks for new news messages should be displayed:
390 * After an ``emerge sync``
391 * After an ``emerge --pretend``
392 * Before an ``emerge <target>`` (which may also include a red warning message)
394 The package manager does not need to know how to launch the user's choice of
395 news client. This is consistent with the way configuration file updates are
396 handled.
398 The package manager may use a timestamp check file to avoid having to process
399 news items unnecessarily.
401 The package manager must keep track of news items that have already been added
402 to the unread list to avoid repeatedly marking a deleted news item. This could
403 be handled via a ``news-${repoid}.skip`` file containing the IDs of news items
404 that have already been added to a ``news-${repoid}.unread`` file, but this
405 method is not required by this GLEP.
407 Users who really don't care about news items can use ``rsync_excludes`` to
408 filter out the ``metadata/news/`` directory.
410 News Item Clients
411 -----------------
413 Once a news item is marked for reading, third party tools (or traditional core
414 Unix tools) can be used to display and view the news files.
416 When a news item is read, its name should be removed from the
417 ``news-${repoid}.unread`` file. If a news client acts as an interactive reader
418 rather than a gateway, it should then add the name to a ``news-${repoid}.read``
419 file in the same directory with the same file format.
421 An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display
422 tool; other display tools (for example, a news to email forwarder, which would
423 be ideal for users who sync on a ``cron``) are left as options for those who
424 desire them.
426 News Item Removal
427 -----------------
429 News items can be removed (by removing the news file from the main tree) when
430 they are no longer relevant, if they are made obsolete by a future news item or
431 after a long period of time. This is the same as the method used for ``updates``
432 entries.
434 Integration with Existing Systems
435 =================================
437 It would be simple to convert these news items into the format used for news
438 items on the Gentoo website or posts for the ``gentoo-announce`` mailing list.
440 There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the
441 forums. A similar tool can be used for these news items.
443 Backwards Compatibility
444 =======================
446 Backwards compatibility is not a concern here. Existing tools will simply ignore
447 the ``news/`` directory.
449 Reference Implementation
450 ========================
452 TODO
454 Credits
455 =======
457 The idea behind notifying users of news updates via Portage comes from Stuart
458 Herbert [#stuart-blog]_.
460 Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
461 Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec
462 Warner for input. Some of the ideas presented here are theirs, others go
463 completely against their suggestions.
465 Example Files
466 =============
468 `example-news-item.txt <glep-0042-extras/example-news-item.txt>`_
469 An example news item.
471 References
472 ==========
474 .. [#bug-11359] Bugzilla Bug 11359
475 "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
476 https://bugs.gentoo.org/show_bug.cgi?id=11359
477 .. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al.,
478 http://www.gentoo.org/doc/en/xml-guide.xml
479 .. [#eselect] eselect modular framework for configuration and
480 administration utilities,
481 http://www.gentoo.org/proj/en/eselect/index.xml
482 .. [#forums-glsa] Forums user GLSA,
483 http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648
484 .. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy",
485 http://forums.gentoo.org/viewtopic-t-384368.html
486 .. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
487 userlands/kernels/archs", Grant Goodyear,
488 http://www.gentoo.org/proj/en/glep/glep-0022.html
489 .. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
490 McCreesh,
491 http://www.gentoo.org/proj/en/glep/glep-0031.html
492 .. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
493 http://www.gentoo.org/proj/en/glep/glep-0034.html
494 .. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron
495 Walker,
496 http://www.gentoo.org/proj/en/glep/glep-0036.html
497 .. [#glep-45] GLEP 45: "GLEP date format", Henrik Brix Andersen,
498 http://www.gentoo.org/proj/en/glep/glep-0045.html
499 .. [#iso-639] ISO 639 "Code for the representation of names of languages"
500 .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
501 Albertson,
502 http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2
503 .. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages"
504 .. [#rfc-3629] RFC 3629: "UTF-8, a transformation format of ISO 10646"
505 http://www.ietf.org/rfc/rfc3629.txt
506 .. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert,
507 http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism
509 Copyright
510 =========
512 This document has been placed in the public domain.
514 .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

  ViewVC Help
Powered by ViewVC 1.1.20