[gentoo-dev] GLEP 42 (Critical news reporting) updates

[gentoo-dev] GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

Main changes since the previous edition:

* File format tweaks.

* Changes to the way relevance headers work to make it easy to do
things like "show this to gcc-3.3 users on x86 or sparc".

* News items are no longer copied. This makes it considerably easier to
install news items -- there's no longer a need to do clever directory
syncing tricks.

For those of you who can't read RST, an updated version will appear on
the website sometime in the not too distant future. For those of you
who can, see the attached.

For the sake of keeping this vaguely sane, replies that meet any of the
following criteria will be ignored:

* Top or HTML posting

* Lack of coherent English sentences, complete with proper punctuation
and capitalisation.

* The sender's first name ends in 'an', and they are not me.

* Questions about why the GLEP doesn't address hypothetical vapourware
concepts.

* Questions about why the GLEP doesn't provide a way to tell users that
there's a pissup at Reuben's house next Tuesday.

* Questions about why the GLEP doesn't require "integration with other
systems", rather than leaving it merely as something that should be
easily doable.

* Anything involving XML.

-- 
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: 19997 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

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-5`` 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

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`` 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/portage/news/news.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 require one news list per repository. Assuming repositories have some
   kind of unique identifier, this file could be named ``news-repoid.unread``.

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)

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.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.unread``
file. News clients may add the name to a ``news.read`` file in the same
directory with the same file format.

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) updates

[Dan Meltzer]

Point of Clarity,

> and the ``mysql-5`` database format changes.

These changes actually occured in mysql 4.1, not mysql-5


On 12/10/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> Main changes since the previous edition:
>
> * File format tweaks.
>
> * Changes to the way relevance headers work to make it easy to do
> things like "show this to gcc-3.3 users on x86 or sparc".
>
> * News items are no longer copied. This makes it considerably easier to
> install news items -- there's no longer a need to do clever directory
> syncing tricks.
>
> For those of you who can't read RST, an updated version will appear on
> the website sometime in the not too distant future. For those of you
> who can, see the attached.
>
> For the sake of keeping this vaguely sane, replies that meet any of the
> following criteria will be ignored:
>
> * Top or HTML posting
>
> * Lack of coherent English sentences, complete with proper punctuation
> and capitalisation.
>
> * The sender's first name ends in 'an', and they are not me.
>
> * Questions about why the GLEP doesn't address hypothetical vapourware
> concepts.
>
> * Questions about why the GLEP doesn't provide a way to tell users that
> there's a pissup at Reuben's house next Tuesday.
>
> * Questions about why the GLEP doesn't require "integration with other
> systems", rather than leaving it merely as something that should be
> easily doable.
>
> * Anything involving XML.
>
> --
> 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) updates

[Homer Parker]

On Sat, 2005-12-10 at 22:31 -0500, Dan Meltzer wrote:
> Point of Clarity,
> 
> > and the ``mysql-5`` database format changes.
> 
> These changes actually occured in mysql 4.1, not mysql-5
> 
> > * The sender's first name ends in 'an', and they are not me.

	Um, your first name ends in 'an' so your reply is immaterial....

-- 
Homer Parker
Gentoo/AMD64 Team
Gentoo/AMD64 Arch Tester Strategic Lead
Gentoo Linux Developer Relations
hparker@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote:
> Whenever relevant unread news items are found, the package manager will
> create a file named ``/var/lib/portage/news/news.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 require one news list per repository. Assuming
> repositories have some kind of unique identifier, this file could be named
> ``news-repoid.unread``.

Repositories will definitely have a unique identifier. Perhaps it would be 
better to use the repository-identifing format from the beginning so that 
readers are forced to be forwards-compatible? Assuming the readers would then 
output the repository name, labeling it "gentoo" should work well...

> When a news item is read, its name should be removed from the
> ``news.unread`` file. News clients may add the name to a ``news.read`` file
> in the same directory with the same file format.

news.read should either be mandatory or not created at all. Should a user 
change from a reader that creates and uses the file to one that doesn't and 
then change back again the results will be unexpected.

>     * Important: there are 5 unread news items.
>     * Type emerge --help news to learn how to read news files.
[...]
> 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.

By "suggested" you mean that it should be referenced in the news help?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Lares Moreau]

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

A couple things I noted:
(1)
In News Item Identities we have the following date format,
> Each news item will have a unique identifier. This identifier will be
> in the form ``yyyy-mm-dd-short-name``

Later in "News Item Headers" we have an other in order to be compatable
with GLEP 1.
> ``Posted:``
>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001)

Is there any reason why we can't keep all the dates in the GLEP 1 date
format? IMHO this helps prevent confusion.

(2)
> Checks for new news messages should be displayed:
>
> * After an ``emerge sync``
> * After an ``emerge --pretend``
Add:
  * Before an ``emerge --ask`` 'yes||no' response
I don't know if this is implied but I think it should be explicitly
stated  
> * Before an ``emerge <target>`` (which may also include a red warning
message)

(3)
Could you be more verbose in the 'News Item Removal' section.  I ask
because what would be considered "no longer relevant".  I think the case
where a router(or similar) box is not updated for >6mths must be
considered.  The Admin may have very well forgot about some particular
News Item, and if it is removed, this box will 'miss' the News Item.

May I suggest only removing news Items after all the packages in the
Display-If-(Installed|Profile) slots are no longer in the tree.

Just a lowely ATs opinion
-- 
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 --]

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Luca Barbato]

Ciaran McCreesh wrote:
> 
> * Anything involving XML.
> 

What about incidentally make the format yaml compatible?

yaml.org

/me runs

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Wernfried Haas]

On Sun, Dec 11, 2005 at 01:35:50AM +0000, Ciaran McCreesh wrote:
> 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-5`` database format changes.
> 
> There are currently several ways of delivering important news items to our
> users, none of them particularly effective:

I'd suggest changing this to something more constructive - calling our
current efforts "none of them particularly effective" isn't exactly
a constructive way of critizing things.

> * 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 is currently being used for that purpose as well - even if the
GLEP will leave it for less important news in the future. So i guess
it should be listed here.

> A more reliable way of getting news of critical updates out to users is required
> to avoid repeats of the various recent upgrade debacles. 

As it was mentioned above, gcc 3.4 went pretty well on x86, can't
comment on mysql as i don't use it myself. I'd suggest changing this
text for something more diplomatic as i don't see much sense in having
council approved GLEPs talking about council approved upgrade debacles.
I'd suggest:
"A more reliable way of getting news of critical updates out to users is required
to prevent problems during upgrades."

> .. 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]_.

Thanks for clearing this quite important point up.

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

I know you think it is beyond the scope of this GLEP, but i believe
having a new tool with rules for publication and OTOH all the
old tools mentioned above without clear guidelines/hints how to use
them doesn't make perfect sense. The gcc upgrade on x86 has shown so
far that combining our efforts does work quite well. Even if not
within this GLEP there should be some documentation how to make use of
all available tools to inform users. Otherwise we just have another
tool that gets more or less acceptance within the community.

I'd suggest extending the process of creating a news item to also
create a text to be posted to www.gentoo.org, the
announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course
depending on the importance it may be decided to e.g. not post it 
on announce but only www.gentoo.org.

Do you think this can be done within this GLEP or rather outside?

cheers,	
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Dan Meltzer]

On 12/11/05, Wernfried Haas <amne@gentoo.org> wrote:
> On Sun, Dec 11, 2005 at 01:35:50AM +0000, Ciaran McCreesh wrote:
> > 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-5`` database format changes.
> >
> > There are currently several ways of delivering important news items to our
> > users, none of them particularly effective:
>
> I'd suggest changing this to something more constructive - calling our
> current efforts "none of them particularly effective" isn't exactly
> a constructive way of critizing things.
>
> > * 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 is currently being used for that purpose as well - even if the
> GLEP will leave it for less important news in the future. So i guess
> it should be listed here.
>
> > A more reliable way of getting news of critical updates out to users is required
> > to avoid repeats of the various recent upgrade debacles.
>
> As it was mentioned above, gcc 3.4 went pretty well on x86, can't
> comment on mysql as i don't use it myself. I'd suggest changing this
> text for something more diplomatic as i don't see much sense in having
> council approved GLEPs talking about council approved upgrade debacles.
> I'd suggest:
> "A more reliable way of getting news of critical updates out to users is required
> to prevent problems during upgrades."

My opinion? The gcc-3.4 upgrade has appeared to go fairly well because
it doesn't automagically upgrade, it requires manual intervention
before it is used.  People see this and investigate.  This is not
something that always happens (apache anyone?, baselayout ~arch
anyone?)  And due to this, I don't believe we can judge success on the
gcc upgrade alone.

>
> > .. 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]_.
>
> Thanks for clearing this quite important point up.
>
> > 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.
>
> I know you think it is beyond the scope of this GLEP, but i believe
> having a new tool with rules for publication and OTOH all the
> old tools mentioned above without clear guidelines/hints how to use
> them doesn't make perfect sense. The gcc upgrade on x86 has shown so
> far that combining our efforts does work quite well. Even if not
> within this GLEP there should be some documentation how to make use of
> all available tools to inform users. Otherwise we just have another
> tool that gets more or less acceptance within the community.
>
> I'd suggest extending the process of creating a news item to also
> create a text to be posted to www.gentoo.org, the
> announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course
> depending on the importance it may be decided to e.g. not post it
> on announce but only www.gentoo.org.
>
> Do you think this can be done within this GLEP or rather outside?
>
> cheers,
>         Wernfried
>
> --
> Wernfried Haas (amne) - amne at gentoo dot org
> Gentoo Forums: http://forums.gentoo.org
> IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Francesco Riosa]

Luca Barbato wrote:
> Ciaran McCreesh wrote:
>>
>> * Anything involving XML.
>>
> 
> What about incidentally make the format yaml compatible?
> 
> yaml.org

Only if we (you?) are able to extract a considerably simpler subset of
the specification, as is it's really overkill.

> 
> /me runs

where ? gentoo devs are everywhere ... mwhuaahahahah

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Repositories will definitely have a unique identifier. Perhaps it
| would be better to use the repository-identifing format from the
| beginning so that readers are forced to be forwards-compatible?
| Assuming the readers would then output the repository name, labeling
| it "gentoo" should work well...

*shrug* If someone creates metadata/repository_id (or whatever), I'll
go with that. Otherwise, I'm not in favour of attempting to guess how
the thing will be implemented.

| > When a news item is read, its name should be removed from the
| > ``news.unread`` file. News clients may add the name to a
| > ``news.read`` file in the same directory with the same file format.
| 
| news.read should either be mandatory or not created at all. Should a
| user change from a reader that creates and uses the file to one that
| doesn't and then change back again the results will be unexpected.

I'm not sure that that's the case. With a news to email forwarder, for
example, it wouldn't make sense to keep track of news.read.

| >     * Important: there are 5 unread news items.
| >     * Type emerge --help news to learn how to read news files.
| [...]
| > 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.
| 
| By "suggested" you mean that it should be referenced in the news help?

News help, handbook etc, yes.

-- 
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) updates

[Ciaran McCreesh]

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

On Sun, 11 Dec 2005 17:46:01 +0100 Wernfried Haas <amne@gentoo.org>
wrote:
| > There are currently several ways of delivering important news items
| > to our users, none of them particularly effective:
| 
| I'd suggest changing this to something more constructive - calling our
| current efforts "none of them particularly effective" isn't exactly
| a constructive way of critizing things.

They're not particularly effective. If they were, there would be no
need for this GLEP.

| > A more reliable way of getting news of critical updates out to
| > users is required to avoid repeats of the various recent upgrade
| > debacles. 
| 
| As it was mentioned above, gcc 3.4 went pretty well on x86, can't
| comment on mysql as i don't use it myself.

I didn't say anywhere that the gcc 3.4 upgrade was a debacle.

| I'd suggest changing this
| text for something more diplomatic as i don't see much sense in having
| council approved GLEPs talking about council approved upgrade
| debacles.

What, we're not allowed to admit that not everything we do works?

| > .. 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]_.
| 
| Thanks for clearing this quite important point up.

That was added after the GLEP was wildly misreported in GWN the last
time around...

| I'd suggest extending the process of creating a news item to also
| create a text to be posted to www.gentoo.org, the
| announce-mailinglist, the forums, RSS feeds, GWN, etc. Of course
| depending on the importance it may be decided to e.g. not post it 
| on announce but only www.gentoo.org.
| 
| Do you think this can be done within this GLEP or rather outside?

That's beyond the scope of the GLEP.

-- 
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) updates

[Francesco Riosa]

Ciaran McCreesh wrote:

> GLEP: 42
> Title: Critical News Reporting

+1 .
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Sun, 11 Dec 2005 04:57:23 -0700 Lares Moreau
<lares.moreau@gmail.com> wrote:
| Is there any reason why we can't keep all the dates in the GLEP 1 date
| format? IMHO this helps prevent confusion.

Yes. It makes sorting news items far harder.

|   * Before an ``emerge --ask`` 'yes||no' response

Does anyone really use emerge --ask?

| Could you be more verbose in the 'News Item Removal' section.  I ask
| because what would be considered "no longer relevant".  I think the
| case where a router(or similar) box is not updated for >6mths must be
| considered.  The Admin may have very well forgot about some particular
| News Item, and if it is removed, this box will 'miss' the News Item.

A news item is no longer relevant when there's no reasonable way in
which it could apply. Six months is still relevant... Updates go back
to 3Q-2002, for 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] GLEP 42 (Critical news reporting) updates

[sanchan]

Ciaran McCreesh wrote:

> Does anyone really use emerge --ask?

Yes.
-- 
Sandro
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Henrik Brix Andersen]

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

On Sun, Dec 11, 2005 at 04:57:23AM -0700, Lares Moreau wrote:
> A couple things I noted:
> (1)
> In News Item Identities we have the following date format,
> > Each news item will have a unique identifier. This identifier will be
> > in the form ``yyyy-mm-dd-short-name``
> 
> Later in "News Item Headers" we have an other in order to be compatable
> with GLEP 1.
> > ``Posted:``
> >     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001)
> 
> Is there any reason why we can't keep all the dates in the GLEP 1 date
> format? IMHO this helps prevent confusion.

As noted in the original GLEP 42 discussion, I strongly feel we should
use an ISO-8601 compliant date string representation as this is both
a) international, b) easy to read and c) machine parsable.

See http://en.wikipedia.org/wiki/ISO_8601 or date(1) for more
information.

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) updates

[Ciaran McCreesh]

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

On Sun, 11 Dec 2005 22:41:30 +0100 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| As noted in the original GLEP 42 discussion, I strongly feel we should
| use an ISO-8601 compliant date string representation as this is both
| a) international, b) easy to read and c) machine parsable.

You forgot d) a pain in the ass to parse, e) inconsistent with
everything else, f) a pain in the ass to sort, g) massive overkill.

-- 
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) updates

[Diego 'Flameeyes' Pettenò]

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

On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote:
> You forgot d) a pain in the ass to parse, e) inconsistent with
> everything else, f) a pain in the ass to sort, g) massive overkill.
I find ISO 8601 simple to sort....

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[John Myers]

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

On Sunday 11 December 2005 13:19, Ciaran McCreesh wrote:
> On Sun, 11 Dec 2005 04:57:23 -0700 Lares Moreau
> |   * Before an ``emerge --ask`` 'yes||no' response
>
> Does anyone really use emerge --ask?
I do. Almost always in fact. When I want to install a package, I use --ask 
with --verbose so I get the --pretend output, and if I agree with the 
proposed list of dependencies and USE-flags, I allow it to proceed with just 
two keystrokes instead of having to go back up, change the command, and wait 
the extra time for it to recalculate the dependencies.

Not a huge savings, but I do use it, and I would expect news items to be 
displayed right before the prompt where I can't miss them
-- 
# 
# electronerd, the electronerdian from electronerdia
#

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

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Curtis Napier]

Ciaran McCreesh wrote:
> Does anyone really use emerge --ask?

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

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[John Myers]

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

On Sunday 11 December 2005 14:07, Diego 'Flameeyes' Pettenò wrote:
> On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote:
> > You forgot d) a pain in the ass to parse, e) inconsistent with
> > everything else, f) a pain in the ass to sort, g) massive overkill.
>
> I find ISO 8601 simple to sort....
Well, if you take the entire spec with all its variations, then ciaranm's 
points there are indeed correct (week number formats, day of the year 
formats, punctuationless formats, etc.) 
-- 
# 
# electronerd, the electronerdian from electronerdia
#

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

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Diego 'Flameeyes' Pettenò]

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

On Sunday 11 December 2005 23:53, John Myers wrote:
> Well, if you take the entire spec with all its variations, then ciaranm's
> points there are indeed correct (week number formats, day of the year
> formats, punctuationless formats, etc.)
Well as long as you always use the same format, the sort is quite natural...

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Monday 12 December 2005 02:43, Ciaran McCreesh wrote:
> On Sun, 11 Dec 2005 13:32:05 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | Repositories will definitely have a unique identifier. Perhaps it
> | would be better to use the repository-identifing format from the
> | beginning so that readers are forced to be forwards-compatible?
> | Assuming the readers would then output the repository name, labeling
> | it "gentoo" should work well...
>
> *shrug* If someone creates metadata/repository_id (or whatever), I'll
> go with that. Otherwise, I'm not in favour of attempting to guess how
> the thing will be implemented.

Repositories will be user-labelled. However, all that readers need be 
concerned with is how to extract the repository name from the news.unread 
file and how to then resolve that to a directory name, regardless of how 
repositories are implemented.

Even before multiple respositories are properly supported, I guarantee bugs 
about support for this in portage overlays. With the above, we would be able 
to add that support. Without it, all we can do is put a big CANTFIX.

> | > When a news item is read, its name should be removed from the
> | > ``news.unread`` file. News clients may add the name to a
> | > ``news.read`` file in the same directory with the same file format.
> |
> | news.read should either be mandatory or not created at all. Should a
> | user change from a reader that creates and uses the file to one that
> | doesn't and then change back again the results will be unexpected.
>
> I'm not sure that that's the case. With a news to email forwarder, for
> example, it wouldn't make sense to keep track of news.read.

In that case, the data should probably not be in /var/lib/portage and 
definitely not specified in the GLEP. It has nothing to do with portage (the 
app) and isn't a requirement on readers. What if a reader wants to keep track 
of what date an item was read on? Or any other metadata? A new file would 
need to be created anyway due to format constrainst placed on news.read...

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Repositories will be user-labelled. However, all that readers need be 
| concerned with is how to extract the repository name from the
| news.unread file and how to then resolve that to a directory name,
| regardless of how repositories are implemented.

See, this is exactly why I'm not wanting to care about multiple repo
details at this point. There's no specification of how they work and
what exactly they're supposed to do, and to make matters worse the way
you seem to think they'll be handled is a really really bad way of
doing it.

| Even before multiple respositories are properly supported, I
| guarantee bugs about support for this in portage overlays. With the
| above, we would be able to add that support. Without it, all we can
| do is put a big CANTFIX.

Overlay is not the same as multiple repository support.

| In that case, the data should probably not be in /var/lib/portage and 
| definitely not specified in the GLEP. It has nothing to do with
| portage (the app) and isn't a requirement on readers. What if a
| reader wants to keep track of what date an item was read on? Or any
| other metadata? A new file would need to be created anyway due to
| format constrainst placed on news.read...

Hrm. Does the GLEP need to cover how news readers that want to keep
track of whether or not the sysadmin was wearing pants last tuesday
should work 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) updates

[Jason Stubbs]

On Monday 12 December 2005 09:01, Ciaran McCreesh wrote:
> On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | Repositories will be user-labelled. However, all that readers need be
> | concerned with is how to extract the repository name from the
> | news.unread file and how to then resolve that to a directory name,
> | regardless of how repositories are implemented.
>
> See, this is exactly why I'm not wanting to care about multiple repo
> details at this point. There's no specification of how they work and
> what exactly they're supposed to do, and to make matters worse the way
> you seem to think they'll be handled is a really really bad way of
> doing it.

Regardless of what you think about the current plans for multiple repository 
support, the details that readers will need to know wont change.

> | Even before multiple respositories are properly supported, I
> | guarantee bugs about support for this in portage overlays. With the
> | above, we would be able to add that support. Without it, all we can
> | do is put a big CANTFIX.
>
> Overlay is not the same as multiple repository support.

There's no difference as far as readers go.

> | In that case, the data should probably not be in /var/lib/portage and
> | definitely not specified in the GLEP. It has nothing to do with
> | portage (the app) and isn't a requirement on readers. What if a
> | reader wants to keep track of what date an item was read on? Or any
> | other metadata? A new file would need to be created anyway due to
> | format constrainst placed on news.read...
>
> Hrm. Does the GLEP need to cover how news readers that want to keep
> track of whether or not the sysadmin was wearing pants last tuesday
> should work too?

Nope, which is why news.read shouldn't be specified.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Regardless of what you think about the current plans for multiple
| repository support, the details that readers will need to know wont
| change.

Incorrect. Right now, readers should ignore news-blah.unread and only
pay attention to news.unread. Readers will have to be updated to deal
with multiple repositories whenever the multiple repositories GLEP is
approved.

| > | Even before multiple respositories are properly supported, I
| > | guarantee bugs about support for this in portage overlays. With
| > | the above, we would be able to add that support. Without it, all
| > | we can do is put a big CANTFIX.
| >
| > Overlay is not the same as multiple repository support.
| 
| There's no difference as far as readers go.

Sure there is. there's no metadata/ directory in overlays.

| Nope, which is why news.read shouldn't be specified.

news.read is specified because there was demand for it the last time
around. It's staying specified because the reasons given were based
upon convincing use cases rather than random speculation.

-- 
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) updates

[Duncan]

Ciaran McCreesh posted <20051211211908.466352f0@snowdrop.home>, excerpted
below,  on Sun, 11 Dec 2005 21:19:08 +0000:

> Does anyone really use emerge --ask?

Oh, /my/ yes!

The following should speak for itself.  (I have a similar set of ep*
commands, those in /usr/local/bin, so I can --pretend as my normal user. 
Yes, I do have autocompletion setup for them all, too, tho it was
basically a matter of ensuring the gentoo autocompletion ran first, then
using the same autocomplete functions emerge did, since these are almost
all just special cases of the emerge command.)

 ~#cd /usr/local/sbin
/usr/local/sbin#for eascript in ea* ;do echo $eascript;cat $eascript;done
ea
#!/bin/bash
exec emerge -av --oneshot $*

ea2
#!/bin/bash
exec emerge -av $*

eafetch
#!/bin/bash
exec emerge -avuDf $*

eafetchworld
#!/bin/bash
exec emerge -avuDf world

eapaK
#!/bin/bash
exec emerge -avk --oneshot $*

eapaK2
#!/bin/bash
exec emerge -avk $*

eapak
#!/bin/bash
exec emerge -avK --oneshot $*

eapak2
#!/bin/bash
exec emerge -avK $*

easync
#!/bin/bash
emerge sync
eupdatedb
emerge -avuDf world

eatree
#!/bin/bash
exec emerge -avuDt --oneshot $*

eatree2
#!/bin/bash
exec emerge -avuDt $*

eatreeworld
#!/bin/bash
exec emerge -avuDt world

eaworld
#!/bin/bash
exec emerge -avuD world

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

[gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Duncan]

Jason Stubbs posted <200512120911.53976.jstubbs@gentoo.org>, excerpted
below,  on Mon, 12 Dec 2005 09:11:53 +0900:

> On Monday 12 December 2005 09:01, Ciaran McCreesh wrote:
>> On Mon, 12 Dec 2005 08:44:00 +0900 Jason Stubbs <jstubbs@gentoo.org>
>>
>> wrote:
>> | Repositories will be user-labelled. However, all that readers need be
>> | concerned with is how to extract the repository name from the
>> | news.unread file and how to then resolve that to a directory name,
>> | regardless of how repositories are implemented.
>>
>> See, this is exactly why I'm not wanting to care about multiple repo
>> details at this point. There's no specification of how they work and
>> what exactly they're supposed to do, and to make matters worse the way
>> you seem to think they'll be handled is a really really bad way of
>> doing it.
> 
> Regardless of what you think about the current plans for multiple repository 
> support, the details that readers will need to know wont change.

Ciaran hasn't stated, but it appears to me if I'm reading correctly
between the lines, the reason he doesn't want to mess with specifying
multiple repo details right now is that it's getting the cart before the
horse in terms of nailing down certain areas of the multiple repo spec.

For example,  if repository-id forms a part of the path and we define path
parsing now, then we are effectively defining legal characters for
repository-id now. That's an entirely different glep, far out of scope and
reaching into other people's territory, limiting how that might be
implemented by defining a portion of the id-scope in an entirely unrelated
glep.

Given how heated I've seen GLEP discussion get (and I'm not saying that's
/bad/, just a fact), I really can't blame Ciaran for attempting to keep
the scope of the proposal, and therefore the debate, down to exactly what
he's aiming to accomplish, without ending up getting into an entirely
/different/ debate about how he's limiting the future flexibility of the
multiple repo implementation.  Once there's a concrete proposal there to
work with, then and only then, he's saying (from my viewpoint), is it
appropriate for consideration in relation to the news proposal.
Don't unnecessarily tie the two together, complicating life for both.  Let
each be argued on its merits separately, and when/if multiple repo is
actually close enough to deployment that there's some actual rules to work
with, /then/ worry about fixing this to match.

If I'm incorrect, just tell me to go back in my corner and lurk some more
<g>, but that's what I'm getting out of this subthread so far.

-- 
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] GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Monday 12 December 2005 09:20, Ciaran McCreesh wrote:
> On Mon, 12 Dec 2005 09:11:53 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | Regardless of what you think about the current plans for multiple
> | repository support, the details that readers will need to know wont
> | change.
>
> Incorrect. Right now, readers should ignore news-blah.unread and only
> pay attention to news.unread. Readers will have to be updated to deal
> with multiple repositories whenever the multiple repositories GLEP is
> approved.

Incorrect. There needs to be no GLEP regarding multiple repository support in 
portage. There may need to be a GLEP regarding splitting up the portage tree 
into separate repositories, but that is nothing to do with the issue I'm 
talking about.

> | > | Even before multiple respositories are properly supported, I
> | > | guarantee bugs about support for this in portage overlays. With
> | > | the above, we would be able to add that support. Without it, all
> | > | we can do is put a big CANTFIX.
> | >
> | > Overlay is not the same as multiple repository support.
> |
> | There's no difference as far as readers go.
>
> Sure there is. there's no metadata/ directory in overlays.

Again, why I really don't like this design. You're asking portage to do crap 
to support external tools without looking to provide compatibilty with future 
portages. How are you planning to find the metadata directory in the first 
place?

> | Nope, which is why news.read shouldn't be specified.
>
> news.read is specified because there was demand for it the last time
> around. It's staying specified because the reasons given were based
> upon convincing use cases rather than random speculation.

Can you show a use case that crosses several readers?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Monday 12 December 2005 18:30, Duncan wrote:
> For example,  if repository-id forms a part of the path and we define path
> parsing now, then we are effectively defining legal characters for
> repository-id now.

This is only of concern to portage developers.

> That's an entirely different glep, far out of scope and 
> reaching into other people's territory, limiting how that might be
> implemented by defining a portion of the id-scope in an entirely unrelated
> glep.

No need for a glep as far as portage support goes anymore than Ciaran needs a 
glep to change or add syntax highlighting in vim.

> Given how heated I've seen GLEP discussion get (and I'm not saying that's
> /bad/, just a fact), I really can't blame Ciaran for attempting to keep
> the scope of the proposal, and therefore the debate, down to exactly what
> he's aiming to accomplish, without ending up getting into an entirely
> /different/ debate about how he's limiting the future flexibility of the
> multiple repo implementation.

There doesn't need to be a debate. This whole proposal doesn't care about 
portage compatibility whatsoever and it's exactly this style of thinking that 
slows down portage development (which everybody loves to complain about so 
much).

> Once there's a concrete proposal there to work with, then and only then, 
> he's saying (from my viewpoint), is it appropriate for consideration in 
> relation to the news proposal. Don't unnecessarily tie the two together, 
> complicating life for both.  Let each be argued on its merits separately, 
> and when/if multiple repo is actually close enough to deployment that 
> there's some actual rules to work with, /then/ worry about fixing this to 
> match.      

As I said already, there will immediately be a bug asking for overlay support. 
Portage already supports multiple in a form whether anybody likes it or not.
How they are supported and how they will change should be of no concern to the 
glep. What should be of concern is establishing a robust API between the 
readers and portage such that future changes won't cause breakage.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Francesco Riosa]

Jason Stubbs wrote:
[...]
> As I said already, there will immediately be a bug asking for overlay support. 
> Portage already supports multiple in a form whether anybody likes it or not.
[...]
BTW I love that feature ;-)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates

[Henrik Brix Andersen]

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

On Sun, Dec 11, 2005 at 02:53:34PM -0800, John Myers wrote:
> On Sunday 11 December 2005 14:07, Diego 'Flameeyes' Pettenò wrote:
> > On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote:
> > > You forgot d) a pain in the ass to parse, e) inconsistent with
> > > everything else, f) a pain in the ass to sort, g) massive overkill.
> >
> > I find ISO 8601 simple to sort....
> Well, if you take the entire spec with all its variations, then ciaranm's 
> points there are indeed correct (week number formats, day of the year 
> formats, punctuationless formats, etc.) 

I specifically said an "ISO-8601 compatible" - I have no intentions of
using the most verbose format.

./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) updates

[Ciaran McCreesh]

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

On Mon, 12 Dec 2005 23:29:00 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Incorrect. There needs to be no GLEP regarding multiple repository
| support in portage. There may need to be a GLEP regarding splitting
| up the portage tree into separate repositories, but that is nothing
| to do with the issue I'm talking about.

Sure. You could go ahead and implement it without a GLEP in the really
really bad way you're proposing currently. Or you could take the GLEP
route and let other developers help you come up with a design that
doesn't royally suck.

| Again, why I really don't like this design. You're asking portage to
| do crap to support external tools without looking to provide
| compatibilty with future portages. How are you planning to find the
| metadata directory in the first place?

Not at all. There's an "it will probably be handled like this" note in
the GLEP. I can't get any more detailed than that until there's a
proper specification for what Portage is going to do in the future.

| > | Nope, which is why news.read shouldn't be specified.
| >
| > news.read is specified because there was demand for it the last time
| > around. It's staying specified because the reasons given were based
| > upon convincing use cases rather than random speculation.
| 
| Can you show a use case that crosses several readers?

Look back to the original thread.

-- 
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: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| No need for a glep as far as portage support goes anymore than Ciaran
| needs a glep to change or add syntax highlighting in vim.

The difference is, Vim syntax scripts are well established, and there
aren't any design issues to solve. Multiple repository support clearly
*isn't* obvious, because the solution you've described is the wrong one.

| There doesn't need to be a debate. This whole proposal doesn't care
| about portage compatibility whatsoever and it's exactly this style of
| thinking that slows down portage development (which everybody loves
| to complain about so much).

Sure it does. It cares about the way Portage is currently, and it cares
about any reasonable future Portage changes.

| As I said already, there will immediately be a bug asking for overlay
| support. Portage already supports multiple in a form whether anybody
| likes it or not. How they are supported and how they will change
| should be of no concern to the glep. What should be of concern is
| establishing a robust API between the readers and portage such that
| future changes won't cause breakage.

Ok, give me a list of every single future enhancement to Portage and
I'll make sure the GLEP will be compatible with them.

-- 
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) updates

[Zac Medico]

Jason Stubbs wrote:
> 
> Repositories will be user-labelled. However, all that readers need be 
> concerned with is how to extract the repository name from the news.unread 
> file and how to then resolve that to a directory name, regardless of how 
> repositories are implemented.

Expanding on this a little further then, we would have a file in a standard location such as /var/lib/portage-news/repos.desc that maps repository identifiers to the absolute paths of news directories (no hard coding of metadata/news/).  This will provide a layer of indirection so that the portage news add-on will be able to direct news readers to the proper locations, regardless of repository implementation details.

> Even before multiple respositories are properly supported, I guarantee bugs 
> about support for this in portage overlays. With the above, we would be able 
> to add that support. Without it, all we can do is put a big CANTFIX.
> 
[...]
> the data should probably not be in /var/lib/portage

I would also prefer that /var/lib/portage/ be reserved for core portage functionality (package management) and that non-essential add-ons store their data elsewhere.

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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Tuesday 13 December 2005 02:16, Ciaran McCreesh wrote:
> On Mon, 12 Dec 2005 23:49:31 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | No need for a glep as far as portage support goes anymore than Ciaran
> | needs a glep to change or add syntax highlighting in vim.
>
> The difference is, Vim syntax scripts are well established, and there
> aren't any design issues to solve. Multiple repository support clearly
> *isn't* obvious, because the solution you've described is the wrong one.

Blah, blah, blah.

> | There doesn't need to be a debate. This whole proposal doesn't care
> | about portage compatibility whatsoever and it's exactly this style of
> | thinking that slows down portage development (which everybody loves
> | to complain about so much).
>
> Sure it does. It cares about the way Portage is currently, and it cares
> about any reasonable future Portage changes.

Bullshit.

> | As I said already, there will immediately be a bug asking for overlay
> | support. Portage already supports multiple in a form whether anybody
> | likes it or not. How they are supported and how they will change
> | should be of no concern to the glep. What should be of concern is
> | establishing a robust API between the readers and portage such that
> | future changes won't cause breakage.
>
> Ok, give me a list of every single future enhancement to Portage and
> I'll make sure the GLEP will be compatible with them.

Without a list of future features, you think the best way to go must be the 
least agile? As Zac said, all that matters to keep full compatibility on the 
side of the readers is to add a level of indirection. All your reasoning 
above falls apart in the face of that simple *logical* request.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Without a list of future features, you think the best way to go must
| be the least agile? As Zac said, all that matters to keep full
| compatibility on the side of the readers is to add a level of
| indirection. All your reasoning above falls apart in the face of that
| simple *logical* request.

Every problem can be solved by adding another layer of indirection,
except for the problem of having too many layers of indirection. This
layer you are proposing is not going to do anything useful. It's merely
adding indirection for the sake of it. There's no more need for this
than there is need for a two thousand line XML DTD which allows us to
specify the author's date of birth using an ancient Sumerian calendar.

Come up with a full specification of how Portage will handle multiple
repositories, and get that specification agreed upon by the people who
will end up having to use it. *Then* come back and ask me to add in
more complexity. I'm not going to over-complicate things to deal with
random hypothetical half-baked speculation.

-- 
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: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Tuesday 13 December 2005 11:11, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 10:51:51 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | Without a list of future features, you think the best way to go must
> | be the least agile? As Zac said, all that matters to keep full
> | compatibility on the side of the readers is to add a level of
> | indirection. All your reasoning above falls apart in the face of that
> | simple *logical* request.
>
> Every problem can be solved by adding another layer of indirection,
> except for the problem of having too many layers of indirection. This
> layer you are proposing is not going to do anything useful. It's merely
> adding indirection for the sake of it. There's no more need for this
> than there is need for a two thousand line XML DTD which allows us to
> specify the author's date of birth using an ancient Sumerian calendar.
>
> Come up with a full specification of how Portage will handle multiple
> repositories, and get that specification agreed upon by the people who
> will end up having to use it. *Then* come back and ask me to add in
> more complexity. I'm not going to over-complicate things to deal with
> random hypothetical half-baked speculation.

So what are you going to do? I asked already but you didn't answer.
How are you going to find $PORTDIR/metadata/news?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| So what are you going to do? I asked already but you didn't answer.
| How are you going to find $PORTDIR/metadata/news?

At present, by using portageq with a hardcoded suffix. If in the future
Portage introduces new functionality, then clients and the
specification can easily be updated to handle said functionality.

-- 
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: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | So what are you going to do? I asked already but you didn't answer.
> | How are you going to find $PORTDIR/metadata/news?
>
> At present, by using portageq with a hardcoded suffix. If in the future
> Portage introduces new functionality, then clients and the
> specification can easily be updated to handle said functionality.

And how can that be adapted to work with overlays, completely ignoring the 
possibility of distinct repositories. Overlays is something that exists 
already and news support for them is a request that will appear as soon as 
news support is added.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Andrew Muraco]

Jason Stubbs wrote:

>On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote:
>  
>
>>On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <jstubbs@gentoo.org>
>>
>>wrote:
>>| So what are you going to do? I asked already but you didn't answer.
>>| How are you going to find $PORTDIR/metadata/news?
>>
>>At present, by using portageq with a hardcoded suffix. If in the future
>>Portage introduces new functionality, then clients and the
>>specification can easily be updated to handle said functionality.
>>    
>>
>
>And how can that be adapted to work with overlays, completely ignoring the 
>possibility of distinct repositories. Overlays is something that exists 
>already and news support for them is a request that will appear as soon as 
>news support is added.
>
>--
>Jason Stubbs
>  
>
Your Point is Moot because an overlay (at present) is going to be 
exprimental software, (unsupported offically anyways) and so you 
_should_ know what risks your taking, this GLEP is to warn you about 
supported updates/changes which you _need_ to know about. Why should an 
overlay need to have news if the user has the consciensely update and 
maintain it to begin it.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| And how can that be adapted to work with overlays, completely
| ignoring the possibility of distinct repositories. Overlays is
| something that exists already and news support for them is a request
| that will appear as soon as news support is added.

Overlays don't contain metadata directories and don't get synced, so
they don't contain news items. Supporting news from multiple sources is
something that's tied to supporting packages from multiple sources,
which overlay doesn't permit. Fixing that would require fixing portage
to support multiple repositories rather than using overlay, which is an
issue for a different GLEP.

-- 
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: GLEP 42 (Critical news reporting) updates

[Zac Medico]

Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | And how can that be adapted to work with overlays, completely
> | ignoring the possibility of distinct repositories. Overlays is
> | something that exists already and news support for them is a request
> | that will appear as soon as news support is added.
> 
> Overlays don't contain metadata directories and don't get synced, so
> they don't contain news items. Supporting news from multiple sources is
> something that's tied to supporting packages from multiple sources,
> which overlay doesn't permit. Fixing that would require fixing portage
> to support multiple repositories rather than using overlay, which is an
> issue for a different GLEP.
> 

You can use gensync (included with gentoolkit).

$ gensync --help
Usage: gensync <options> repo-id-1 repo-id-2 ...
where <options> is one of
 -a, --all-sources  - sync all know sources
 -l, --list-sources - list known rsync sources
 -C, --no-color      - turn off colours
 -h, --help         - this help screen
 -V, --version      - display version info

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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Tuesday 13 December 2005 11:45, Andrew Muraco wrote:
> Jason Stubbs wrote:
> >On Tuesday 13 December 2005 11:22, Ciaran McCreesh wrote:
> >>On Tue, 13 Dec 2005 11:17:30 +0900 Jason Stubbs <jstubbs@gentoo.org>
> >>
> >>wrote:
> >>| So what are you going to do? I asked already but you didn't answer.
> >>| How are you going to find $PORTDIR/metadata/news?
> >>
> >>At present, by using portageq with a hardcoded suffix. If in the future
> >>Portage introduces new functionality, then clients and the
> >>specification can easily be updated to handle said functionality.
> >
> >And how can that be adapted to work with overlays, completely ignoring the
> >possibility of distinct repositories. Overlays is something that exists
> >already and news support for them is a request that will appear as soon as
> >news support is added.
>
> Your Point is Moot ... 

Interesting use of capitals.

> because an overlay (at present) is going to be exprimental software, 

or a repository from a non-English speaking community Gentoo site...

> (unsupported offically anyways) and so you _should_ know what risks your 
> taking,

except if your a new non-English-speaking user utilizing such a repository.

> this GLEP is to warn you about supported updates/changes which you _need_ to 
> know about.

This GLEP is about getting news regarding a set of ebuilds to the user. Making 
it only about the Gentoo supported tree serves no purpose.

> Why should an overlay need to have news if the user has the consciensely 
> update and maintain it to begin it.      

Because they already support package.mask, thirdpartymirrors, eclasses and 
just about anything else that exists in the supported tree.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Tuesday 13 December 2005 11:48, Ciaran McCreesh wrote:
> On Tue, 13 Dec 2005 11:39:14 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | And how can that be adapted to work with overlays, completely
> | ignoring the possibility of distinct repositories. Overlays is
> | something that exists already and news support for them is a request
> | that will appear as soon as news support is added.
>
> Overlays don't contain metadata directories

There's nothing preventing this.

> and don't get synced,

As Zac pointed out, esync exists.

> so they don't contain news items.

Neither of the points above prevent an overlay from containing news items.

> Supporting news from multiple sources is something that's tied to supporting 
> packages from multiple sources, which overlay doesn't permit. 

Overlays are used for getting packages from multiple sources every day. The 
only thing preventing them from supporting getting news from multiple sources 
is your stubborness against adding a single level of indirection - a level of 
indirection that has absolutely no cost to readers.

> Fixing that would require fixing portage to support multiple repositories 
> rather than using overlay, which is an issue for a different GLEP.

I'll say it again. It wouldn't require a GLEP because the changes wouldn't go 
beyond portage. At least they wouldn't if you'd allow portage to keep its 
internals internal.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Grant Goodyear]

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

Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST]
> > | There doesn't need to be a debate. This whole proposal doesn't care
> > | about portage compatibility whatsoever and it's exactly this style of
> > | thinking that slows down portage development (which everybody loves
> > | to complain about so much).
> >
> > Sure it does. It cares about the way Portage is currently, and it cares
> > about any reasonable future Portage changes.
> 
> Bullshit.

I'm not quite sure I understand the strong response.  The GLEP was
clearly designed to have a minimal impact on portage.  Now I'm willing
to listen to arguments that it does not, in fact, do that, but certainly
the well-defined, minimal coupling between the news and emerge was not
accidental.  (Incidentally, I've never complained about the pace of
portage development.  I'm not developing it, so I don't complain about
those who are.)

Just as an aside, it would be nice if we could keep gentoo-dev@g.o
vulgarity-free, since it's a list that's often read at work by a good
number of people.

> 
> > | As I said already, there will immediately be a bug asking for overlay
> > | support. Portage already supports multiple in a form whether anybody
> > | likes it or not. How they are supported and how they will change
> > | should be of no concern to the glep. What should be of concern is
> > | establishing a robust API between the readers and portage such that
> > | future changes won't cause breakage.

Wouldn't it suffice for the GLEP to simply have a statement that it will
query portage for a list of repositories, once there's a way to do that,
but until then the default repo will be assumed?

-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] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Wednesday 14 December 2005 07:12, Grant Goodyear wrote:
> Jason Stubbs wrote: [Mon Dec 12 2005, 07:51:51PM CST]
> > > | As I said already, there will immediately be a bug asking for overlay
> > > | support. Portage already supports multiple in a form whether anybody
> > > | likes it or not. How they are supported and how they will change
> > > | should be of no concern to the glep. What should be of concern is
> > > | establishing a robust API between the readers and portage such that
> > > | future changes won't cause breakage.
>
> Wouldn't it suffice for the GLEP to simply have a statement that it will
> query portage for a list of repositories, once there's a way to do that,
> but until then the default repo will be assumed?

Modifications are required to portage anyway. Why postpone it until after 
several readers are written and force all of them become broken?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Modifications are required to portage anyway. Why postpone it until
| after several readers are written and force all of them become broken?

Because there isn't a specification saying what the future changes to
Portage will be, so supporting said future changes straight off would
require a massively over-generalised, over-indirected solution.

-- 
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: GLEP 42 (Critical news reporting) updates

[Grant Goodyear]

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

Jason Stubbs wrote: [Tue Dec 13 2005, 05:44:39PM CST]
> > Wouldn't it suffice for the GLEP to simply have a statement that it will
> > query portage for a list of repositories, once there's a way to do that,
> > but until then the default repo will be assumed?
> 
> Modifications are required to portage anyway. Why postpone it until after 
> several readers are written and force all of them become broken?

Okay, so what is the portage team proposing to use for a repo query API?  

-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] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Wednesday 14 December 2005 08:54, Ciaran McCreesh wrote:
> On Wed, 14 Dec 2005 08:44:39 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | Modifications are required to portage anyway. Why postpone it until
> | after several readers are written and force all of them become broken?
>
> Because there isn't a specification saying what the future changes to
> Portage will be, so supporting said future changes straight off would
> require a massively over-generalised, over-indirected solution.

newsdir="$(portageq envvar PORTDIR)/metadata/news"
newsdir="$(portageq newsdir gentoo)"

Both have one level of indirection. The first has two hard coded elements. The 
first has one. Where is the massive over-indirection?

The second allows future changes. The first does not. Where does the 
specification come into it? All that would be needed is to allow a user a 
method to name overlays and it'd be useful straight off the bat.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| newsdir="$(portageq envvar PORTDIR)/metadata/news"
| newsdir="$(portageq newsdir gentoo)"
| 
| Both have one level of indirection. The first has two hard coded
| elements. The first has one. Where is the massive over-indirection?
| 
| The second allows future changes. The first does not. Where does the 
| specification come into it? All that would be needed is to allow a
| user a method to name overlays and it'd be useful straight off the
| bat.

The former relies upon existing, widely used functionality together
with a well-defined path. The latter has some magic hard-coded name
voodoo (what's a 'gentoo'?) and is still stuck only supporting a single
location.

-- 
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: GLEP 42 (Critical news reporting) updates

[Zac Medico]

For reference, I'm quoting this snippet from earlier in the thread:

Jason Stubbs wrote:
> On Sunday 11 December 2005 10:35, Ciaran McCreesh wrote:
>>.. Note:: Future changes to Portage involving support for multiple
>>repositories may require one news list per repository. Assuming
>>repositories have some kind of unique identifier, this file could be named
>>``news-repoid.unread``.
> 
> 
> Repositories will definitely have a unique identifier. Perhaps it would be 
> better to use the repository-identifing format from the beginning so that 
> readers are forced to be forwards-compatible? Assuming the readers would then 
> output the repository name, labeling it "gentoo" should work well...
> 

[...]

Ciaran McCreesh wrote:
> On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | newsdir="$(portageq envvar PORTDIR)/metadata/news"
> | newsdir="$(portageq newsdir gentoo)"
> | 
> | Both have one level of indirection. The first has two hard coded
> | elements. The first has one. Where is the massive over-indirection?
> | 
> | The second allows future changes. The first does not. Where does the 
> | specification come into it? All that would be needed is to allow a
> | user a method to name overlays and it'd be useful straight off the
> | bat.
> 
> The former relies upon existing, widely used functionality together
> with a well-defined path. The latter has some magic hard-coded name
> voodoo (what's a 'gentoo'?) and is still stuck only supporting a single
> location.
> 

Apparently, 'gentoo' is meant to be the identifier for the official gentoo repository (portage tree).  It corresponds to 'magic-chicken' below.

Ciaran McCreesh wrote:
> 
> 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.

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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Jason Stubbs]

On Wednesday 14 December 2005 09:52, Ciaran McCreesh wrote:
> On Wed, 14 Dec 2005 09:11:51 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | newsdir="$(portageq envvar PORTDIR)/metadata/news"
> | newsdir="$(portageq newsdir gentoo)"
> |
> | Both have one level of indirection. The first has two hard coded
> | elements. The first has one. Where is the massive over-indirection?
> |
> | The second allows future changes. The first does not. Where does the
> | specification come into it? All that would be needed is to allow a
> | user a method to name overlays and it'd be useful straight off the
> | bat.
>
> The former relies upon existing, widely used functionality together
> with a well-defined path. The latter has some magic hard-coded name
> voodoo (what's a 'gentoo'?) and is still stuck only supporting a single
> location.

What's a 'PORTDIR'? What's a 'metadata'? Outside of portage, these are also 
magic name voodoo. But I've grown tired of your imperfect circles. I think 
your design sucks and you think that my solution to making it not suck is too 
soon. The solution to that seems simple to me. Rather than have 'package 
manager' do anything, just have it provide hooks that will allow you to do 
your thing at the times you want. Good luck with solving the "news in 
overlays" bug when it comes in.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Wed, 14 Dec 2005 21:09:02 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| What's a 'PORTDIR'?

A PORTDIR is a well defined, widely used variable.

| What's a 'metadata'?

A metadata is a well defined, widely used directory in the tree.

| Outside of portage, these are also magic name voodoo.

Sure. Where in the GLEP does it say that I care about supporting Debian?

| But I've grown tired of your imperfect circles. I think your design
| sucks and you think that my solution to making it not suck is too
| soon. The solution to that seems simple to me. Rather than have
| 'package manager' do anything, just have it provide hooks that will
| allow you to do your thing at the times you want.

Exactly what I am doing. Hence why I'm not making Portage know any more
than it really really has to about news.

-- 
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: GLEP 42 (Critical news reporting) updates

[Zac Medico]

Ciaran McCreesh wrote:
> | soon. The solution to that seems simple to me. Rather than have
> | 'package manager' do anything, just have it provide hooks that will
> | allow you to do your thing at the times you want.
> 
> Exactly what I am doing. Hence why I'm not making Portage know any more
> than it really really has to about news.
> 

I wish you'd reconsider, because I was looking forward to multiple repository support.  You may want to specify the newsdir="$(portageq envvar PORTDIR)/metadata/news" bit in the glep and also note in the glep that there were dissenting opinions regarding the assumptions that you have made there.

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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico <zmedico@gmail.com> wrote:
| I wish you'd reconsider, because I was looking forward to multiple
| repository support.

Well, if Portage ever gets multiple repository support, then news
clients can be updated to handle it. The GLEP says that already.

-- 
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: GLEP 42 (Critical news reporting) updates

[Brian Harring]

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

On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote:
> On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico <zmedico@gmail.com> wrote:
> | I wish you'd reconsider, because I was looking forward to multiple
> | repository support.
> 
> Well, if Portage ever gets multiple repository support, then news
> clients can be updated to handle it. The GLEP says that already.

Care to clarify how that transition is going to occur?

Your proposal, if you know a roadblock is coming down the line I 
expect it to be documented in the glep (with potential suggestions how 
to minimize the horkage).

If you're not going to do N repo, state so in the glep, state that it 
_will_ break down the line, and that the issue while known, are being 
ignored despite portage developers concerns.  Only fair the council
knows the exact details, that and it made clear that this was known 
when proposed and ignored.

If you're going to create and dump a mess on us, I expect it to be in 
the proposal- especially since your proposal is intrinsically portage 
bound.

Thing that's daft out of all of this time wasting is that what's being 
asked of you is a couple of portageq calls so that we're not 
screwed over by a feature.  Something along the lines of...

portageq get_repo_id path # helper method of getting repo_id for a path (dar)
portageq match root atom [repo-id] # method of limiting matching of 
	vdb to a specific source repo
portageq newsdir repo_id  # get the absolute news path for said id.

Integration for that is pretty damn simple from our side of things, 
and you get the major blocker of your news glep resolved (meaning it 
has a chance of actually passing).

If it's too slow, I'd suggest since it's your proposal, looking for a 
method to batch up the calls (modularization of portageq would be 
required, which is available in the dead ebd branch already).  Tricks 
of that sort are easily implemented, and don't require specs and gleps 
(just requires someone to do a minor bit of work).
~harring


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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <ferringb@gentoo.org>
wrote:
| On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote:
| > On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico <zmedico@gmail.com>
| > wrote:
| > | I wish you'd reconsider, because I was looking forward to multiple
| > | repository support.
| > 
| > Well, if Portage ever gets multiple repository support, then news
| > clients can be updated to handle it. The GLEP says that already.
| 
| Care to clarify how that transition is going to occur?
| 
| Your proposal, if you know a roadblock is coming down the line I 
| expect it to be documented in the glep (with potential suggestions
| how to minimize the horkage).

It'll probably just be a case of updating news clients to query Portage
somehow for a list of repository IDs and using appropriately named news
files. Hard to say for sure without details of how exactly multiple
repository support will work though -- for example, if you're going to
allow fancy characters in repository names then some kind of name
mangling standard will need to be defined.

| If you're going to create and dump a mess on us, I expect it to be in 
| the proposal- especially since your proposal is intrinsically portage 
| bound.

There's very little that's Portage bound. As originally requested, I've
tried to keep as much as is reasonably possible *out* of Portage...

| Thing that's daft out of all of this time wasting is that what's
| being asked of you is a couple of portageq calls so that we're not 
| screwed over by a feature.  Something along the lines of...
| 
| portageq get_repo_id path # helper method of getting repo_id for a
| path (dar) portageq match root atom [repo-id] # method of limiting
| matching of vdb to a specific source repo
| portageq newsdir repo_id  # get the absolute news path for said id.

You're asking me to guess how Portage multiple repository support will
work, and then ask for a bunch of changes to Portage to support
appropriate dummy functions. Unless you're prepared to commit
yourselves to saying "multiple repository support will work like
$blah", I'm not going to even think about asking you to restrict
yourselves to a particular implementation...

Especially since you've said "we're not doing it the way you think it
should work"...

| If it's too slow, I'd suggest since it's your proposal, looking for a 
| method to batch up the calls (modularization of portageq would be 
| required, which is available in the dead ebd branch already).  Tricks 
| of that sort are easily implemented, and don't require specs and
| gleps (just requires someone to do a minor bit of work).

That's not likely to be a major performance hit... We're not expecting
the user to have more than a few repositories, are we?

-- 
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: GLEP 42 (Critical news reporting) updates

[Brian Harring]

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

On Sun, Dec 18, 2005 at 12:14:30AM +0000, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 15:33:18 -0800 Brian Harring <ferringb@gentoo.org> wrote:
> | On Wed, Dec 14, 2005 at 09:54:06PM +0000, Ciaran McCreesh wrote:
> | > Well, if Portage ever gets multiple repository support, then news
> | > clients can be updated to handle it. The GLEP says that already.
> | Care to clarify how that transition is going to occur?
> |
> | Your proposal, if you know a roadblock is coming down the line I 
> | expect it to be documented in the glep (with potential suggestions
> | how to minimize the horkage).
> 
> It'll probably just be a case of updating news clients to query Portage
> somehow for a list of repository IDs and using appropriately named news
> files.

Transitioning from single news.unread to N is going to break clients 
that expect a single.

As I said, you're going to break stuff- and you're building it into 
your glep out of (aparent) stubborness.

What do you want, another glep amending yours with that one little 
detail?  Or someone just gets off their ass and tweaks your glep, gets 
another glep #, and stops the pointless arguing with you and pushes 
a competing glep?

The news glep crosses several groups, collaboration here is required, 
meaning *listen* to the folk you're trying to command.  Otherwise the 
glep *will* go nowhere no matter how much noise you make.


> Hard to say for sure without details of how exactly multiple
> repository support will work though -- for example, if you're going to
> allow fancy characters in repository names then some kind of name
> mangling standard will need to be defined.

Standard ascii, same rules required for glep31.


> | If you're going to create and dump a mess on us, I expect it to be in 
> | the proposal- especially since your proposal is intrinsically portage 
> | bound.
> 
> There's very little that's Portage bound. As originally requested, I've
> tried to keep as much as is reasonably possible *out* of Portage...

It's distributed via the portage tree, it's updated by portage, the 
check for new news items is *via* portage, and check for news items 
prior to merging is done by portage.

If that truly was your intention, you failed in it..  It's bound to 
portage, despite the rhetoric.


> | Thing that's daft out of all of this time wasting is that what's
> | being asked of you is a couple of portageq calls so that we're not 
> | screwed over by a feature.  Something along the lines of...
> | 
> | portageq get_repo_id path # helper method of getting repo_id for a
> | path (dar) portageq match root atom [repo-id] # method of limiting
> | matching of vdb to a specific source repo
> | portageq newsdir repo_id  # get the absolute news path for said id.
> 
> You're asking me to guess how Portage multiple repository support will
> work, and then ask for a bunch of changes to Portage to support
> appropriate dummy functions.

I'll remind you that portage devs have stated this is required for 
your damn glep.  Iow, collaboration here is required- work out the api 
that you need that fits in with what we need, instead of wasting our 
time arguing over whether you should do it or not.


> Unless you're prepared to commit
> yourselves to saying "multiple repository support will work like
> $blah", I'm not going to even think about asking you to restrict
> yourselves to a particular implementation...

There's no asking here; you're pushing a glep, we've stated in it's 
current form constrains *our* efforts long term.

Word games suck, instead of playing them you *should* be trying to 
address the concerns- iow, what do you *explicitly* need from portage, 


> Especially since you've said "we're not doing it the way you think it
> should work"...

Where have I stated that?  My statements thus far about multi repo 
were in reference to a glep that missed the target.

Provide quotes please, or get back to nailing down exactly what you 
need portageq wise so we can state "do it this way, and we'll shut 
up".


> | If it's too slow, I'd suggest since it's your proposal, looking for a 
> | method to batch up the calls (modularization of portageq would be 
> | required, which is available in the dead ebd branch already).  Tricks 
> | of that sort are easily implemented, and don't require specs and
> | gleps (just requires someone to do a minor bit of work).
> 
> That's not likely to be a major performance hit... We're not expecting
> the user to have more than a few repositories, are we?

Stated it to cut off any angle of "waah, can't go that route, 
portageq calls are to slow".

Something your glep doesn't clarify and I want nailed down in stone 
(since at your request we are being explicit here), is how the 
'package manager' is going to track news items that are marked as 
unread already, further the news.skip file.

Basically... you're the glep author/champion, implementing the portage 
modifications are your responsibility (we may help, but it's your job 
to do it).  Since this proposal *is* complicating portage, hand waving 
of the sort "implementation is not specified by this GLEP" I want 
nailed down.

You want us to nail everything down for our request, I'd like you to 
do the same (especially since we're stuck maintaining whatever you 
propose/create).
~harring

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

Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates

[Ciaran McCreesh]

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

On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring <ferringb@gentoo.org>
wrote:
| Transitioning from single news.unread to N is going to break clients 
| that expect a single.

Yup.

| As I said, you're going to break stuff- and you're building it into 
| your glep out of (aparent) stubborness.

No no. I'm just not adding something ill defined and arbitrary to the
GLEP to avoid introducing minor possible breakage when some ill defined
and arbitrary change is made to Portage.

| What do you want, another glep amending yours with that one little 
| detail?

Probably won't be necessary...

| The news glep crosses several groups, collaboration here is required, 
| meaning *listen* to the folk you're trying to command.  Otherwise the 
| glep *will* go nowhere no matter how much noise you make.

And I'm asking you to provide me with a specification of how multiple
repositories will work. Without that, there's no way the GLEP can be
made to handle multiple repositories.

| > | If you're going to create and dump a mess on us, I expect it to
| > | be in the proposal- especially since your proposal is
| > | intrinsically portage bound.
| > 
| > There's very little that's Portage bound. As originally requested,
| > I've tried to keep as much as is reasonably possible *out* of
| > Portage...
| 
| It's distributed via the portage tree, it's updated by portage, the 
| check for new news items is *via* portage, and check for news items 
| prior to merging is done by portage.
| 
| If that truly was your intention, you failed in it..  It's bound to 
| portage, despite the rhetoric.

No no. A Portage bound solution would stick all the code and clients in
Portage proper, rather than using Portage merely for hooks as far as is
reasonably possible.

| Word games suck, instead of playing them you *should* be trying to 
| address the concerns- iow, what do you *explicitly* need from
| portage, 

What explicitly I need, *if* the GLEP is to specify multiple repository
support from the outset, is a specification of how Portage will handle
multiple repositories conceptually and a description of the interface
that will be provided by Portage.

| > Especially since you've said "we're not doing it the way you think
| > it should work"...
| 
| Where have I stated that?  My statements thus far about multi repo 
| were in reference to a glep that missed the target.
|
| Provide quotes please, or get back to nailing down exactly what you 
| need portageq wise so we can state "do it this way, and we'll shut 
| up".

I'm thinking mainly about "Portage externally will use user defined" in
relation to repository identification. Any specification on multiple
repositories that comes from me will have said identifiers being
repository designed, simply because I can't see a sane way of handling
it otherwise.

| You want us to nail everything down for our request, I'd like you to 
| do the same (especially since we're stuck maintaining whatever you 
| propose/create).

I can't nail down details on multiple repository support until I'm told
what Portage will do. Give me a specification for what Portage will do
and I'll quite happily make the GLEP work with it.

-- 
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: GLEP 42 (Critical news reporting) updates

[Brian Harring]

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

On Sun, Dec 18, 2005 at 01:07:27AM +0000, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring <ferringb@gentoo.org>
> wrote:
> | Transitioning from single news.unread to N is going to break clients 
> | that expect a single.
> 
> Yup.
> 
> | As I said, you're going to break stuff- and you're building it into 
> | your glep out of (aparent) stubborness.
> 
> No no. I'm just not adding something ill defined and arbitrary to the
> GLEP to avoid introducing minor possible breakage when some ill defined
> and arbitrary change is made to Portage.

Well, since we're toeing the line, I'll just state your glep is ill 
defined and arbitrary, it is inflexible and incomplete due to the fact 
it doesn't take into consideration the existing solutions (namely overlays).

Back off the technical double speak insults unless you want others 
people to get nastier then they are already.


> | What do you want, another glep amending yours with that one little 
> | detail?
> 
> Probably won't be necessary...

If you're unwilling to make your 'flexible' proposal actually flexible 
for anything but your stuff (eselect), either the glep is going to be 
fought tooth and nail or a competing glep is going to come out of 
this.

Bluntly, stop being a tool, users want this feature, stop using it as 
fodder to fight.


> | The news glep crosses several groups, collaboration here is required, 
> | meaning *listen* to the folk you're trying to command.  Otherwise the 
> | glep *will* go nowhere no matter how much noise you make.
> 
> And I'm asking you to provide me with a specification of how multiple
> repositories will work. Without that, there's no way the GLEP can be
> made to handle multiple repositories.

We have overlays already.  That *is* multiple repositories.

Stop trying to dodge the request by making us waste our time and 
produce a stand alone repository glep- overlays exist *now*, thus you 
*do* need to address them *now* else your glep is incomplete.


> | > | If you're going to create and dump a mess on us, I expect it to
> | > | be in the proposal- especially since your proposal is
> | > | intrinsically portage bound.
> | > 
> | > There's very little that's Portage bound. As originally requested,
> | > I've tried to keep as much as is reasonably possible *out* of
> | > Portage...
> | 
> | It's distributed via the portage tree, it's updated by portage, the 
> | check for new news items is *via* portage, and check for news items 
> | prior to merging is done by portage.
> | 
> | If that truly was your intention, you failed in it..  It's bound to 
> | portage, despite the rhetoric.
> 
> No no. A Portage bound solution would stick all the code and clients in
> Portage proper, rather than using Portage merely for hooks as far as is
> reasonably possible.

Word games...  You're dodging my point.


> | Word games suck, instead of playing them you *should* be trying to 
> | address the concerns- iow, what do you *explicitly* need from
> | portage, 
> 
> What explicitly I need, *if* the GLEP is to specify multiple repository
> support from the outset, is a specification of how Portage will handle
> multiple repositories conceptually and a description of the interface
> that will be provided by Portage.

Overlays.

The only thing you need is a repo id, the only thing we need is to know 
what you'll be accessing, what we need to future proof from an api 
standpoint.


> | > Especially since you've said "we're not doing it the way you think
> | > it should work"...
> | 
> | Where have I stated that?  My statements thus far about multi repo 
> | were in reference to a glep that missed the target.
> |
> | Provide quotes please, or get back to nailing down exactly what you 
> | need portageq wise so we can state "do it this way, and we'll shut 
> | up".
> 
> I'm thinking mainly about "Portage externally will use user defined" in
> relation to repository identification.  Any specification on multiple
> repositories that comes from me will have said identifiers being
> repository designed, simply because I can't see a sane way of handling
> it otherwise.

We've had this discussion once already, but I'll keep hammering the 
point till you follow it- external repo label is just that, what the 
user would specify on commandline.  emerge --repo blah --rsync (fex).

Internal ids are a seperate beast, and a simple solution *now* is that 
any repo that provides new must bundle an ID.

Do that, and portage can made to use it for your news crap.  Aliasing 
(user naming) is something *we* would add as a feature down the line.

Why am I stating it as such?  Because again, overlays exist now, and 
your glep is willfully leaving them out in the cold.


> | You want us to nail everything down for our request, I'd like you to 
> | do the same (especially since we're stuck maintaining whatever you 
> | propose/create).
> 
> I can't nail down details on multiple repository support until I'm told
> what Portage will do. Give me a specification for what Portage will do
> and I'll quite happily make the GLEP work with it.

Overlays have existed for at least 2 years.
Theres your spec.  Time to amend your glep so it actually encompasses 
them, especially considering your glep is a modification of the tree 
format.
~harring

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