GLEP: XX Title: Critical News Reporting Version: $Revision: $ Author: Ciaran McCreesh Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-October-2005 Post-Date: 1-November-2005 Abstract ======== This GLEP proposes a new way of informing users of important updates and news regarding tree-related items. Motivation ========== There are currently several ways of getting news out to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce`` mailing list * The Gentoo Forums * The main Gentoo website A more reliable way of getting news of critical updates out to users is required to avoid repeats of the various recent upgrade debacles. Requirements ============ An adequate solution must meet all of the following requirements: Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. In particular, this means that any markup to be parsed must be in a very simple format. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. No user subscription required It has already been demonstrated [#forums-whining]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-whining]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Preemptive Users should be told of changes *before* they break the user's system, not after the damage has already been done. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers, those whose English language skills are below par or morons. Simple for developers Posting news items should be as simple as is reasonably possible. Simple for users Reading relevant news items should be as simple as is reasonably possible. Compatibility with existing news sources It would be ideal if a news system could easily be integrated with the existing communication methods. Specification ============= The following specification is based upon Stuart's "Favouring an automatic news mechanism" post [#stuart-blog]_ and discussion on the ``gentoo-dev`` mailing lists [#dev-thread]_ and the ``#gentoo-dev`` IRC channel. News Item Source ---------------- News items are to be made available via the Portage tree. This removes any need for polling of a remote source. A new directory, ``news/``, will be created in the main tree. Commit access to this directory will be handled in the same way as for the rest of the tree. This directory will contain further subdirectories named ``yyyy-mm/``, where ``yyyy`` is the current year and ``mm`` is the current month number (01 for January through 12 for December) -- this extra level of separation will help keep news items more manageable. Users who really don't care about news items can use ``rsync_excludes`` to filter out the ``news/`` directory. .. Note:: The ``profiles/`` directory will *not* be used. This fits in with the Portage team's future plans for ``profiles/`` and ``metadata/`` separation. Each news item will be represented by a single text file. This file will be encoded using UTF-8 for compatibility with and for the same reason as existing Gentoo documentation [#docs-policy]_ and tree [#glep-31]_ practices. The news item will be named in the form ``yyyy-mm-dd-item-name.en.txt``, where ``item-name`` is a very short name (e.g. ``apache-updates``) and ``en`` is the two letter ISO 639 [#iso-639]_ language code for the news item. The directory and file name rules are designed specifically to allow easy sorting by date. An English (``en``) version must be available for all news items. Other languages may be provided either by the original author or by other translators who have commit access. This anglocentricity is justified on the grounds that nobody objected to it with GLEP 34 [#glep-34]_. News Item File Format --------------------- A news item will consist of an RFC 822 [#rfc-822]_ style header followed by the main body of the message as plain text. This GLEP defines various optional and mandatory headers. Future GLEPs may propose new headers -- tools handling these news items must discard any unrecognised header. News Item Metadata Headers '''''''''''''''''''''''''' ``Title:`` A short (maximum 44 characters) descriptive title. Mandatory. ``Author:`` Author's name and email address, in the form ``Real Name ``. Mandatory, multiple author fields may be specified if appropriate. ``Translator:`` For translated news items, the translator's name and email address. ``Content-Type:`` Must be ``text/plain``. Mandatory. ``Posted:`` Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). Mandatory. ``Version:`` Initially 1. Incremented every time a non-trivial change is made. Changes which require a re-read of the news item should instead use a new news item file. News Item Relevance Headers ''''''''''''''''''''''''''' If none of the following headers are specified, the news item is aimed at all users. Otherwise, the news item should only be displayed if at least one of the criteria matches. ``Display-If-Installed:`` A dependency atom or simple package name (for example, `` Content-Type: text/plain Posted: 01-Nov-2005 Display-If-Installed: