[gentoo-dev] GLEP 42 (Critical News Reporting) round five

[gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 800 bytes --]

Ok, new draft. Changes are as follows:

* mysql-4.1, not -5.

* Added einfo, ewarn to the list of methods currently used

* Added + and : to the allowed news item IDs, to match package name
policy (Kugelfang thought we might need, say, a libstdc++ news item at
some point)

* Changed /var/lib/portage to /var/lib/gentoo

* The news file is now named 'news-magic-chicken.*'. News clients are
to use a wildcard rather than hardcoding magic-chicken.

* Added emerge --ask thingie

* news.read is now mandatory for interactive clients, and ignored for
gateway clients

Read the whole thing before commenting please.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #1.2: glep-0042.txt --]
[-- Type: text/plain, Size: 20473 bytes --]

GLEP: 42
Title: Critical News Reporting
Version: $Revision: $
Author: Ciaran McCreesh <ciaranm@gentoo.org>
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

Abstract
========

This GLEP proposes a new way of informing users about important updates and news
regarding tree-related items.

Motivation
==========

Although most package updates are clean and require little user action,
occasionally an upgrade requires user intervention during the upgrade process.
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 required
to avoid repeats of the various recent 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`` messages
   which are displayed post-install. That is a separate issue which is handled
   by ``elog`` [#bug-11359]_.

Requirements
============

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 which
    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 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.

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.
    Users must not be forced to install unreasonable extra software to be able
    to read news items.

No privacy violations
    Users of the solution should not be required to provide information about
    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 and
    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 messages
    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 possible.

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 news
    sources should not be precluded.

Specification
=============

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]_) repository.
   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 items 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`_.

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), ``:`` (colon) and ``-`` (hyphen).

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``, which
contains the text of the news item, in English, in the format described below.

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) 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 should be signed with a detached GPG signature: ::

    gpg --armour --detach-sign ????-??-??-*.??.txt

A news item file's content will consist of an RFC 822 style header [#rfc-822]_
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 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 <email@address>``.
    Mandatory; multiple author headers may be specified if appropriate.

``Translator:``
    For translated news items, the translator's name and email address. Multiple
    translator headers may be specified if appropriate.

``Content-Type:``
    Must be ``text/plain``. Mandatory.

``Posted:``
    Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001) for
    compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss +0000`` format
    may also be included. Mandatory.

``Revision:``
    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. 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 or simple package name (for example,
    ``<dev-lang/php-5_alpha`` or ``net-www/apache``). If the user has the
    package specified installed, the news item should be displayed.

``Display-If-Keyword:``
    A keyword [#glep-22]_ name, for example ``mips`` or ``x86-fbsd``. If the
    user is on the keyword in question, the news item should be displayed.

``Display-If-Profile:``
    A profile path, for example ``default-linux/sparc/sparc64/server``. Standard
    shell GLOB wildcards may be used. If the user is using the exact profile in
    question, the news item should be displayed. This header may be used to
    replace ``deprecated`` files in the future.

.. Note:: When performing package moves, developers must also update any
   relevant ``Display-If-Installed`` headers in news files.

The algorithm used to determine whether a news item is 'relevant' is as
follows:

* For each ``Display-If-`` header type which occurs at least once:

  + The news item is not relevant if none of the headers of this type are
    successfully matched.

* Otherwise the news item is relevant.

In particular, if no ``Display-If-`` header is specified, a news item will be
relevant for all users.

This algorithm was chosen because it makes conditions like "display this news
item for ``YourSQL`` users who are on ``sparc`` or ``x86-obsd`` relatively
simple to specify — it is believed that these kinds of condition are far more
likely to occur than "display this news item for people using ``YourSQL``, or
for people on ``sparc`` or ``x86-obsd``\" or "display these news items for
people who use ``YourSQL`` and who are on both ``sparc`` and ``x86-obsd``\".

News Item Body
''''''''''''''

The header section must be followed by a blank line, then the main body of the
text.

The text body should be wrapped at 72 characters. No fancy formatting or tab
characters should be used — the news item may be being displayed directly to a
terminal. Paragraphs should be separated by a blank line.

Hyperlinks may be used to refer to further information (for example, an upgrade
guide). However, the main body of the news item should be descriptive and not
simply a "read this link" text. It is assumed that the user will have access to
a web browser *somewhere*, but not necessarily on the box which is being
administrated — this will be the case on may servers and routers, for example.

Example News Item
'''''''''''''''''

`This hypothetical news item`__ could be used for an upgrade to the
``YourSQL`` database format which breaks forward compatibility.

.. __: glep-0042-extras/example-news-item.txt

News Item Quality Control
-------------------------

There have been complaints regarding the comprehensibility of some upgrade
notices and news items in the past. This is understandable — not every Gentoo
developer speaks English as a first language. However, for the sake of clarity,
professionalism and avoiding making us look like prats, it is important that any
language problems be corrected before inflicting a news item upon end users.

Thus, at least 72 hours before a proposed news item is committed, it must be
posted to the ``gentoo-dev`` mailing list and ``Cc:``\ed to ``pr@gentoo.org``
(exceptions may be made in exceptional circumstances). Any complaints — for
example regarding wording, clarity or accuracy — **must** be addressed before
the news item goes live.

.. Note:: A previous draft of this GLEP allowed news items to be sent to
   ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation
   may arise where this will be necessary (for example, a security update which
   must break backwards compatibility and which cannot be revealed to the public
   before a given date).

News items must only be for **important** changes that may cause serious upgrade
or compatibility problems. Ordinary upgrade messages and non-critical news items
should remain in ``einfo`` notices. The importance of the message to its
intended audience should be justified with the proposal.

.. Important:: The filtering system means that it is appropriate to send out
   news items which are aimed at users of an uncommon package or architecture.
   Thus, the justification should be in the form "this message is important to
   YourSQL users because ...", not "YourSQL is important because ...".

News Item Distribution
----------------------

Server Side
'''''''''''

News items are to be made available via the standard rsync tree. This removes
any need for polling of a remote source.

A new repository will be created for news items. The type (CVS or Subversion),
location and access controls on this repository are beyond the scope of this
GLEP.

.. Note:: A previous draft of this GLEP instead used the main ``gentoo-x86``
   tree. This was changed following advice from Infrastructure
   [#ramereth-repo]_. Both solutions have the same end result.

This repository will contain directories named ``yyyy/mm/``, where ``yyyy`` is
the current year and ``mm`` is the current month number (01 for January through
12 for December). This separation will help keep news items more manageable.

The contents of this repository will automatically be merged with the main rsync
tree, placing the items in a ``metadata/news/`` directory. The method used for
merging these items is beyond the scope of this GLEP — a similar setup is
already used for merging GLSAs into the rsync tree.

The main rsync tree will **not** use the ``yyyy/mm/`` subdirectory layout.

Client Side
'''''''''''

Whenever relevant unread news items are found, the package manager will create a
file named ``/var/lib/gentoo/news/news-magic-chicken.unread`` (if it does not
already exist) and append the news item identifier (eg
``2005-11-01-yoursql-updates``) on a new line.

.. Note:: Future changes to Portage involving support for multiple repositories
   may introduce repository names. In this case, the ``magic-chicken`` part of the
   filename should be replaced by a string representation of the repository
   name. Thus, news item clients should use a wildcard rather than hardcoding
   the ``magic-chicken`` string.

Notification that new relevant news items will be displayed via the
``emerge`` tool in a similar way to the existing "configuration files need
updating" messages:

::

    * Important: there are 5 unread news items.
    * Type emerge --help news to learn how to read news files.

Checks for new news messages should be displayed:

* After an ``emerge sync``
* After an ``emerge --pretend``
* Before an ``emerge <target>`` (which may also include a red warning message)
* Before an ``emerge --ask <target>`` sequence

The package manager may use a timestamp check file to avoid having to process
news items unnecessarily.

The package manager must keep track of news items that have already been added
to the unread list to avoid repeatedly marking a deleted news item. This could
be handled via a ``news-magic-chicken.skip`` file, but implementation is not
specified 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 core
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-magic-chicken.unread`` file. If a news client acts as an interactive
reader rather than a gateway, it should then add the name to a
``news-magic-chicken.read`` file in the same directory with the same file
format (again, ``magic-chicken`` should be a wildcard rather than hardcoded).

An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display
tool; other display tools (for example, a news to email forwarder, which would
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) when
they are no longer relevant, if they are made obsolete by a future news item or
after a long period of time. This is the same as the method used for ``updates``
entries.

Integration with Existing Systems
=================================

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 list.

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
=======================

Backwards compatibility is not a concern here. Existing tools will simply ignore
the ``news/`` directory.

Reference Implementation
========================

Portage Code
------------

TODO

Simple ``eselect`` News Client
------------------------------

TODO Removed until the exact format details are figured out.

Simple News to Mail Forwarder
-----------------------------

TODO Removed until the exact format details are figured out.

Credits
=======

The idea behind notifying users of news updates via Portage comes from Stuart
Herbert [#stuart-blog]_.

Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
Brian Harring, 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
=============

TODO Removed until the exact format details are figured out.

References
==========

.. [#bug-11359] Bugzilla Bug 11359
   "[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
   https://bugs.gentoo.org/show_bug.cgi?id=11359
.. [#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=viewprofile&u=55648
.. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy",
     http://forums.gentoo.org/viewtopic-t-384368.html
.. [#glep-1] GLEP 1: "GLEP Purpose and Guidelines", Grant Goodyear,
     http://www.gentoo.org/proj/en/glep/glep-0001.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
.. [#iso-639] ISO 639 "Code for the representation of names of languages"
.. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
     Albertson,
     http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2
.. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages"
.. [#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
=========

This document has been placed in the public domain.

.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five

[Dan Meltzer]

>Internationalisable
>   Being able to provide messages in multiple languages may be beneficial.

Not quite sure, is it required for GLEP's to be in american English or
is UK English fine?

Pointing at Internationalizable

On 12/12/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> Ok, new draft. Changes are as follows:
>
> * mysql-4.1, not -5.
>
> * Added einfo, ewarn to the list of methods currently used
>
> * Added + and : to the allowed news item IDs, to match package name
> policy (Kugelfang thought we might need, say, a libstdc++ news item at
> some point)
>
> * Changed /var/lib/portage to /var/lib/gentoo
>
> * The news file is now named 'news-magic-chicken.*'. News clients are
> to use a wildcard rather than hardcoding magic-chicken.
>
> * Added emerge --ask thingie
>
> * news.read is now mandatory for interactive clients, and ignored for
> gateway clients
>
> Read the whole thing before commenting please.
>
> --
> Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| >Internationalisable
| >   Being able to provide messages in multiple languages may be
| > beneficial.
| 
| Not quite sure, is it required for GLEP's to be in american English or
| is UK English fine?
| 
| Pointing at Internationalizable

The standard for Gentoo documentation is to use whichever variant the
original author prefers.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five

[Dan Meltzer]

Alrighty then, good enough for me :)

One other thing
> .. Note:: A previous draft of this GLEP allowed news items to be sent to
>   ``gentoo-core`` instead of ``gentoo-dev``. It is possible that a situation
>   may arise where this will be necessary (for example, a security update which
>   must break backwards compatibility and which cannot be revealed to the public
>  before a given date).

The seems like a half complete thought, I realize you want to
discourage it from happening, but maybe change it to read "It is
possible that a situation.... and in only this case may it be sent to
-core instead"

On 12/12/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Mon, 12 Dec 2005 22:30:52 -0500 Dan Meltzer
> <parallelgrapefruit@gmail.com> wrote:
> | >Internationalisable
> | >   Being able to provide messages in multiple languages may be
> | > beneficial.
> |
> | Not quite sure, is it required for GLEP's to be in american English or
> | is UK English fine?
> |
> | Pointing at Internationalizable
>
> The standard for Gentoo documentation is to use whichever variant the
> original author prefers.
>
> --
> Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Andrew Muraco]

Ciaran McCreesh wrote:

>Ok, new draft. Changes are as follows:
>
I Think That You've tweaked this GLEP to death ;-)
Anyways, I can't wait until everybody is happy with it and it gets 
moving, because I know that gcc 4 and qt4 and glibc 2.3.6 are right 
around the corner, and those would be great chances to use this new news 
dohicker and see how it goes.

Thanks for the continuous hard work on this,

Andrew
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Mon, 12 Dec 2005 23:25:29 -0500 Andrew Muraco <tuxp3@leetworks.com>
wrote:
| Ciaran McCreesh wrote:
| >Ok, new draft. Changes are as follows:
| >
| I Think That You've tweaked this GLEP to death ;-)

Sadly not. It still needs work. It's going to take at least a couple
more drafts before I'd be happy sticking it up for voting... Complex
changes need thorough planning. Otherwise we just end up wasting lots
of time implementing something that doesn't work, and then lots more
time trying to fix bugs in something that's broken by design, and then
even more time supporting the legacy brokenness whenever it finally is
done properly.

I'd much rather throw away a design than throw away code. 

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five

[Duncan]

Ciaran McCreesh posted <20051213032043.55a6e40f@snowdrop.home>, excerpted
below,  on Tue, 13 Dec 2005 03:20:43 +0000:

> Ok, new draft. Changes are as follows:
[]
> * Changed /var/lib/portage to /var/lib/gentoo

OK, I must have missed the reason for that, and it isn't listed in one of
your "a previous version" notes, unless I missed that too. <g>

Assuming the reason wasn't contrary to this (which it probably is,
but...), why not /var/lib/portage/news/gentoo?  If I read jstubbs'
suggestion correctly, the "gentoo" would then serve as the repo name (in
place of magic-chicken, altho as he proposed it, that would be part of the
filename, not the directory the file is in) as well -- he said naming the
current/default repo "gentoo" was sufficient.

> * Added emerge --ask thingie

> Checks for new news messages should be displayed:
[]
> * After an ``emerge --pretend``
[]
> * Before an ``emerge --ask <target>`` sequence

Wouldn't it be less confusing if the news warning appeared in the same
place, relative to the package listing, in both of these?  Isn't an emerge
--ask just the output of pretend, with a confirmation pinned to the end? 
Shouldn't it continue to be that, at least in concept?

> * news.read is now mandatory for interactive clients, and ignored for
> gateway clients

> When a news item is read, its name should be removed from the
> ``news-magic-chicken.unread`` file. If a news client acts as an
> interactive reader rather than a gateway, it should then add the name to
> a ``news-magic-chicken.read`` file in the same directory with the same
> file format (again, ``magic-chicken`` should be a wildcard rather than
> hardcoded).

First, the change outline doesn't state what the result actually was, in
the GLEP. Mandatory would require a MUST (or a similar statement that it's
mandatory), while the GLEP words it as a SHOULD.  Or is "should" not to be
taken in the usual RFC meaning, but rather as an RFC "MUST"?

Second but related, the first time I read thru it, I somehow missed the
"rather than a gateway" part.  Upon rereading, I saw it (obviously), but
the effect of the present wording is to deemphasize the "gateway" clause,
as well as the "read" file.  If it's truly a MUST, then the "read" file
deserves equal treatment with the "unread" file, probably by introducing
the two as a pair, then treating them in parallel thru most of the other
references.

(IOW, the read file and its requirement for interactive clients currently
appears to be the afterthought it in fact was, without that fact
being recognized, which doesn't particularly positively impress,
quality-wise.)

Third, recall from the discussion of an earlier draft, someone mentioned
the multiple meaning of read (as here) vs. "read" (as in README).  The
suggestion to avoid that ambiguity was "seen" and "unseen".  Another might
be (un)viewed.  I'm not sure this is a big enough issue to matter much,
particularly with "unread" there as well, to influence the context, but as
I don't recall that point being addressed, I thought I'd mention it here.

> Read the whole thing before commenting please.

I did.

FWIW & IMO...  Your tenacity and attention to detail are both extremely
good qualities to have in someone doing a GLEP.  Few have the attention to
detail and self-standards necessary, and I fear many that do would give up
due to the barrage of criticism (hopefully all constructive <g>) these
things get.  Do keep up the good work!  IMO, you are /far/ better at it
than most would be, and the resulting GLEP will ultimately be the better
for it!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Tue, 13 Dec 2005 05:19:27 -0700 Duncan <1i5t5.duncan@cox.net> wrote:

| Ciaran McCreesh posted <20051213032043.55a6e40f@snowdrop.home>,
| excerpted below,  on Tue, 13 Dec 2005 03:20:43 +0000:
| 
| > Ok, new draft. Changes are as follows:
| []
| > * Changed /var/lib/portage to /var/lib/gentoo
| 
| OK, I must have missed the reason for that, and it isn't listed in
| one of your "a previous version" notes, unless I missed that too. <g>

It's getting ready for the glorious future when we won't be using
Portage any more. I also changed most of the instances of "Portage" in
the GLEP to "the package manager".

| Wouldn't it be less confusing if the news warning appeared in the same
| place, relative to the package listing, in both of these?  Isn't an
| emerge --ask just the output of pretend, with a confirmation pinned
| to the end? Shouldn't it continue to be that, at least in concept?

It's a question of visibility.

| First, the change outline doesn't state what the result actually was,
| in the GLEP. Mandatory would require a MUST (or a similar statement
| that it's mandatory), while the GLEP words it as a SHOULD.  Or is
| "should" not to be taken in the usual RFC meaning, but rather as an
| RFC "MUST"?

I'm avoiding 'must', because there's probably a legitimate exception
somewhere.

| Third, recall from the discussion of an earlier draft, someone
| mentioned the multiple meaning of read (as here) vs. "read" (as in
| README).  The suggestion to avoid that ambiguity was "seen" and
| "unseen".  Another might be (un)viewed.  I'm not sure this is a big
| enough issue to matter much, particularly with "unread" there as
| well, to influence the context, but as I don't recall that point
| being addressed, I thought I'd mention it here.

Pfff. Email clients use it. Trying to avoid words with multiple
definitions in English is pretty much futile.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Tue, Dec 13, 2005 at 03:20:43AM +0000, Ciaran McCreesh wrote:
> ``Posted:``
>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001) for
>     compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss +0000`` format
>     may also be included. Mandatory.

Proposed change:

 ``Posted:``
     Date of posting, in ``yyyy-mm-dd`` format (e.g. 2001-08-14) for
     compatibility with ISO-8601. UTC time in ``T19:53:46+0000`` format
     may also be included (`date --iso-8601=seconds`). Mandatory.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Tue, 13 Dec 2005 20:55:23 +0100 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| On Tue, Dec 13, 2005 at 03:20:43AM +0000, Ciaran McCreesh wrote:
| > ``Posted:``
| >     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001)
| > for compatibility with GLEP 1 [#glep-1]_. UTC time in ``hh-mm-ss
| > +0000`` format may also be included. Mandatory.
| 
| Proposed change:
| 
|  ``Posted:``
|      Date of posting, in ``yyyy-mm-dd`` format (e.g. 2001-08-14) for
|      compatibility with ISO-8601. UTC time in ``T19:53:46+0000``
| format may also be included (`date --iso-8601=seconds`). Mandatory.

I'll accept that change if you get Grant to accept a mini-GLEP
switching the GLEPs over to use that format too.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Tue, Dec 13, 2005 at 08:03:29PM +0000, Ciaran McCreesh wrote:
> I'll accept that change if you get Grant to accept a mini-GLEP
> switching the GLEPs over to use that format too.

Fair enough. What do you mean by a mini-GLEP?

Grant, what are your thoughts on this? Would you be willing to accept
such a change?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Tue, 13 Dec 2005 21:13:29 +0100 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| On Tue, Dec 13, 2005 at 08:03:29PM +0000, Ciaran McCreesh wrote:
| > I'll accept that change if you get Grant to accept a mini-GLEP
| > switching the GLEPs over to use that format too.
| 
| Fair enough. What do you mean by a mini-GLEP?

Like GLEP 43.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh schrieb:
| | Proposed change:
| |
| |  ``Posted:``
| |      Date of posting, in ``yyyy-mm-dd`` format (e.g. 2001-08-14) for
| |      compatibility with ISO-8601. UTC time in ``T19:53:46+0000``
| | format may also be included (`date --iso-8601=seconds`). Mandatory.
|
| I'll accept that change if you get Grant to accept a mini-GLEP
| switching the GLEPs over to use that format too.

I don't think that we need a GLEP for it, no matter how 'mini' it
would be.. Just asked Grant if I can convert dates in current GLEPs,
and he's ok with, though he wanted to have input from -dev first, so:

Anyone objecting to change those dates from "dd-mon-yyyy" format to
"yyyy-mm-dd"?

If not, i'll commit my diff in 24h...

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm
vqe7CvpCLGklzdgsb3DUq54=
=offW
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Dan Meltzer]

Well, it would be changing Glep 1... which probably needs an ammendatory GLEP

On 12/13/05, Danny van Dyk <kugelfang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ciaran McCreesh schrieb:
> | | Proposed change:
> | |
> | |  ``Posted:``
> | |      Date of posting, in ``yyyy-mm-dd`` format (e.g. 2001-08-14) for
> | |      compatibility with ISO-8601. UTC time in ``T19:53:46+0000``
> | | format may also be included (`date --iso-8601=seconds`). Mandatory.
> |
> | I'll accept that change if you get Grant to accept a mini-GLEP
> | switching the GLEPs over to use that format too.
>
> I don't think that we need a GLEP for it, no matter how 'mini' it
> would be.. Just asked Grant if I can convert dates in current GLEPs,
> and he's ok with, though he wanted to have input from -dev first, so:
>
> Anyone objecting to change those dates from "dd-mon-yyyy" format to
> "yyyy-mm-dd"?
>
> If not, i'll commit my diff in 24h...
>
> Danny
> - --
> Danny van Dyk <kugelfang@gentoo.org>
> Gentoo/AMD64 Project, Gentoo Scientific Project
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDnzCgaVNL8NrtU6IRAgcOAJ0b/to61rIrLyyMLfNpx4rRrvDRDwCeLufm
> vqe7CvpCLGklzdgsb3DUq54=
> =offW
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Tue, 13 Dec 2005 21:35:44 +0100 Danny van Dyk <kugelfang@gentoo.org>
wrote:
| I don't think that we need a GLEP for it, no matter how 'mini' it
| would be.. Just asked Grant if I can convert dates in current GLEPs,
| and he's ok with, though he wanted to have input from -dev first, so:
| 
| Anyone objecting to change those dates from "dd-mon-yyyy" format to
| "yyyy-mm-dd"?

I object. You're changing the GLEP process, and the way that that's
done is through another GLEP. Otherwise we'll end up with people
writing GLEPs following GLEP 1, and not realising that GLEP 1 is no
longer how things work.

Doing things properly wouldn't be difficult here. GLEP 43 took less
than half an hour. It's worth doing it for the sake of not confusing
future GLEP authors.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Mike Frysinger]

On Tue, Dec 13, 2005 at 03:36:33PM -0500, Dan Meltzer wrote:
> Well, it would be changing Glep 1... which probably needs an ammendatory GLEP

or we avoid all the redtape bs and just do it, let anarchy rule

the docs team already require dates to be in YYYY-MM-DD format and it
makes sense to me
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

Danny van Dyk wrote: [Tue Dec 13 2005, 02:35:44PM CST]
> | I'll accept that change if you get Grant to accept a mini-GLEP
> | switching the GLEPs over to use that format too.
> 
> I don't think that we need a GLEP for it, no matter how 'mini' it
> would be.. Just asked Grant if I can convert dates in current GLEPs,
> and he's ok with, though he wanted to have input from -dev first, so:
> 
> Anyone objecting to change those dates from "dd-mon-yyyy" format to
> "yyyy-mm-dd"?

Note that GLEP 1 would need to be amended, too, to reflect the new
format.

> If not, i'll commit my diff in 24h...

I actually had in mind a couple of days, just to make sure that people
had a reasonable chance to respond....

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] RE: Changes to date format of current GLEPs

[Dan Meltzer]

Whoops, sending to the list is a good idea

---------- Forwarded message ----------
From: Dan Meltzer <parallelgrapefruit@gmail.com>
Date: Tue, 13 Dec 2005 15:51:16 -0500
Subject: Re: Changes to date format of current GLEPs
To: Danny van Dyk <kugelfang@gentoo.org>

Nope, but the changes further on.

>   Created: <date created on, in dd-mmm-yyyy format>
> The Created header records the date that the GLEP was assigned a number, while > Post-History is used to record the dates of when new versions of the GLEP are
> posted to gentoo-dev. Both headers should be in dd-mmm-yyyy format, e.g.
> 14-Aug-2001.

Should

On 12/13/05, Danny van Dyk <kugelfang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Dan,
>
> Dan Meltzer schrieb:
> | Well, it would be changing Glep 1... which probably needs an
> ammendatory GLEP
>
> I would apply these changes to glep-0001.txt:
> dvandyk@phi glep $ cvs diff glep-0001.txt
> Index: glep-0001.txt
> ===================================================================
> RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0001.txt,v
> retrieving revision 1.8
> diff -u -b -B -r1.8 glep-0001.txt
> - --- glep-0001.txt       4 Apr 2004 23:05:35 -0000       1.8
> +++ glep-0001.txt       13 Dec 2005 20:45:37 -0000
> @@ -6,8 +6,8 @@
> ~ Status: Active
> ~ Type: Informational
> ~ Content-Type: text/x-rst
> - -Created: 31-May-2003
> - -Post-History: 1-Jun-2003, 2-Jul-2003
> +Created: 2003-05-31
> +Post-History: 2003-06-01, 2003-07-02
>
> Do you _really_ think this make a GLEP necessary?
>
> Danny
> - --
> Danny van Dyk <kugelfang@gentoo.org>
> Gentoo/AMD64 Project, Gentoo Scientific Project
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDnzUXaVNL8NrtU6IRAnruAJ4zXT5+gtyvKHi3BbD1EPvJYACCYwCgmG6z
> FW28Kz5W3N1nFz3ZJuPOEh8=
> =tVHu
> -----END PGP SIGNATURE-----
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Tue, 13 Dec 2005 20:44:42 +0000 Mike Frysinger <vapier@gentoo.org>
wrote:
| On Tue, Dec 13, 2005 at 03:36:33PM -0500, Dan Meltzer wrote:
| > Well, it would be changing Glep 1... which probably needs an
| > ammendatory GLEP
| 
| or we avoid all the redtape bs and just do it, let anarchy rule

It's not a question of red tape. Red tape would be requiring that the
GLEP be approved by twenty six different managers and team leads. It's
a question of having the change documented properly so that future GLEP
authors don't get bitten, and so that future GLEP authors understand
the rationale so that they don't go and introduce something that has
the same problems as the GLEP 1 date format.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Olivier Crete]

On Tue, 2005-13-12 at 20:43 +0000, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 21:35:44 +0100 Danny van Dyk <kugelfang@gentoo.org>
> wrote:
> | I don't think that we need a GLEP for it, no matter how 'mini' it
> | would be.. Just asked Grant if I can convert dates in current GLEPs,
> | and he's ok with, though he wanted to have input from -dev first, so:
> | 
> | Anyone objecting to change those dates from "dd-mon-yyyy" format to
> | "yyyy-mm-dd"?
> 
> I object. You're changing the GLEP process, and the way that that's
> done is through another GLEP. Otherwise we'll end up with people
> writing GLEPs following GLEP 1, and not realising that GLEP 1 is no
> longer how things work.

Why not just modify GlEP 1 ?

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changes to date format of current GLEPs

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dan,

Dan Meltzer schrieb:
| Well, it would be changing Glep 1... which probably needs an
ammendatory GLEP

I would apply these changes to glep-0001.txt:
dvandyk@phi glep $ cvs diff glep-0001.txt
Index: glep-0001.txt
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0001.txt,v
retrieving revision 1.8
diff -u -b -B -r1.8 glep-0001.txt
- --- glep-0001.txt       4 Apr 2004 23:05:35 -0000       1.8
+++ glep-0001.txt       13 Dec 2005 20:45:37 -0000
@@ -6,8 +6,8 @@
~ Status: Active
~ Type: Informational
~ Content-Type: text/x-rst
- -Created: 31-May-2003
- -Post-History: 1-Jun-2003, 2-Jul-2003
+Created: 2003-05-31
+Post-History: 2003-06-01, 2003-07-02

Do you _really_ think this make a GLEP necessary?

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDnzUXaVNL8NrtU6IRAnruAJ4zXT5+gtyvKHi3BbD1EPvJYACCYwCgmG6z
FW28Kz5W3N1nFz3ZJuPOEh8=
=tVHu
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Ciaran McCreesh wrote: [Tue Dec 13 2005, 02:43:42PM CST]
> I object. You're changing the GLEP process, and the way that that's
> done is through another GLEP. Otherwise we'll end up with people
> writing GLEPs following GLEP 1, and not realising that GLEP 1 is no
> longer how things work.
> 
> Doing things properly wouldn't be difficult here. GLEP 43 took less
> than half an hour. It's worth doing it for the sake of not confusing
> future GLEP authors.

Okay, I'll acquiesce to the call for a GLEP.  It seems a tad
extravagant, since I'll be the one approving it, but I can agree that
having the change documented would be useful.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changes to date format of current GLEPs

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ciaran,

Ciaran McCreesh schrieb:
| | Anyone objecting to change those dates from "dd-mon-yyyy" format to
| | "yyyy-mm-dd"?
|
| I object. You're changing the GLEP process, and the way that that's
| done is through another GLEP. Otherwise we'll end up with people
It wouldn't change the GLEP process. It changes how we document a date
information.
| writing GLEPs following GLEP 1, and not realising that GLEP 1 is no
| longer how things work.
No, they'd have to follow GLEP 2, the GLEP Template...

| Doing things properly wouldn't be difficult here. GLEP 43 took less
| than half an hour. It's worth doing it for the sake of not confusing
| future GLEP authors.
I just change all date strings in all glep-xxxx.txt ... Nobody will be
confused if he has a look into the template GLEP first.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDnzZVaVNL8NrtU6IRAnVWAJ9nGEEqRqv6D4CbGh1RLNPvVn8aygCgm1JE
iqNotfEWrZQuqfVfSiBzGqI=
=KyUu
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changes to date format of current GLEPs

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Tue, 13 Dec 2005 21:54:48 +0100 Danny van Dyk <kugelfang@gentoo.org>
wrote:
| Do you _really_ think this make a GLEP necessary?

Yes. Otherwise, the next person who comes along and writes a GLEP that
does something to do with dates will have to rationalise the whole date
format decision all over again.

You're assuming that "GLEP == lots of work". This is the case for some
things, but it isn't true in all situations. Look at 43 for an example.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <tester@gentoo.org>
wrote:
| Why not just modify GlEP 1 ?

Going back and retroactively modifying standards is icky, and it
*still* doesn't address the issue of documenting why the change was
made.

You know, a GLEP could have been written and posted by now :)

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re[2]: [gentoo-dev] Re: Changes to date format of current GLEPs

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]


13.12.2005, 22:00:12, Ciaran McCreesh wrote:

> On Tue, 13 Dec 2005 21:54:48 +0100 Danny van Dyk <kugelfang@gentoo.org>
> wrote:
> | Do you _really_ think this make a GLEP necessary?

> Yes. Otherwise, the next person who comes along and writes a GLEP that
> does something to do with dates will have to rationalise the whole date
> format decision all over again.

> You're assuming that "GLEP == lots of work". This is the case for some
> things, but it isn't true in all situations. Look at 43 for an example.

Pardon my ignorance, but how's a GLEP amending a GLEP (amending a GLEP ...)
less confusing than just changing the text of the original GLEP... Huh, goes
beyond me...


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] Re: Changes to date format of current GLEPs

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Tue, 13 Dec 2005 22:18:36 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| Pardon my ignorance, but how's a GLEP amending a GLEP (amending a
| GLEP ...) less confusing than just changing the text of the original
| GLEP... Huh, goes beyond me...

History. Look at RFCs for a good example. There's nothing wrong with
extending or replacing parts of existing standards, especially if the
existing standards are clearly marked as "extended by $blah" or
"replaced by $blah". On the other hand, changing accepted GLEPs leads to
confusion -- when someone says "GLEP 1", do they mean "GLEP 1 as it was
when it was approved" or "GLEP 1 plus the modifications made three
weeks ago" or "GLEP 1 plus the modifications made three weeks ago plus
the modifications made last Tuesday"?

Plus, of course, it helps to have a record of *why* changes were
made...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Changes to date format of current GLEPs

[Lares Moreau]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Tue, 2005-12-13 at 21:38 +0000, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 22:18:36 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | Pardon my ignorance, but how's a GLEP amending a GLEP (amending a
> | GLEP ...) less confusing than just changing the text of the original
> | GLEP... Huh, goes beyond me...
> 
> History. Look at RFCs for a good example. There's nothing wrong with
> extending or replacing parts of existing standards, especially if the
> existing standards are clearly marked as "extended by $blah" or
> "replaced by $blah". On the other hand, changing accepted GLEPs leads to
> confusion -- when someone says "GLEP 1", do they mean "GLEP 1 as it was
> when it was approved" or "GLEP 1 plus the modifications made three
> weeks ago" or "GLEP 1 plus the modifications made three weeks ago plus
> the modifications made last Tuesday"?
> 
> Plus, of course, it helps to have a record of *why* changes were
> made...
> 
Or IEEE ish

Original:   GLEP 01
Ammended:   GLEP 01.a
-- 
Lares Moreau <lares.moreau@gmail.com>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net                 |
Gentoo x86 Arch Tester                 |               ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |          Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: GLEP 42 (Critical News Reporting) round five

[Duncan]

Ciaran McCreesh posted <20051213192000.1f8e35ff@snowdrop.home>, excerpted
below,  on Tue, 13 Dec 2005 19:20:00 +0000:

> Duncan wrote:
> 
> | Ciaran McCreesh posted ...
> |
> | > * Changed /var/lib/portage to /var/lib/gentoo
> | 
> | OK, I must have missed the reason for that
> 
> It's getting ready for the glorious future when we won't be using
> Portage any more. I also changed most of the instances of "Portage" in
> the GLEP to "the package manager".

I noticed the generic "package manager" stuff, but hadn't put two and two
together.  I have mixed feelings but see the point.

> | Mandatory would require a MUST (or a similar statement
> | that it's mandatory), while the GLEP words it as a SHOULD.
> 
> I'm avoiding 'must', because there's probably a legitimate exception
> somewhere.

Makes sense.  Just didn't agree with the change summary, and I wondered
which was intended.

> | Third, recall from the discussion of an earlier draft, someone
> | mentioned the multiple meaning of read (as here) vs. "read" (as in
> | README).
> 
> Pfff. Email clients use it. Trying to avoid words with multiple
> definitions in English is pretty much futile.

Agreed.  Just hadn't seen the point addressed, and recalled seeing it
mentioned.

Thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Olivier Crete]

On Tue, 2005-13-12 at 21:09 +0000, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <tester@gentoo.org>
> wrote:
> | Why not just modify GlEP 1 ?
> 
> Going back and retroactively modifying standards is icky, and it
> *still* doesn't address the issue of documenting why the change was
> made.

And why not just adding a changelog to the glep explaining the changes?
I really don't like to idea of having to read 8 gleps to find out how to
write a glep ... and calling it glep 1.a is a good idea.. or 1.1

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Tue, Dec 13, 2005 at 06:05:03PM -0500, Olivier Crete wrote:
> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1

GLEP 45, "GLEP date format", says that GLEP 1 should be modified to
reflect this new date format, should it be accepted.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

[gentoo-dev] Re: Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Dan Meltzer]

http://viewcvstest.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0001.html?rev=1.8&view=log
meh, when it comes down to it... isn't this good enough of a change log?

On 12/13/05, Olivier Crete <tester@gentoo.org> wrote:
> On Tue, 2005-13-12 at 21:09 +0000, Ciaran McCreesh wrote:
> > On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <tester@gentoo.org>
> > wrote:
> > | Why not just modify GlEP 1 ?
> >
> > Going back and retroactively modifying standards is icky, and it
> > *still* doesn't address the issue of documenting why the change was
> > made.
>
> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1
>
> --
> Olivier Crête
> tester@gentoo.org
> Gentoo Developer
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]


14.12.2005, 0:05:03, Olivier Crete wrote:


> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1

+1

-- 

jakub

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] Changes to date format of current GLEPs (was: GLEP 42 (Critical News Reporting) round five)

[Francesco Riosa]

Olivier Crete wrote:
> On Tue, 2005-13-12 at 21:09 +0000, Ciaran McCreesh wrote:
>> On Tue, 13 Dec 2005 15:53:45 -0500 Olivier Crete <tester@gentoo.org>
>> wrote:
>> | Why not just modify GlEP 1 ?
>>
>> Going back and retroactively modifying standards is icky, and it
>> *still* doesn't address the issue of documenting why the change was
>> made.
> 
> And why not just adding a changelog to the glep explaining the changes?
> I really don't like to idea of having to read 8 gleps to find out how to
> write a glep ... and calling it glep 1.a is a good idea.. or 1.1
> 

agree, have to dig multiple places to get the history of a document is
annoying.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical News Reporting) round five

[Andrew Muraco]

Ciaran McCreesh wrote:

>Ok, new draft. Changes are as follows:
>
...

>* Added emerge --ask thingie
>  
>
Perhaps it would be a good idea to have an extra prompt during -av and a 
forced prompt (perhaps with a timeout) for just plain old emerge. And to 
make people that just don't care happy, a FEATURES="nonews" for making 
portage ignore news. Just an idea to add some more redunancy in the way 
news is delivered.

comment on multi-repo support:
-Perhaps someone should write a formal GLEP for multiple repo support 
before we get flustered over that here.

Greetings,
Andrew Muraco
-- 
gentoo-dev@gentoo.org mailing list