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.54) id 1FG6BH-0005wr-FV for garchives@archives.gentoo.org; Mon, 06 Mar 2006 03:14:44 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k263Ds56011505; Mon, 6 Mar 2006 03:13:54 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 k263BxqD010313 for ; Mon, 6 Mar 2006 03:12:00 GMT Received: from [213.121.151.206] (helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1FG68X-0003XE-SQ; Mon, 06 Mar 2006 03:11:55 +0000 Received: from localhost ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1FG68V-0005eO-My; Mon, 06 Mar 2006 03:11:51 +0000 Date: Mon, 6 Mar 2006 03:11:47 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Cc: glep@gentoo.org Subject: Re: [gentoo-dev] glep 0042 (news) final draft Message-ID: <20060306031147.3da01ce6@snowdrop.home> In-Reply-To: <20060302001947.6b490856@snowdrop.home> References: <20060302001947.6b490856@snowdrop.home> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.12; i686-pc-linux-gnu) 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: multipart/signed; boundary="Sig_ID_n.9bfm2/fJnkfMkc5TKl"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 80fd45a2-f4b5-4af0-917c-c24ab3c593d5 X-Archives-Hash: 90d333b074e0e7d842e9231e43b13eb1 --Sig_ID_n.9bfm2/fJnkfMkc5TKl Content-Type: multipart/mixed; boundary=MP_uHvCoB669ggYR3I7Iin4Ta1 --MP_uHvCoB669ggYR3I7Iin4Ta1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 2 Mar 2006 00:19:47 +0000 Ciaran McCreesh wrote: | Attached is the final draft. And now, attached is the final final draft. The only change in this version is to the behaviour of Display-If-Profile / `portageq profile_used` -- now, an exact profile equivalence is used. --=20 Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --MP_uHvCoB669ggYR3I7Iin4Ta1 Content-Type: text/plain; name=glep-0042.txt Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=glep-0042.txt GLEP: 42 Title: Critical News Reporting Version: $Revision: $ Author: Ciaran McCreesh Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 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 Abstract =3D=3D=3D=3D=3D=3D=3D=3D This GLEP proposes a new way of informing users about important updates and= news related to the tree. Motivation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1= `` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst`` A more reliable way of getting news of critical updates out to users is req= uired to avoid repeats of various prior upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` = tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messa= ges which are displayed post-install. That is a separate issue which is hand= led by ``elog`` [#bug-11359]_. Requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An adequate solution must meet all of the following requirements: Preemptive Users should be told of changes *before* they break a system, not after= the damage has already been done. Ideally, the system administrator would be given ample warning to plan difficult upgrades and changes, rather than= only being told just before action is necessary. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do = not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution = that requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ 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. Relevant System administrators who do not use a particular package should not ha= ve to read news items which affect purely that package. Some news items may b= e of relevance to most or all users, but those that are not should not be fo= rced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, e= mail client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be a= ble to read news items. No privacy violations Users of the solution should not be required to provide information abo= ut their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal a= nd some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. 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 mes= sages are not sent out, for example by inexperienced developers or those whose English language skills are below par. 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 possib= le. Compatibility with existing and future news sources A news system would ideally be able to be integrated with existing news sources (for example, Forums, GWN, the main Gentoo website) without excessive difficulty. Similarly, easy interoperation with any future ne= ws sources should not be precluded. Specification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Overview -------- News items are published and delivered to users as follows: 1. A news item is written. The format to be used is described below. 2. The news item is reviewed, following the process described in `News Item Quality Control`_. 3. The news item is committed to a CVS (or Subversion [#glep-36]_) reposito= ry. From here, it is merged with the rsync tree. This is described in `News = Item Distribution`_. 4. Users fetch the news item when they sync. This ensures that the news ite= ms in question are pushed to the user before the user accidentally makes an unwanted change. No changes to the existing rsync process are required by this GLEP. 5. The package manager filters the news item and, if it is relevant, marks = the news item for reading. The package manager should also display a notice informing the user that there are unread news items. 6. The news item is handled by the user's choice of news item reader. See `= News Item Clients`_. Required Portage Enhancements ----------------------------- The following extensions to Portage are required: * Every repository (including overlays) will require a unique identifier. I= t is assumed that an identifier will be a string consisting of characters from ``a`` to ``z``, ``A`` to ``Z``, ``0`` to ``9``, ``+`` (plus), ``-`` (hyph= en) ``_`` (underscore). * Portage must provide a way for external programs to obtain a list of all repository identifiers for a given system. It is assumed that this will b= e in the form of a ``portageq`` command (e.g. ``portageq get_repo_ids``). * Portage must provide a way for external programs to obtain the base path = for a repository with a given ID. It is assumed that this will be in the form= of a ``portageq`` command (e.g. ``portageq get_repo_root gentoo-x86``). * Portage must extend ``portageq has_version`` to support restrictions to a given repository ID. * Portage must extend ``portageq`` to implement a command which returns whe= ther or not the profile used for a given repository ID is exactly the given pr= ofile (e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3 gentoo-x86``). These extensions are assumed during the following specification. News Item Identities -------------------- Each news item will have a unique identifier. This identifier will be in the form ``yyyy-mm-dd-short-name``, where ``yyyy`` is the year (e.g. ``2005``), ``mm`` is the month (``01`` through ``12``) and dd is the day of the month (``01`` through ``31``). The ``short-name`` is a very short name describing= the news item (e.g. ``yoursql-updates``), consisting only of the characters ``a= -z``, ``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). News Item Directories --------------------- Each news item will be represented by a directory whose name is the same as= the news item's identifier. The directory will contain a file named ``yyyy-mm-dd-short-name.en.txt``, w= hich contains the text of the news item, in English, in the format described bel= ow. If a news item is translated, other files named ``yyyy-mm-dd-short-name.xx.= txt`` (where ``xx`` is the ISO 639 [#iso-639]_ two letter country code, and the d= ate remains the same as the original news item) will also be provided. However,= only the English version of a news item is authoritative. This anglocentricity = is justified by precedent [#glep-34]_. News Item Files --------------- A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for compatibility with and for the same reasons as existing Gentoo documentation [#docs-policy]_ and the tree [#glep-31]_. News items must be signed with a detached GPG signature.:: gpg --armour --detach-sign ????-??-??-*.??.txt This GLEP does not specify the type or strength of signature to be used, nor does it discuss how, if at all, a centralised keychain will be provided. Th= ese issues should be handled as part of the signing policy discussions. A news item file's content will consist of an RFC 822 style header [#rfc-82= 2]_ followed by the main body of the message as plain text. This GLEP defines various optional and mandatory headers. Future GLEPs may propose new header= s =E2=80=94 tools handling these news items must ignore any unrecognised header. News Item Headers ''''''''''''''''' The following headers describe the purpose and format of the news item: ``Title:`` A short (maximum 44 characters) descriptive title. Mandatory. ``Author:`` Author's name and email address, in the form ``Real Name ``. Mandatory; multiple author headers may be specified if appropriate. ``Translator:`` For translated news items, the translator's name and email address. Mul= tiple translator headers may be specified if appropriate. ``Content-Type:`` Must be ``text/plain``. Mandatory. ``Posted:`` Date of posting, in ``yyyy-mm-dd`` format (e.g. 2005-12-18) for compatibility with GLEP 45 [#glep-45]_. Translations should use the date of the original news item. Mandatory. ``Revision:`` Initially 1. Should be incremented every time a change is made to the n= ews item. Changes that require a re-read of the news item (i.e., most chang= es that are not spelling or formatting related) should instead use a new n= ews item. Mandatory. ``News-Item-Format:`` Must be ``1.0``. Future revisions to the format may increment the minor number for backwards-compatible changes, or the major number for major changes. The following headers are used for filtering: ``Display-If-Installed:`` A dependency atom (for example, ```` (which may also include a red warning messa= ge) The package manager does not need to know how to launch the user's choice of news client. This is consistent with the way configuration file updates are handled. The package manager may use a timestamp check file to avoid having to proce= ss news items unnecessarily. The package manager must keep track of news items that have already been ad= ded to the unread list to avoid repeatedly marking a deleted news item. This co= uld be handled via a ``news-${repoid}.skip`` file containing the IDs of news it= ems that have already been added to a ``news-${repoid}.unread`` file, but this method is not required by this GLEP. Users who really don't care about news items can use ``rsync_excludes`` to filter out the ``metadata/news/`` directory. News Item Clients ----------------- Once a news item is marked for reading, third party tools (or traditional c= ore Unix tools) can be used to display and view the news files. When a news item is read, its name should be removed from the ``news-${repoid}.unread`` file. If a news client acts as an interactive rea= der rather than a gateway, it should then add the name to a ``news-${repoid}.re= ad`` file in the same directory with the same file format. An ``eselect`` [#eselect]_ module shall be created as the 'suggested' displ= ay tool; other display tools (for example, a news to email forwarder, which wo= uld be ideal for users who sync on a ``cron``) are left as options for those who desire them. News Item Removal ----------------- News items can be removed (by removing the news file from the main tree) wh= en they are no longer relevant, if they are made obsolete by a future news ite= m or after a long period of time. This is the same as the method used for ``upda= tes`` entries. Integration with Existing Systems =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D It would be simple to convert these news items into the format used for news items on the Gentoo website or posts for the ``gentoo-announce`` mailing li= st. There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the forums. A similar tool can be used for these news items. Backwards Compatibility =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Backwards compatibility is not a concern here. Existing tools will simply i= gnore the ``news/`` directory. Reference Implementation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TODO Credits =3D=3D=3D=3D=3D=3D=3D The idea behind notifying users of news updates via Portage comes from Stua= rt Herbert [#stuart-blog]_. Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear, Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and = Alec Warner for input. Some of the ideas presented here are theirs, others go completely against their suggestions. Example Files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `example-news-item.txt `_ An example news item. References =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D .. [#bug-11359] Bugzilla Bug 11359 "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging", https://bugs.gentoo.org/show_bug.cgi?id=3D11359 .. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al., http://www.gentoo.org/doc/en/xml-guide.xml .. [#eselect] eselect modular framework for configuration and administration utilities, http://www.gentoo.org/proj/en/eselect/index.xml .. [#forums-glsa] Forums user GLSA, http://forums.gentoo.org/profile.php?mode=3Dviewprofile&u=3D55648 .. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy", http://forums.gentoo.org/viewtopic-t-384368.html .. [#glep-22] GLEP 22: "New "keyword" system to incorporate various userlands/kernels/archs", Grant Goodyear, http://www.gentoo.org/proj/en/glep/glep-0022.html .. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran McCreesh, http://www.gentoo.org/proj/en/glep/glep-0031.html .. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh, http://www.gentoo.org/proj/en/glep/glep-0034.html .. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron Walker, http://www.gentoo.org/proj/en/glep/glep-0036.html .. [#glep-45] GLEP 45: "GLEP date format", Henrik Brix Andersen, http://www.gentoo.org/proj/en/glep/glep-0045.html .. [#iso-639] ISO 639 "Code for the representation of names of languages" .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", La= nce Albertson, http://marc.theaimsgroup.com/?l=3Dgentoo-dev&m=3D113111585907703&w=3D2 .. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messag= es" .. [#rfc-3629] RFC 3629: "UTF-8, a transformation format of ISO 10646" http://www.ietf.org/rfc/rfc3629.txt .. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert, http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic= _news_mechanism Copyright =3D=3D=3D=3D=3D=3D=3D=3D=3D This document has been placed in the public domain. .. vim: set tw=3D80 fileencoding=3Dutf-8 spell spelllang=3Den et : --MP_uHvCoB669ggYR3I7Iin4Ta1-- --Sig_ID_n.9bfm2/fJnkfMkc5TKl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEC6h396zL6DUtXhERAo4zAJ9Vb2P2xHV9lyiuJvIRFxqgEF+zdQCgz25P YA89cqh8KIAhebdYOLROYjY= =xd3q -----END PGP SIGNATURE----- --Sig_ID_n.9bfm2/fJnkfMkc5TKl-- -- gentoo-dev@gentoo.org mailing list