[gentoo-dev] GLEP ??: Critical News Reporting

[gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

The attached GLEP is a draft proposal for the emerge --news thing that's
been under discussion. There are still some TODO items. These are calls
for people to weigh in with suggestions. Of course, suggestions on other
items are good too...

There is currently no explanation as to why this GLEP should be chosen
over ChrisWhite's 42. I will add such a section if anyone requests it.

Grant, please pick me a number.

I'll post this one to -user and the forums if it survives a round or
two of being shot at in here first...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

GLEP: XX
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-October-2005
Post-Date: 1-November-2005

Abstract
========

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

Motivation
==========

There are currently several ways of getting news out to our users, none of
them particularly effective:

* Gentoo Weekly News
* The ``gentoo-announce`` mailing list
* The Gentoo Forums
* The main Gentoo website

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

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

An adequate solution must meet all of the following requirements:

Lightweight
    It is not reasonable to expect all users to have an MTA, web browser,
    email client, cron daemon or text processing suite available on their
    system. In particular, this means that any markup to be parsed must be
    in a very simple format.

Relevant
    System administrators who do not use a particular package should not
    have to read news items which affect purely that package. Some news
    items may be of relevance to most or all users, but those that are
    not should not be forced upon users unnecessarily.

No user subscription required
    It has already been demonstrated [#forums-whining]_ that many users do
    not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A
    solution which requires subscription has no advantage over current
    methods.

No user monitoring required
    It has already been demonstrated [#forums-whining]_ that many users do
    not read news items posted to the Gentoo website, or do not read news
    items until it is too late. A solution that relies upon active
    monitoring of a particular source has no advantage over current
    methods.

No privacy violations
    Users of the solution should not be required to provide information
    about their systems (for example, IP addresses or installed packages).

Preemptive
    Users should be told of changes *before* they break the user's system,
    not after the damage has already been done.

The following characteristics would be desirable:

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

Quality control
    There should be some way to ensure that badly written or irrelevant
    messages are not sent out, for example by inexperienced developers,
    those whose English language skills are below par or morons.

Simple for developers
    Posting news items should be as simple as is reasonably possible.

Simple for users
    Reading relevant news items should be as simple as is reasonably
    possible.

Compatibility with existing news sources
    It would be ideal if a news system could easily be integrated with the
    existing communication methods.

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

The following specification is based upon Stuart's "Favouring an automatic
news mechanism" post [#stuart-blog]_ and discussion on the ``gentoo-dev``
mailing lists [#dev-thread]_ and the ``#gentoo-dev`` IRC channel.

News Item Source
----------------

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

A new directory, ``news/``, will be created in the main tree.  Commit access
to this directory will be handled in the same way as for the rest of the
tree. This directory will contain further subdirectories named
``yyyy-mm/``, where ``yyyy`` is the current year and ``mm`` is the current
month number (01 for January through 12 for December) -- this extra level
of separation will help keep news items more manageable.

Users who really don't care about news items can use ``rsync_excludes`` to
filter out the ``news/`` directory.

.. Note:: The ``profiles/`` directory will *not* be used. This fits in with
   the Portage team's future plans for ``profiles/`` and ``metadata/``
   separation.

Each news item will be represented by a single text file. This file will
be encoded using UTF-8 for compatibility with and for the same reason as
existing Gentoo documentation [#docs-policy]_ and tree [#glep-31]_ practices.

The news item will be named in the form ``yyyy-mm-dd-item-name.en.txt``,
where ``item-name`` is a very short name (e.g. ``apache-updates``) and
``en`` is the two letter ISO 639 [#iso-639]_ language code for the news
item.

The directory and file name rules are designed specifically to allow easy
sorting by date.

An English (``en``) version must be available for all news items. Other
languages may be provided either by the original author or by other
translators who have commit access. This anglocentricity is justified on
the grounds that nobody objected to it with GLEP 34 [#glep-34]_.

News Item File Format
---------------------

A news item will consist of an RFC 822 [#rfc-822]_ style header followed
by the main body of the message as plain text. This GLEP defines various
optional and mandatory headers. Future GLEPs may propose new headers --
tools handling these news items must discard any unrecognised header.

News Item Metadata Headers
''''''''''''''''''''''''''

``Title:``
    A short (maximum 44 characters) descriptive title. Mandatory.
``Author:``
    Author's name and email address, in the form
    ``Real Name <email@address>``. Mandatory, multiple author fields may
    be specified if appropriate.
``Translator:``
    For translated news items, the translator's name and email address.
``Content-Type:``
    Must be ``text/plain``. Mandatory.
``Posted:``
    Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
    Mandatory.
``Version:``
    Initially 1. Incremented every time a non-trivial change is made.
    Changes which require a re-read of the news item should instead use a
    new news item file.

News Item Relevance Headers
'''''''''''''''''''''''''''

If none of the following headers are specified, the news item is aimed at
all users. Otherwise, the news item should only be displayed if at least
one of the criteria matches.

``Display-If-Installed:``
    A dependency atom or simple package name (for example,
    ``<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``. If the user is on
    the arch in question, the news item should be displayed.

TODO: Display-If-USE for USE flag renames?

TODO: Display-If-Mode: ``any`` or ``all`` or ``none`` with ``any`` being
the default?

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 two blank lines.

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

The following hypothetical news item would be placed in
``news/2005-11/2005-11-01-mysql-4.0-4.1-upgrade.en.txt``.

::

    Title: YourSQL Upgrades from 4.0 to 4.1
    Author: Ciaran McCreesh <ciaranm@gentoo.org>
    Content-Type: text/plain
    Posted: 01-Nov-2005
    Display-If-Installed: <dev-db/yoursql-4.1_alpha

    YourSQL databases created using YourSQL version 4.0 are incompatible
    with YourSQL version 4.1 or later. There is no reliable way to
    automate the database format conversion, so action from the system
    administrator is required before an upgrade can take place.

    Please see the Gentoo YourSQL Upgrade Guide for instructions:

        http://www.gentoo.org/doc/en/yoursql-upgrading.xml

    Also see the official YourSQL documentation:

        http://dev.yoursql.com/doc/refman/4.1/en/upgrading-from-4-0.html

    After upgrading, you should also recompile any packages which link
    against YourSQL:

        revdep-rebuild --library=libyoursqlclient.so.12

    The revdep-rebuild tool is provided by app-portage/gentoolkit.

.. Note:: The presence of URLs in a news item does not contradict the "no
    need for a web browser" requirement. Many systems are administered
    remotely, for example over ``ssh``.

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

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

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.

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 and professionalism it is important that any language problems
be corrected before inflicting a news item upon end users.

News Item Display
-----------------

Whenever relevant unread news items are found, ``emerge`` will copy the
news file into ``/var/lib/gentoo/news/``.

TODO: or ``/var/gentoo/news/`` or ``/etc/gentoo/news/``? And make it
overridable by an environment variable?

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: 3 config files in /etc need updating.
    * Type emerge --help config to learn how to update config files.

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

From there, third party tools (or a traditional Unix pager and ``rm``) can
be used to display and view the news files. An ``eselect`` [#eselect]_
module can easily be created as the 'suggested' display tool; other
display tools (for example, a news to email forwarder) are left as options
for those who desire them -- the simple file format make this relatively
simple.

TODO: Implementation detail: what's the easiest way to keep track of
"stuff that has already been copied over" to avoid duplicating news? A
straight list with filtered language codes in a text file is the obvious
solution...

News Item Removal
-----------------

News items can be removed (by removing the news file from the main tree)
when they are no longer relevant, 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 trivial 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 for posting GLSAs to the forums. A
similar tool can be used for these news items.

TODO: reference for the above. or did I just make it it?

Backwards Compatibility
=======================

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

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

TODO

References
==========

.. [#dev-thread] "[gentoo-dev] Getting Important Updates To Users",
    http://marc.theaimsgroup.com/?t=113065837900001&r=1&w=2
.. [#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-whining] Gentoo Forums thread "Gentoo Apache2 Config Change
     Idiocy",
     http://forums.gentoo.org/viewtopic-t-384368.html
.. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
     userlands/kernels/archs", Grant Goodyear,
     http://www.gentoo.org/proj/en/glep/glep-0022.html
.. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
     McCreesh,
     http://www.gentoo.org/proj/en/glep/glep-0031.html
.. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
     http://www.gentoo.org/proj/en/glep/glep-0034.html
.. [#iso-639] ISO 639 "Code for the representation of names of languages"
.. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text
     messages"
.. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert,
     http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism

Credits
=======

Thanks to Brian Harring, Stuart Herbert, Donnie Berkholz, Alec Warner and
Dan Meltzer for input. Some of the ideas presented here are theirs, others
go completely against their suggestions.

Copyright
=========

This document has been placed in the public domain.

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

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

[gentoo-dev] Re: GLEP ??: Critical News Reporting

[Dan Meltzer]

I spoke to you about this in PM, but I think I didn't make it clear,
so here we are :)

WRT links in file updates, this seems completely backwards.  If a user
was admining over ssh, it would be far easier for them to load www.g.o
in their browser vs. copying link from terminal to their browser, but
for that matter, why is ssh relevent wrt links in files, but not when
we are talking about it being lightweight?  If a user is not expected
to have a browser to recieve the news, how can they be expected to
have one to view doc's about it.

Seems like these doc's should just be added to the news, none of them
are _that_ long.

On 10/31/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> The attached GLEP is a draft proposal for the emerge --news thing that's
> been under discussion. There are still some TODO items. These are calls
> for people to weigh in with suggestions. Of course, suggestions on other
> items are good too...
>
> There is currently no explanation as to why this GLEP should be chosen
> over ChrisWhite's 42. I will add such a section if anyone requests it.
>
> Grant, please pick me a number.
>
> I'll post this one to -user and the forums if it survives a round or
> two of being shot at in here first...
>
> --
> Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Brian Harring]

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

On Tue, Nov 01, 2005 at 01:51:25AM +0000, Ciaran McCreesh wrote:
> ``Posted:``
>   Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
>   Mandatory.

Don't have a good arguement as to why it should be added, but utc 
time seems like it should be included.

<snip>

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

You're going to run into issues with slotmoves for longterm...

I'd personally rather the translation/updating of the atoms specified 
for this field does *not* occur in portage clientside, iow it's 
handled server side.

> ``Display-If-Keyword:``
>     A keyword [#glep-22]_ name, for example ``mips``. If the user is on
>     the arch in question, the news item should be displayed.
> 
> TODO: Display-If-USE for USE flag renames?
> 
> TODO: Display-If-Mode: ``any`` or ``all`` or ``none`` with ``any`` being
> the default?

TODO: Display-If-Profile: ?

I'd like to kill off the deprecated profile file someday...


> News Item Display
> -----------------
> 
> Whenever relevant unread news items are found, ``emerge`` will copy the
> news file into ``/var/lib/gentoo/news/``.

Expand this to address N repo's all delivering their own news 
please...

Any reason this must be moved locally?  Why not just track some id 
from the news article locally, instead of copying it?

Yes this makes things a bit more funky for reading tools... but imo, 
the duplication is a bit wasteful.  Not a huge issue, but worth 
considering imo.

~harring

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

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[Brian Harring]

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

On Mon, Oct 31, 2005 at 09:08:19PM -0500, Dan Meltzer wrote:
> I spoke to you about this in PM, but I think I didn't make it clear,
> so here we are :)
> 
> WRT links in file updates, this seems completely backwards.  If a user
> was admining over ssh, it would be far easier for them to load www.g.o
> in their browser vs. copying link from terminal to their browser, but
> for that matter, why is ssh relevent wrt links in files, but not when
> we are talking about it being lightweight?  If a user is not expected
> to have a browser to recieve the news, how can they be expected to
> have one to view doc's about it.

Links would be to guides, and bugs.
Like it or not, that requires a browser... distributing notice of this 
information however does not require a browser.

> Seems like these doc's should just be added to the news, none of them
> are _that_ long.

Guides/docs live on the site; distributing a snapshot of them in a 
news posting is a bad idea... forcing an emerge --sync to get at a doc 
is just plain daft.
~harring

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

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Mon, 31 Oct 2005 21:08:19 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| WRT links in file updates, this seems completely backwards.  If a user
| was admining over ssh, it would be far easier for them to load www.g.o
| in their browser vs. copying link from terminal to their browser, but
| for that matter, why is ssh relevent wrt links in files, but not when
| we are talking about it being lightweight?  If a user is not expected
| to have a browser to recieve the news, how can they be expected to
| have one to view doc's about it.

The user isn't expected to have a browser on the system on which the
news item is being displayed. For example, I have a router box which
does not have lynx or X or anything like that which would still be
generating news item hits -- expecting me to install a browser on that
system to read HTML or XML content is unreasonable. However, admin work
on the router is done over ssh, and it's trivial to copy and paste a
link from the output of some command on a remote box into a firefox
window on my desktop.

Perhaps I should add a note that news items should not simply be of a
"see this link" form, and that any links which are used should only be
for reference, not the primary source...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Mon, 31 Oct 2005 20:16:30 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| On Tue, Nov 01, 2005 at 01:51:25AM +0000, Ciaran McCreesh wrote:
| > ``Posted:``
| >   Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
| >   Mandatory.
| 
| Don't have a good arguement as to why it should be added, but utc 
| time seems like it should be included.

Ok. I nicked the Posting: header from GLEPs, which only use dates. Are
posting times relevant for news items?

| > ``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.
| 
| You're going to run into issues with slotmoves for longterm...
| 
| I'd personally rather the translation/updating of the atoms specified 
| for this field does *not* occur in portage clientside, iow it's 
| handled server side.

Would adding news/ to the "list of stuff that must be changed when you
do a package move" suffice?

| TODO: Display-If-Profile: ?
| 
| I'd like to kill off the deprecated profile file someday...

Ok.

| > News Item Display
| > -----------------
| > 
| > Whenever relevant unread news items are found, ``emerge`` will copy
| > the news file into ``/var/lib/gentoo/news/``.
| 
| Expand this to address N repo's all delivering their own news 
| please...

If we have proper named repos... /var/lib/gentoo/news/repo_name/ ? What
are the plans for multiple repositories exactly?

| Any reason this must be moved locally?  Why not just track some id 
| from the news article locally, instead of copying it?
| 
| Yes this makes things a bit more funky for reading tools... but imo, 
| the duplication is a bit wasteful.  Not a huge issue, but worth 
| considering imo.

I was aiming for "really really easy to write clients that read news",
and "really really easy to read news files using cat or less and rm".

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

[gentoo-dev] Re: GLEP ??: Critical News Reporting

[Dan Meltzer]

That works, I suppose my point was, if you are going to be adminning
from a box with a webbrowser anyways, why not just use that
aforementioned webbrowser to check www.g.o? what is the benefit of
news/ over that?

On 10/31/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Mon, 31 Oct 2005 21:08:19 -0500 Dan Meltzer
> <parallelgrapefruit@gmail.com> wrote:
> | WRT links in file updates, this seems completely backwards.  If a user
> | was admining over ssh, it would be far easier for them to load www.g.o
> | in their browser vs. copying link from terminal to their browser, but
> | for that matter, why is ssh relevent wrt links in files, but not when
> | we are talking about it being lightweight?  If a user is not expected
> | to have a browser to recieve the news, how can they be expected to
> | have one to view doc's about it.
>
> The user isn't expected to have a browser on the system on which the
> news item is being displayed. For example, I have a router box which
> does not have lynx or X or anything like that which would still be
> generating news item hits -- expecting me to install a browser on that
> system to read HTML or XML content is unreasonable. However, admin work
> on the router is done over ssh, and it's trivial to copy and paste a
> link from the output of some command on a remote box into a firefox
> window on my desktop.
>
> Perhaps I should add a note that news items should not simply be of a
> "see this link" form, and that any links which are used should only be
> for reference, not the primary source...
>
> --
> Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Mon, 31 Oct 2005 21:25:29 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| That works, I suppose my point was, if you are going to be adminning
| from a box with a webbrowser anyways, why not just use that
| aforementioned webbrowser to check www.g.o? what is the benefit of
| news/ over that?

It doesn't get ignored.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Brian Harring]

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

On Tue, Nov 01, 2005 at 02:24:40AM +0000, Ciaran McCreesh wrote:
> On Mon, 31 Oct 2005 20:16:30 -0600 Brian Harring <ferringb@gentoo.org>
> wrote:
> | On Tue, Nov 01, 2005 at 01:51:25AM +0000, Ciaran McCreesh wrote:
> | > ``Posted:``
> | >   Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
> | >   Mandatory.
> | 
> | Don't have a good arguement as to why it should be added, but utc 
> | time seems like it should be included.
> 
> Ok. I nicked the Posting: header from GLEPs, which only use dates. Are
> posting times relevant for news items?

Only relevant if you get a sameday version bump for a news item, which 
shouldn't occur, but stupid stuff does occur.

Like I said, don't have a good "you must do it cause of x" reason, 
just a gut feeling it should be there.


> | > ``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.
> | 
> | You're going to run into issues with slotmoves for longterm...
> | 
> | I'd personally rather the translation/updating of the atoms specified 
> | for this field does *not* occur in portage clientside, iow it's 
> | handled server side.
> 
> Would adding news/ to the "list of stuff that must be changed when you
> do a package move" suffice?

Manual labor == potential for screwup. :)

Should be automatic serverside im, just for the sake of older news 
items still pointing to appropriate location of a package.


> | > News Item Display
> | > -----------------
> | > 
> | > Whenever relevant unread news items are found, ``emerge`` will copy
> | > the news file into ``/var/lib/gentoo/news/``.
> | 
> | Expand this to address N repo's all delivering their own news 
> | please...
> 
> If we have proper named repos... /var/lib/gentoo/news/repo_name/ ? What
> are the plans for multiple repositories exactly?

You'd have to clarify;
Repositories will be labeled by user configuration, but that's a bad 
bit of data to use for /var/lib/gentoo/news/$REPO imo.

Some unique id/label bound with the repo maybe?  and yes... bit of 
overkill, but it's also useful for tracking where/which repo an ebuild 
was installed from.


One thing this glep is missing, and needs to address is signing of the 
news also.  Detached sig probably is best route for the keep it 
simple route you're going.

~harring

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

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[Alec Warner]

Dan Meltzer wrote:
> That works, I suppose my point was, if you are going to be adminning
> from a box with a webbrowser anyways, why not just use that
> aforementioned webbrowser to check www.g.o? what is the benefit of
> news/ over that?
So you are going to tell www.g.o what your installed system is so it can
filter relevant news for you?  Or do you want to read news on all 10,000
packages?  I certainly don't want to swim through all the crappy news
just to find the items relevant for the box that I'm on.

-Alec Warner (Antarus)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[pclouds]

[quote]
All proposed news items must be posted to the ``gentoo-dev`` or
``gentoo-core`` mailing list, and ``Cc:``\ed to ``pr@gentoo.org`` at least
72 hours before being committed (exceptions may be made in exceptional
circumstances). Any complaints regarding wording or clarity **must** be
addressed before the news item goes live.
[/quote]
Once english versions passed this process will their translations need
to be sent to gentoo-dev and pr@? I would propose delegate those cases
to gentoo doc team.
--
Bi Cờ Lao

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Wernfried Haas]

On Tue, Nov 01, 2005 at 01:51:25AM +0000, Ciaran McCreesh wrote:
> There is currently no explanation as to why this GLEP should be chosen
> over ChrisWhite's 42. I will add such a section if anyone requests it.
Any reason why you chose bashing Chris' GLEP in another mail and start
your own instead of working together and bringing your input for 42?

> Lightweight
>     It is not reasonable to expect all users to have an MTA, web browser,
>     email client, cron daemon or text processing suite available on their
>     system. In particular, this means that any markup to be parsed must be
>     in a very simple format.
I think i have an idea where this is going...
Don't you already have some GLEP saying XML sucks?

I miss references to the old log ewarn issue, which really should be
solved as well while we're at it.

There are some good ideas in your GLEP, so are some in Chris'. No good
is coming from having two similar GLEPs around at the same
time. So please don't waste our time [1] by having two more or less
redundant GLEPs discussed.

cheers,
	Wernfried

[1] http://dev.gentoo.org/~chriswhite/flame.html Code listing 1.6


-- 
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] Re: GLEP ??: Critical News Reporting

[Duncan]

Ciaran McCreesh posted <20051101015125.1cc45eb4@snowdrop.home>, excerpted
below,  on Tue, 01 Nov 2005 01:51:25 +0000:

> ``Version:``
>     Initially 1. Incremented every time a non-trivial change is made.
>     Changes which require a re-read of the news item should instead use a
>     new news item file.

Very good work!

This "Version" field calls to mind the MIMEVersion spec, and the ebuild
version proposal, only here it's apparently used for news-item version.

I'd suggest we preemptively incorporate an ENewsVersion or similar field
as well, to be 1.0, with this proposal, but should the format ever need
changed, that would allow for a format version 1.1 or 2.0 or whatever.  As
the GLEP suggests that future GLEPs may add new headers, this would allow
them to update this version field as necessary, presumably using the
familiar minor version = backward compatible, major version if not
backward compatible, versioning scheme.

You are very good at laying everything out in a just so spec, so I'll
leave it to you to provide specific wording.  =8^)

One other niggle.  The encoding is specified as UTF-8, but then the format
is specified as RFC-822 (7-bit ASCII, pre-i18n) compatible.  I'm not up
on i18n specs, but presumably there's a newer RFC that specifies how
internationalized internet messages are handled in an RFC-822 backward
compatible way? If so, it may make more sense to reference that specific
RFC, which presumably deals with UTF-8 instead of specifying 7-bit ASCII
as does 822. Alternatively, MIME/Quoted-printable could be specified,
which would allow for escaped 8-bit chars, as I'd /assume/ UTF-8
requires, given the -8. (I /said/ I'm not up on that!)

-- 
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 ??: Critical News Reporting

[Thierry Carrez]

Ciaran McCreesh wrote:

> Preemptive
>     Users should be told of changes *before* they break the user's system,
>     not after the damage has already been done.

I think that's one of the key points...

> 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: 3 config files in /etc need updating.
>     * Type emerge --help config to learn how to update config files.
> 
>     * Important: there are 5 unread news items.
>     * Type emerge --help news to learn how to read news files.

Aren't those messages displayed after the damage is done ? Typical use :

- emerge --sync run as a daily cron job
- emerge -a mysql
- great, a new version is there. Typing "Yes"
- system gets borken
- emerge spits out message saying 14 files need updating and there is 1
unread news item

I'm probably missing something here. Please elaborate on how this GLEP
meets the "Preemptive" design goal...

-- 
Thierry Carrez (Koon)
Gentoo Council Member
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting

[Jakub Moc]

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


1.11.2005, 11:00:22, Thierry Carrez wrote:

> Aren't those messages displayed after the damage is done ? Typical use :

> - emerge --sync run as a daily cron job
> - emerge -a mysql
> - great, a new version is there. Typing "Yes"
> - system gets borken
> - emerge spits out message saying 14 files need updating and there is 1
> unread news item

> I'm probably missing something here. Please elaborate on how this GLEP
> meets the "Preemptive" design goal...


I'm probably missing something obvious here, because I can't see why *existing*
emerge --changelog code cannot be recycled for this feature to display upgrade
messages when running emerge -uDav world...


-- 
Best regards,

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

 ... still no signature ;)

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[John Myers]

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

On Tuesday 01 November 2005 02:00, Thierry Carrez wrote:
> Ciaran McCreesh wrote:
> > 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: 3 config files in /etc need updating.
> >     * Type emerge --help config to learn how to update config files.
> >
> >     * Important: there are 5 unread news items.
> >     * Type emerge --help news to learn how to read news files.
>
> Aren't those messages displayed after the damage is done ? Typical use :
>
> - emerge --sync run as a daily cron job
> - emerge -a mysql
> - great, a new version is there. Typing "Yes"
> - system gets borken
> - emerge spits out message saying 14 files need updating and there is 1
> unread news item
>
> I'm probably missing something here. Please elaborate on how this GLEP
> meets the "Preemptive" design goal...
The "configuration files need updating" messages also appear at the end of 
emerge sync

Also, perhaps the news messages could be put at both ends of the emerge 
output?

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 09:25:34 +0100 Wernfried Haas <amne@gentoo.org>
wrote:
| On Tue, Nov 01, 2005 at 01:51:25AM +0000, Ciaran McCreesh wrote:
| > There is currently no explanation as to why this GLEP should be
| > chosen over ChrisWhite's 42. I will add such a section if anyone
| > requests it.
| Any reason why you chose bashing Chris' GLEP in another mail and start
| your own instead of working together and bringing your input for 42?

Yup. I already had most of my GLEP written, and I don't see anything in
ChrisWhite's list of vagueness worth using. Besides, there's nothing
wrong with multiple competing GLEPs on an issue.

| I miss references to the old log ewarn issue, which really should be
| solved as well while we're at it.

Separate concern.

| There are some good ideas in your GLEP, so are some in Chris'. No good
| is coming from having two similar GLEPs around at the same
| time. So please don't waste our time [1] by having two more or less
| redundant GLEPs discussed.

It's my view that ChrisWhite's GLEP is a complete waste of space, given
that it doesn't contain an actual proposal. I see no point in using it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 01 Nov 2005 11:00:22 +0100 Thierry Carrez <koon@gentoo.org>
wrote:
| I'm probably missing something here. Please elaborate on how this GLEP
| meets the "Preemptive" design goal...

Simple. emerge --sync displays the "you have 12 unread news items"
message after it's done. The only changes which can't be preempted here
are the kind which completely break rsync...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Georgi Georgiev]

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

maillog: 01/11/2005-11:45:08(+0100): Jakub Moc types
> 1.11.2005, 11:00:22, Thierry Carrez wrote:
> 
> > Aren't those messages displayed after the damage is done ? Typical use :
> 
> > - emerge --sync run as a daily cron job
> > - emerge -a mysql
> > - great, a new version is there. Typing "Yes"
> > - system gets borken
> > - emerge spits out message saying 14 files need updating and there is 1
> > unread news item
> 
> > I'm probably missing something here. Please elaborate on how this GLEP
> > meets the "Preemptive" design goal...
> 
> 
> I'm probably missing something obvious here, because I can't see why *existing*
> emerge --changelog code cannot be recycled for this feature to display upgrade
> messages when running emerge -uDav world...

That reminds me of the idea to stick tags in the ChangeLog:
http://groups.google.com/group/linux.gentoo.dev/msg/8f2dc84619be5c5b?fwc=1

But still, I'm guessing the idea of "--news" is to tell people that they
need to do something A.S.A.P. This means as soon as the news are
obtained, and the users are nagged about the news on *every invocation
of emerge*, similar to the /etc messages, and not only when they decide
to install some package, which is when --changelog kicks in.

And then, I am not sure why glsa-check cannot do the same job...

-- 
()   Georgi Georgiev   () Computers are unreliable, but humans are   ()
()    chutz@gg3.net    () even more unreliable. Any system which     ()
() http://www.gg3.net/ () depends on human reliability is            ()
() ------------------- () unreliable. -- Gilb                        ()

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Thierry Carrez]

Ciaran McCreesh wrote:
> On Tue, 01 Nov 2005 11:00:22 +0100 Thierry Carrez <koon@gentoo.org>
> wrote:
> | I'm probably missing something here. Please elaborate on how this GLEP
> | meets the "Preemptive" design goal...
> 
> Simple. emerge --sync displays the "you have 12 unread news items"
> message after it's done. The only changes which can't be preempted here
> are the kind which completely break rsync...

That won't save those following the example I gave:

Thierry Carrez wrote:
> - emerge --sync run as a daily cron job
> - emerge -a mysql
> - great, a new version is there. Typing "Yes"
> - system gets borken
> - emerge spits out message saying 14 files need updating and there is 1
> unread news item

For them to know about it, they need to be warned when they do their
"emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
as it seems. People using a cron job to sync are probably a significant
part of our user base...

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

[gentoo-dev] Re: GLEP ??: Critical News Reporting

[Dan Meltzer]

Two things.

One, if users run --sync in a cronjob, which many do, this preemptive
goes out the window.

Two, an alternative to that, if we are all recoding portage anyways :)
 Have portage place a special note next to any items with relevent
news when -a or -p is passed, and then, emerge --news cat/package
could show relvent stuff, or --news to see it all.

On 11/1/05, Georgi Georgiev <chutz@gg3.net> wrote:
> maillog: 01/11/2005-11:45:08(+0100): Jakub Moc types
> > 1.11.2005, 11:00:22, Thierry Carrez wrote:
> >
> > > Aren't those messages displayed after the damage is done ? Typical use
> :
> >
> > > - emerge --sync run as a daily cron job
> > > - emerge -a mysql
> > > - great, a new version is there. Typing "Yes"
> > > - system gets borken
> > > - emerge spits out message saying 14 files need updating and there is 1
> > > unread news item
> >
> > > I'm probably missing something here. Please elaborate on how this GLEP
> > > meets the "Preemptive" design goal...
> >
> >
> > I'm probably missing something obvious here, because I can't see why
> *existing*
> > emerge --changelog code cannot be recycled for this feature to display
> upgrade
> > messages when running emerge -uDav world...
>
> That reminds me of the idea to stick tags in the ChangeLog:
> http://groups.google.com/group/linux.gentoo.dev/msg/8f2dc84619be5c5b?fwc=1
>
> But still, I'm guessing the idea of "--news" is to tell people that they
> need to do something A.S.A.P. This means as soon as the news are
> obtained, and the users are nagged about the news on *every invocation
> of emerge*, similar to the /etc messages, and not only when they decide
> to install some package, which is when --changelog kicks in.
>
> And then, I am not sure why glsa-check cannot do the same job...
>
> --
> ()   Georgi Georgiev   () Computers are unreliable, but humans are   ()
> ()    chutz@gg3.net    () even more unreliable. Any system which     ()
> () http://www.gg3.net/ () depends on human reliability is            ()
> () ------------------- () unreliable. -- Gilb                        ()
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 01 Nov 2005 02:21:31 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| I'd suggest we preemptively incorporate an ENewsVersion or similar
| field as well, to be 1.0, with this proposal, but should the format
| ever need changed, that would allow for a format version 1.1 or 2.0
| or whatever.  As the GLEP suggests that future GLEPs may add new
| headers, this would allow them to update this version field as
| necessary, presumably using the familiar minor version = backward
| compatible, major version if not backward compatible, versioning
| scheme.

Sounds reasonable.

| One other niggle.  The encoding is specified as UTF-8, but then the
| format is specified as RFC-822 (7-bit ASCII, pre-i18n) compatible.
| I'm not up on i18n specs, but presumably there's a newer RFC that
| specifies how internationalized internet messages are handled in an
| RFC-822 backward compatible way? If so, it may make more sense to
| reference that specific RFC, which presumably deals with UTF-8
| instead of specifying 7-bit ASCII as does 822. Alternatively,
| MIME/Quoted-printable could be specified, which would allow for
| escaped 8-bit chars, as I'd /assume/ UTF-8 requires, given the -8.
| (I /said/ I'm not up on that!)

Hrm. The "RFC-822 like" phrase is used in various places (for example,
the GLEP specification) to describe the structure of the header
section. I don't think it precludes us also specifying UTF-8.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez <koon@gentoo.org>
wrote:
| For them to know about it, they need to be warned when they do their
| "emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
| as it seems. People using a cron job to sync are probably a
| significant part of our user base...

Have Portage give a red flashy before emerge if there're unread news
items?

Although, a better solution for users who cron sync would be to have
said cron mail them all the relevant news files...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting

[Jakub Moc]

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


1.11.2005, 13:26:57, Ciaran McCreesh wrote:

> On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez <koon@gentoo.org>
> wrote:
> | For them to know about it, they need to be warned when they do their
> | "emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
> | as it seems. People using a cron job to sync are probably a
> | significant part of our user base...

> Have Portage give a red flashy before emerge if there're unread news
> items?

> Although, a better solution for users who cron sync would be to have
> said cron mail them all the relevant news files...

Uhm... emerge sync is a *bad* time to display upgrade messages, it's simply
irrelevant at that time, I'm not upgrading anything at the moment and might not
be upgrading for next week or so.

The messages should be displayed when I'm about to upgrade an ebuild which has
an upgrade note associated with the new version. Sending mail via cron might be
a nice optional feature for those who want to use it.

-- 
Best regards,

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

 ... still no signature ;)

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 13:39:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| Uhm... emerge sync is a *bad* time to display upgrade messages, it's
| simply irrelevant at that time, I'm not upgrading anything at the
| moment and might not be upgrading for next week or so.

It doesn't display the messages. It displays a note saying "you have
unread news items".

| The messages should be displayed when I'm about to upgrade an ebuild
| which has an upgrade note associated with the new version. Sending
| mail via cron might be a nice optional feature for those who want to
| use it.

Not really a good idea, a) because news items aren't tied directly to
ebuilds, and b) because people like advance warning of "when you
upgrade Apache, all hell will break loose!" rather than having it
sprung on them suddenly when they're trying to do a quick update.
Getting the news item in advance allows for planning.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting

[Jakub Moc]

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


1.11.2005, 13:48:06, Ciaran McCreesh wrote:

> | The messages should be displayed when I'm about to upgrade an ebuild
> | which has an upgrade note associated with the new version. Sending
> | mail via cron might be a nice optional feature for those who want to
> | use it.

> Not really a good idea, a) because news items aren't tied directly to
> ebuilds, and b) because people like advance warning of "when you
> upgrade Apache, all hell will break loose!" rather than having it
> sprung on them suddenly when they're trying to do a quick update.
> Getting the news item in advance allows for planning.

What do you mean "they aren't tied to ebuilds"? I don't really understand what
this feature should do then, it seems. Once again, what's wrong with reusing
emerge --changelog mechanism for displaying this kind of information?

I'm not particularly happy with idea of emerge as a newsreader really, IMHO we
should display relevant, vital upgrading information *when relevant*, not to
inform users about upgrades that they are not interested in in the least.
Example: Don't bother me with mysql-4.1 upgrade instructions, I don't plan to
upgrade to that version and did put it into package.mask. Another example:
Don't bother me with upgrade instructions for ~arch ebuilds, I'm running
stable. I want to read them when I decide to upgrade, put them into
package.keywords and run emerge -uav someebuild/world or when it goes stable.

And please, keep the thing simple so that I can be done in reasonable amount of
time and does not follow the destiny of einfo/ewarn logging (3 years and
counting).


-- 
Best regards,

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

 ... still no signature ;)

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Alec Warner]

Ciaran McCreesh wrote:

>On Tue, 1 Nov 2005 13:39:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
>| Uhm... emerge sync is a *bad* time to display upgrade messages, it's
>| simply irrelevant at that time, I'm not upgrading anything at the
>| moment and might not be upgrading for next week or so.
>
>It doesn't display the messages. It displays a note saying "you have
>unread news items".
>
>| The messages should be displayed when I'm about to upgrade an ebuild
>| which has an upgrade note associated with the new version. Sending
>| mail via cron might be a nice optional feature for those who want to
>| use it.
>
>Not really a good idea, a) because news items aren't tied directly to
>ebuilds, and b) because people like advance warning of "when you
>upgrade Apache, all hell will break loose!" rather than having it
>sprung on them suddenly when they're trying to do a quick update.
>Getting the news item in advance allows for planning.
>
>  
>
Personally, I'm for both.  E-mailing cron output is a relatively simple 
operation.  Adding a red flashy deal to emerge saying hey, package X has 
an unread news item, also simple as long as the read/unread format is 
non-complex.  Having emerge --news, I dislike emmensely.  We have emerge 
--changelog, and contrary to what someone posted above, it shows up 
whenever you specify -l.  However changelog does have it's fair share of 
problems, mostly people who don't use the correct changelog format and 
break the tagging, causing -l to display nothing.

If you want to make a seperate program to read the news, go for it.  I 
don't see why we have to stick silly things in a core utility.  emerge 
is a package manager, it does not do your laundry too.

-Alec Warner (Antarus)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 01 Nov 2005 08:34:25 -0500 Alec Warner <warnera6@egr.msu.edu>
wrote:
| Personally, I'm for both.  E-mailing cron output is a relatively
| simple operation.  Adding a red flashy deal to emerge saying hey,
| package X has an unread news item, also simple as long as the
| read/unread format is non-complex.

Checking for unread news items is just a case of checking for the
existence of files in a particular directory.

| If you want to make a seperate program to read the news, go for it.
| I don't see why we have to stick silly things in a core utility.
| emerge is a package manager, it does not do your laundry too.

Well, I see no reason for Portage itself doing anything beyond basic
news message filtering and installing and alerting that there are
unread news messages.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Andrej Kacian]

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

On Tue, 1 Nov 2005 01:51:25 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> The attached GLEP is a draft proposal for the emerge --news thing that's
> been under discussion. There are still some TODO items. These are calls
> for people to weigh in with suggestions. Of course, suggestions on other
> items are good too...

Before this, make pre-install and post-install emerge messages more usable,
instead of having them lost among thousands of gibberish text in batch emerges.

-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

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

Re: Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Tuesday 01 November 2005 13:39, Jakub Moc wrote:
> Uhm... emerge sync is a *bad* time to display upgrade messages, it's
> simply irrelevant at that time, I'm not upgrading anything at the
> moment and might not be upgrading for next week or so.

If you are not upgrading anything the news is not relevant for you anyway. 
The news is to accompany changes to the tree. 

> The messages should be displayed when I'm about to upgrade an ebuild
> which has an upgrade note associated with the new version. Sending mail
> via cron might be a nice optional feature for those who want to use it.

I agree that it might be usefull to allways declare the related 
package(s). Even when the message is not restricted to them.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Tuesday 01 November 2005 02:51, Ciaran McCreesh wrote:
> The attached GLEP is a draft proposal for the emerge --news thing
> that's been under discussion. There are still some TODO items. These
> are calls for people to weigh in with suggestions. Of course,
> suggestions on other items are good too...
>
> There is currently no explanation as to why this GLEP should be chosen
> over ChrisWhite's 42. I will add such a section if anyone requests it.
>
> Grant, please pick me a number.
>

I have one suggestion on an added header. I think that an Overrides: 
header should be added. This is for those messages that make a previous 
message obsolete. Say for example that an upgrade guide to modular X was 
posted, but that a critical error was made in it. This was fixed, and to 
make sure that people read the new message, it is not a higher version.

It is however not a good idea to have people then read the old message 
when the new message is there.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Christian Birchinger]

On Tue, Nov 01, 2005 at 02:54:51PM +0100, Andrej Kacian wrote:
> On Tue, 1 Nov 2005 01:51:25 +0000
> Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> 
> > The attached GLEP is a draft proposal for the emerge --news thing that's
> > been under discussion. There are still some TODO items. These are calls
> > for people to weigh in with suggestions. Of course, suggestions on other
> > items are good too...
> 
> Before this, make pre-install and post-install emerge messages more usable,
> instead of having them lost among thousands of gibberish text in batch emerges.
> 

I always ask myself what's wrong with doing a simple "if"
statement before displaying infos, warnings or errors which
don't affect the current installaion.

No one complained when i started doing that ages ago in
bash-completion.

I don't mean huge and resource hungry tests. But why tell the
user that he should remove a file in /etc with einfo when it
doesn't even exist? (That's just an example)

Some ebuilds do this now, but most still broadcast (sometimes
huge) text floods.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Tue, 2005-11-01 at 12:26 +0000, Ciaran McCreesh wrote:
> On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez <koon@gentoo.org>
> wrote:
> | For them to know about it, they need to be warned when they do their
> | "emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
> | as it seems. People using a cron job to sync are probably a
> | significant part of our user base...
> 
> Have Portage give a red flashy before emerge if there're unread news
> items?

Or have it die unless they have
I_LIKE_A_BROKEN_SYSTEM_PLEASE_IGNORE_NEWS="yes" in make.conf.... ;]

> Although, a better solution for users who cron sync would be to have
> said cron mail them all the relevant news files...

We don't have control over what they do in cron, we do have control over
portage itself.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Tuesday 01 of November 2005 02:51 Ciaran McCreesh wrote:
[...]

What's wrong with XML format similar to the one that is used for our GLSAs? 
Are there any advantages in using yet-another-markup-system while we already 
have some XML-parsing code in `glsa-check` which does similar job?

(IMHO arguments like "Portage shouldn't contain XML-parsing code" doesn't 
count as there are plans to integrate GLSA checking into Portage (aka `emerge 
--security`).)

TIA,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 14:32:47 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| What do you mean "they aren't tied to ebuilds"? I don't really
| understand what this feature should do then, it seems. Once again,
| what's wrong with reusing emerge --changelog mechanism for displaying
| this kind of information?

We make changes that have scope other than ebuilds.

| I'm not particularly happy with idea of emerge as a newsreader
| really, IMHO we should display relevant, vital upgrading information
| *when relevant*, not to inform users about upgrades that they are not
| interested in in the least.

Which is what my proposed GLEP does, at least as far as we can
determine automatically. Yes, occasionally this will mean giving, say,
mysql 4.1 upgrade instructions to people who plan to use only mysql
4.0, but then, if we didn't give them the news, most of them wouldn't
know that they don't want to upgrade.

And it doesn't turn emerge into a news reader. All portage does is
deliver the news. How said news is read is a different issue.

| And please, keep the thing simple so that I can be done in reasonable
| amount of time and does not follow the destiny of einfo/ewarn logging
| (3 years and counting).

Of course. Hence why I'm proposing something easy and workable, and not
suggesting some magic new framework that will solve all existing
problems (including world peace).

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 14:54:51 +0100 Andrej Kacian <ticho@gentoo.org>
wrote:
| On Tue, 1 Nov 2005 01:51:25 +0000
| Ciaran McCreesh <ciaranm@gentoo.org> wrote:
| > The attached GLEP is a draft proposal for the emerge --news thing
| > that's been under discussion. There are still some TODO items.
| > These are calls for people to weigh in with suggestions. Of course,
| > suggestions on other items are good too...
| 
| Before this, make pre-install and post-install emerge messages more
| usable, instead of having them lost among thousands of gibberish text
| in batch emerges.

Separate issue. That one's the whole elog thing.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
| What's wrong with XML format similar to the one that is used for our
| GLSAs?

1. Portage does not handle XML. Portage will not handle XML in the
near future.

2. Many users do not have an XML parser installed.

3. The standard Unix tools cannot be used on XML files.

4. Bloat.

5. XML is merely adding another problem to the one we have already.

There is no XML in this GLEP for the same reasons that there is no
Java, CORBA, EJBs, web services, on demand computing initiatives or
invisible pink unicorns.

I have an eselect module which can read these news files. The whole
thing is about the same size as the DTD would need to be for an
XML-based solution. I have a parser written for the format in question.
The whole thing is smaller than the initialisation code for an off the
shelf XML parser.

It's not a question of "what's wrong with XML?". It's a question of
"what advantage would we gain by strapping a giant flapping wet kipper
to a bicycle?".

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 15:16:27 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| I have one suggestion on an added header. I think that an Overrides: 
| header should be added. This is for those messages that make a
| previous message obsolete. Say for example that an upgrade guide to
| modular X was posted, but that a critical error was made in it. This
| was fixed, and to make sure that people read the new message, it is
| not a higher version.
| 
| It is however not a good idea to have people then read the old
| message when the new message is there.

Hrm. The advantage of this over simply removing the old news item is
that it'll work if the user keeps unread messages around between
multiple syncs. The disadvantage is that it makes the implementation a
bit trickier. Opinions on the tradeoff?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Andrej Kacian]

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

On Tue, 1 Nov 2005 18:18:55 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> | Before this, make pre-install and post-install emerge messages more
> | usable, instead of having them lost among thousands of gibberish text
> | in batch emerges.
> 
> Separate issue. That one's the whole elog thing.

Yes, it is a separate issue, but it's an issue that's been around for far too
long, and seems to be ignored, despite the apparent importance of emerge
messages for users.

-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Stuart Herbert]

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

Thanks for this.  Even if nothing comes of it, I appreciate the help!

Best regards,
Stu
--
On Tue, 2005-11-01 at 01:51 +0000, Ciaran McCreesh wrote:
> The attached GLEP is a draft proposal for the emerge --news thing that's
> been under discussion. There are still some TODO items. These are calls
> for people to weigh in with suggestions. Of course, suggestions on other
> items are good too...
> 
> There is currently no explanation as to why this GLEP should be chosen
> over ChrisWhite's 42. I will add such a section if anyone requests it.
> 
> Grant, please pick me a number.
> 
> I'll post this one to -user and the forums if it survives a round or
> two of being shot at in here first...
> 
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Alec Joseph Warner]

Andrej Kacian wrote:
> On Tue, 1 Nov 2005 18:18:55 +0000
> Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> 
> 
>>| Before this, make pre-install and post-install emerge messages more
>>| usable, instead of having them lost among thousands of gibberish text
>>| in batch emerges.
>>
>>Separate issue. That one's the whole elog thing.
> 
> 
> Yes, it is a separate issue, but it's an issue that's been around for far too
> long, and seems to be ignored, despite the apparent importance of emerge
> messages for users.
> 

http://search.gmane.org/search.php?group=gmane.linux.gentoo.portage.devel&query=elog

The first 7 or 8 results should about cut it.  As for it taking forever, 
code doesn't write itself, and 1000's of whining users/devs don't get 
code written either.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Grant Goodyear]

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

Andrej Kacian wrote: [Tue Nov 01 2005, 01:20:54PM CST]
> > Separate issue. That one's the whole elog thing.
> 
> Yes, it is a separate issue, but it's an issue that's been around for far too
> long, and seems to be ignored, despite the apparent importance of emerge
> messages for users.

That seems a bit unfair to me.  There's a complete logging facility in
portage CVS for a version that's probably not going to be released, but
I believe that the logging stuff is being back-ported to the current
version of portage.  (Moreover, I would argue that this issue was never
ignored, but it often wasn't at the top of the list for what our limited
portage devs should be working on: see
http://bugs.gentoo.org/show_bug.cgi?id=11359#c83 .)

-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] GLEP ??: Critical News Reporting

[Andrej Kacian]

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

On Tue, 1 Nov 2005 13:44:17 -0600
Grant Goodyear <g2boojum@gentoo.org> wrote:

> That seems a bit unfair to me.  There's a complete logging facility in
> portage CVS for a version that's probably not going to be released, but
> I believe that the logging stuff is being back-ported to the current
> version of portage.  (Moreover, I would argue that this issue was never
> ignored, but it often wasn't at the top of the list for what our limited
> portage devs should be working on: see
> http://bugs.gentoo.org/show_bug.cgi?id=11359#c83 .)

It seems I was misinformed about this. My apologies to anyone working on this
rather vital portage feature.

-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Tuesday 01 of November 2005 19:25 Ciaran McCreesh wrote:
> On Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
> | What's wrong with XML format similar to the one that is used for our
> | GLSAs?
>
> 1. Portage does not handle XML. Portage will not handle XML in the
> near future.

How will it handle GLSAs then? [1]

> 5. XML is merely adding another problem to the one we have already.

Could you please explain?

> There is no XML in this GLEP for the same reasons that there is no
> Java, CORBA, EJBs, web services, on demand computing initiatives or
> invisible pink unicorns.

I'm not sure if our GLSAs use PHP, ODBC, ASP, SOAP, computer grids or 
invisible pink unicorns while I'm pretty sure they do use XML.

> I have an eselect module which can read these news files. The whole
> thing is about the same size as the DTD would need to be for an
> XML-based solution. I have a parser written for the format in question.
> The whole thing is smaller than the initialisation code for an off the
> shelf XML parser.

Great. Why haven't you just used existing code from `glsa-check`, BTW?

> It's not a question of "what's wrong with XML?". It's a question of
> "what advantage would we gain by strapping a giant flapping wet kipper
> to a bicycle?".

Or (a little bit rephrased) "why should we stick with consistent file 
formats".

[1] http://www.gentoo.org/proj/en/portage/glsa-integration.xml

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 22:57:13 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
| On Tuesday 01 of November 2005 19:25 Ciaran McCreesh wrote:
| > On Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <jkt@gentoo.org>
| > wrote:
| > | What's wrong with XML format similar to the one that is used for
| > | our GLSAs?
| >
| > 1. Portage does not handle XML. Portage will not handle XML in the
| > near future.
| 
| How will it handle GLSAs then? [1]

gentoolkit != portage.

| > 5. XML is merely adding another problem to the one we have already.
| 
| Could you please explain?

Parsing XML is complicated. Writing XML is complicated. I put together
a complete working client that can show news items in the plain text
format proposed -- it took me fifteen minutes to write. I threw
together a script which can be called after a cron sync that mails news
items to root in under a minute. There is no way this could be done if
XML were being used -- any task involving news items would be a major
chore.

| > There is no XML in this GLEP for the same reasons that there is no
| > Java, CORBA, EJBs, web services, on demand computing initiatives or
| > invisible pink unicorns.
| 
| I'm not sure if our GLSAs use PHP, ODBC, ASP, SOAP, computer grids or 
| invisible pink unicorns while I'm pretty sure they do use XML.

And? Why repeat previous mistakes?

| > I have an eselect module which can read these news files. The whole
| > thing is about the same size as the DTD would need to be for an
| > XML-based solution. I have a parser written for the format in
| > question. The whole thing is smaller than the initialisation code
| > for an off the shelf XML parser.
| 
| Great. Why haven't you just used existing code from `glsa-check`, BTW?

Because merely figuring out the XML DTD takes longer than it does to
write an entire client for plain text news items.

| > It's not a question of "what's wrong with XML?". It's a question of
| > "what advantage would we gain by strapping a giant flapping wet
| > kipper to a bicycle?".
| 
| Or (a little bit rephrased) "why should we stick with consistent file 
| formats".

Uh, you'd have to invent a load of new XML DTD stuff for this anyway.
So you're not using a consistent file format at all, you're just using
a consistent unnecessary layer in the middle, which as a side effect
makes your files incompatible with every standard Unix tool ever
written.

Using XML does not magically make things compatible. XML is just a
layer in the middle. Any tool processing XML files still has to worry
about however the DTD in question works.

You think XML magically makes things compatible? Then I suggest you
write a GuieXML to Docbook conversion tool, and see how many thousand
lines of XSLT it takes. All XML does is move the conversion and parsing
problems to a different, more complex level.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Tue, 1 Nov 2005 19:29:59 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| Come on now, this is a bit of bullshit.
| http://dev.gentoo.org/~ferringb/portage_metadata.py,
| 47 lines
| 
| Might be a pain in the ass under the frameworks you deal in, but 
| something as simple as news items can be done pretty quickly.

Pfff, now come up with some code that simply emails plain text versions
of news items to the root user. It's four lines of bash if you don't
bring XML into it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Brian Harring]

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

On Tue, Nov 01, 2005 at 10:16:35PM +0000, Ciaran McCreesh wrote:
> On Tue, 1 Nov 2005 22:57:13 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
> | On Tuesday 01 of November 2005 19:25 Ciaran McCreesh wrote:
> | > On Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <jkt@gentoo.org>
> | > wrote:
> | > | What's wrong with XML format similar to the one that is used for
> | > | our GLSAs?
> | >
> | > 1. Portage does not handle XML. Portage will not handle XML in the
> | > near future.
> | 
> | How will it handle GLSAs then? [1]
> 
> gentoolkit != portage.
Correct.  Course, also incorrect.

We already have a module for parsing metadata.xml in use in the 
experimental 2.1 branch (which can be backported to 2.0 if anyone 
wants it and does the work).

Python comes bundled with xml as long as you don't have the build flag 
enabled.



> | > 5. XML is merely adding another problem to the one we have already.
> | 
> | Could you please explain?
> 
> Parsing XML is complicated. Writing XML is complicated. I put together
> a complete working client that can show news items in the plain text
> format proposed -- it took me fifteen minutes to write. I threw
> together a script which can be called after a cron sync that mails news
> items to root in under a minute. There is no way this could be done if
> XML were being used -- any task involving news items would be a major
> chore.

Come on now, this is a bit of bullshit.
http://dev.gentoo.org/~ferringb/portage_metadata.py,
47 lines

Might be a pain in the ass under the frameworks you deal in, but 
something as simple as news items can be done pretty quickly.

> | > I have an eselect module which can read these news files. The whole
> | > thing is about the same size as the DTD would need to be for an
> | > XML-based solution. I have a parser written for the format in
> | > question. The whole thing is smaller than the initialisation code
> | > for an off the shelf XML parser.
> | 
> | Great. Why haven't you just used existing code from `glsa-check`, BTW?
> 
> Because merely figuring out the XML DTD takes longer than it does to
> write an entire client for plain text news items.

Not arguing for, or against, just pointing out certain arguements are 
questionable...
~harring

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Michiel de Bruijne]

On Wednesday 02 November 2005 02:29, Brian Harring wrote:
> On Tue, Nov 01, 2005 at 10:16:35PM +0000, Ciaran McCreesh wrote:

> > | How will it handle GLSAs then? [1]
> >
> > gentoolkit != portage.
>
> Correct.  Course, also incorrect.

A plan for handling GLSA's from portage (emerge --security) was announced some 
time ago. Is this still planned (i.o.w. portage handling xml)?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Tue, 2005-11-01 at 19:29 -0600, Brian Harring wrote:
> We already have a module for parsing metadata.xml in use in the 
> experimental 2.1 branch (which can be backported to 2.0 if anyone 
> wants it and does the work).
> 
> Python comes bundled with xml as long as you don't have the build flag 
> enabled.

Translation: it won't work on a stage1 tarball, but will work any time
after bootstrap.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Tuesday 01 of November 2005 23:16 Ciaran McCreesh wrote:
> | How will it handle GLSAs then? [1]
>
> gentoolkit != portage.

To quote GLEP 14 [1]:

"Once this tool is implemented and well tested it can be integrated into 
portage."

> | > It's not a question of "what's wrong with XML?". It's a question of
> | > "what advantage would we gain by strapping a giant flapping wet
> | > kipper to a bicycle?".
> |
> | Or (a little bit rephrased) "why should we stick with consistent file
> | formats".
>
> Uh, you'd have to invent a load of new XML DTD stuff for this anyway.

Nope. We can build on *existing* GLSA DTD and on *existing* code. The downside 
is that Portage integration could be slower (same case as with `glsa-check`, 
AFAIK).

> So you're not using a consistent file format at all, you're just using
> a consistent unnecessary layer in the middle, which as a side effect
> makes your files incompatible with every standard Unix tool ever
> written.

See below.

> Using XML does not magically make things compatible. XML is just a
> layer in the middle. Any tool processing XML files still has to worry
> about however the DTD in question works.

Just to clarify - I don't say that XML is The Best Way To Go (tm), I'm just 
pointing out another possibility of implementation which is *very* similar to 
the way GLSAs are processed. 

GLSA already contains stuff for marking items as valid only for given systems, 
for "injecting" them etc. Why don't use existing code? Why duplication?

Have a look at the XML source of any GLSA.

> You think XML magically makes things compatible? Then I suggest you
> write a GuieXML to Docbook conversion tool, and see how many thousand
> lines of XSLT it takes. All XML does is move the conversion and parsing
> problems to a different, more complex level.

I'm not familiar with DocBook, but I doubt I'll need thousands of lines of 
code.

[1] http://www.gentoo.org/proj/en/glep/glep-0014.html

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Eldad Zack]

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

On Tuesday 01 November 2005 14:39, Jakub Moc wrote:
> 1.11.2005, 13:26:57, Ciaran McCreesh wrote:
> > On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez <koon@gentoo.org>
> >
> > wrote:
> > | For them to know about it, they need to be warned when they do their
> > | "emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
> > | as it seems. People using a cron job to sync are probably a
> > | significant part of our user base...
> >
> > Have Portage give a red flashy before emerge if there're unread news
> > items?
> >
> > Although, a better solution for users who cron sync would be to have
> > said cron mail them all the relevant news files...
>
> Uhm... emerge sync is a *bad* time to display upgrade messages, it's simply
> irrelevant at that time, I'm not upgrading anything at the moment and might
> not be upgrading for next week or so.
>
> The messages should be displayed when I'm about to upgrade an ebuild which
> has an upgrade note associated with the new version. Sending mail via cron
> might be a nice optional feature for those who want to use it.

I think cron as suggested hit the spot here. I do the same with glsa-check -t 
all to notify me about security issues present on my system.



-- 
Eldad Zack <eldad@gentoo.org>
Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Wed, 2 Nov 2005 19:33:37 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
| "Once this tool is implemented and well tested it can be integrated
| into portage."

can ! will. It might, but don't count on it.

| GLSA already contains stuff for marking items as valid only for given
| systems, for "injecting" them etc. Why don't use existing code? Why
| duplication?

Because it's quicker to invent a wheel which is actually round.

| > You think XML magically makes things compatible? Then I suggest you
| > write a GuieXML to Docbook conversion tool, and see how many
| > thousand lines of XSLT it takes. All XML does is move the
| > conversion and parsing problems to a different, more complex level.
| 
| I'm not familiar with DocBook, but I doubt I'll need thousands of
| lines of code.

Oh? Our GuideXML to HTML conversion is thousands of lines of code...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Wednesday 02 of November 2005 23:34 Ciaran McCreesh wrote:
> Oh? Our GuideXML to HTML conversion is thousands of lines of code...

...including stuff for detecting outdated translations, inclusion of icons for 
the homepage etc etc.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
> | What's wrong with XML format similar to the one that is used for our
> | GLSAs?
> 
> 1. Portage does not handle XML. Portage will not handle XML in the
> near future.
> 
> 2. Many users do not have an XML parser installed.
> 
> 3. The standard Unix tools cannot be used on XML files.
> 
> 4. Bloat.
> 
> 5. XML is merely adding another problem to the one we have already.
> 

6. Ciaran is completely biased against XML (or anything that isn't
stored as a simple flat file) ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDahV22QTTR4CNEQARArcBAJ9OKq5xfST4dCq0aUCLYw4DxUXdbQCbBPmD
b02OM9czrkinjosTw4zCC5I=
=Fr/5
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> [a reply]

1. Store the actual guides as GuideXML at a central place such as
http://errata.gentoo.org/

2. Write a simple 'publishing' tool that extracts a summary and a link.
This is what gets pumped into portage and shown during an
# emerge --news

3. Rejoice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDahaE2QTTR4CNEQARAmzbAJ9G3UdKnSJ1ze+KMD4jMnr7I91fMwCgm29P
1prgiQtmdk6F6qSgngCyfWY=
=P03X
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[pclouds]

On 11/3/05, Nathan L. Adams <nadams@ieee.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ciaran McCreesh wrote:
> > [a reply]
>
> 1. Store the actual guides as GuideXML at a central place such as
> http://errata.gentoo.org/
>
> 2. Write a simple 'publishing' tool that extracts a summary and a link.
> This is what gets pumped into portage and shown during an
> # emerge --news
>
> 3. Rejoice.
Well, i like this way. We may write a good migration article and a
summary which is used by emerge --news. This is better than just an
annoucement that something has changed. Anyone who is to make backward
incompatible changes will have to write detail guidelines in addition
to annoucement. That's good.
--
Bi Cờ Lao

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 08:49:42 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| 6. Ciaran is completely biased against XML (or anything that isn't
| stored as a simple flat file) ;)

It's not bias. I give XML exactly what it deserves. SGML is a giant
fire breathing stomping monster useful for crushing Tokyo. XML is the
spawn of said giant fire breathing stomping monster that's had its
claws and teeth removed, its jaws glued shut, its legs chained together
and its tail nailed to the ground. And we're not trying to destroy any
large cities here...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 08:49:42 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | 6. Ciaran is completely biased against XML (or anything that isn't
> | stored as a simple flat file) ;)
> 
> It's not bias. I give XML exactly what it deserves. SGML is a giant
> fire breathing stomping monster useful for crushing Tokyo. XML is the
> spawn of said giant fire breathing stomping monster that's had its
> claws and teeth removed, its jaws glued shut, its legs chained together
> and its tail nailed to the ground. And we're not trying to destroy any
> large cities here...
> 

<rant>
You're just missing the fact that a flat file (or whatever it is you're
clinging to; for the purpose of this rant, I shall refer to your simple
data format as "flat file") has trade-offs, just like XML's trade off is
parsing overhead. XML was designed to solve certain problems;
portability of data, separation and portability of presentation from the
data, etc. Complexity in the parser is the trade-off.

Flat files can be great in certain situations. Flat files do indeed make
the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST IMPORTANT
REQUIREMENT. In the case of this GLEP, the most important requirement is
getting the proper migration info to the users in the best possible way.

So what are the trade-offs of the 'flat file'? If you store a migration
guide as a 'flat file', its not going to be very readable. I would
certainly rather read info in GuideXML than some garbage output by einfo
or the like (and I'm talking about the same exact data, just a different
presentation). You're being daft if you say that your average terminal
output is easier to read and understand than the same data in proper
GuideXML format. OK, you say, you have a point there. But, you say, my
flat file allows me to write a 'presentation' proggy in relatively few
lines of trivial code. Yes, but now you have to write a new presentation
program for every type of presentation you want to do. Or worse you
would imbed the presentation in the data itself and make a new copy of
the data every time you want to present it differently. But, you say,
don't you have to do that with XML (i.e. a new style sheet definition
for each presentation)? Sure, but I don't have to re-write firefox in
the process...

So the point is that, yes, XML has a down side. But plain text, CSV
files, whatever have their downsides too. And the point of this GLEP
shouldn't be to push any XML-bashing agenda, it should be to present the
user with the migration guide in the best possible way. GuideXML is the
standard for Gentoo docs for some damn good reasons!
</rant>

Nathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDaqt52QTTR4CNEQARAoQ1AJ42ItHkJ37eFUY8rSoGpN/dVoKIFACeJi7b
KW6/pzn8VEKi3hO0Gqomsms=
=cSQh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 19:29:45 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| Flat files can be great in certain situations. Flat files do indeed
| make the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST
| IMPORTANT REQUIREMENT. In the case of this GLEP, the most important
| requirement is getting the proper migration info to the users in the
| best possible way.

Read the list of requirements in the GLEP. The plain text solution
meets all of them. XML fails on several.

And, incidentally, I came up with the requirements list *before*
dismissing XML.

| So what are the trade-offs of the 'flat file'? If you store a
| migration guide as a 'flat file', its not going to be very readable.

Who said anything about storing a migration guide as a flat file? Read
the GLEP.

| GuideXML is the standard for Gentoo docs for some damn good reasons!

No, it's the standard because Daniel said so. And the reasons behind
which web publishing setup we use have little relation to good reasons
for a news delivery system.

Why do you think we still send email in plain text?

*shrug* Anyway, if you want to come up with an alternate GLEP based
around XML, bittorrent, Java and CORBA, go right ahead. The GLEP system
is quite happy with handling multiple competing proposals for a given
topic, and at the end of it we can select the best proposal, reject all
the proposals or go and come up with a new proposal with bits from
both.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Tue, 1 Nov 2005 14:32:47 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | What do you mean "they aren't tied to ebuilds"? I don't really
> | understand what this feature should do then, it seems. Once again,
> | what's wrong with reusing emerge --changelog mechanism for displaying
> | this kind of information?
> 
> We make changes that have scope other than ebuilds.
> 
> | I'm not particularly happy with idea of emerge as a newsreader
> | really, IMHO we should display relevant, vital upgrading information
> | *when relevant*, not to inform users about upgrades that they are not
> | interested in in the least.
> 
> Which is what my proposed GLEP does, at least as far as we can
> determine automatically. Yes, occasionally this will mean giving, say,
> mysql 4.1 upgrade instructions to people who plan to use only mysql
> 4.0, but then, if we didn't give them the news, most of them wouldn't
> know that they don't want to upgrade.
> 
> And it doesn't turn emerge into a news reader. All portage does is
> deliver the news. How said news is read is a different issue.
> 
> | And please, keep the thing simple so that I can be done in reasonable
> | amount of time and does not follow the destiny of einfo/ewarn logging
> | (3 years and counting).
> 
> Of course. Hence why I'm proposing something easy and workable, and not
> suggesting some magic new framework that will solve all existing
> problems (including world peace).
> 

Just keep in mind that portage is supposed to be non-interactive and
most users like it that way. (Although the countdown when cleaning out
old packages kinda breaks that idea, but I digress.)

So just make sure that the scheme doesn't involve forcing the user to
notice anything during a 'normal' non-interactive emerge in order for it
to be effective. Thats why I keep pushing having a nice GuideXML version
in a central location like http://errata.g.o/ and just having emerge
output a summary and a link (however/at what point/with what mechanism
you decide to actually have portage output it).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDaq8U2QTTR4CNEQARAm6kAJ948WBp0elnZvxoHLMXvNfaBZvxsgCdEdAO
gO6VPobgKHfqcKpjAQ1II6U=
=iNoA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Chris Gianelloni wrote:
> On Tue, 2005-11-01 at 12:26 +0000, Ciaran McCreesh wrote:
> 
>>On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez <koon@gentoo.org>
>>wrote:
>>| For them to know about it, they need to be warned when they do their
>>| "emerge -p world" or "emerge -a mysql" that the upgrade is not as easy
>>| as it seems. People using a cron job to sync are probably a
>>| significant part of our user base...
>>
>>Have Portage give a red flashy before emerge if there're unread news
>>items?
> 
> Or have it die unless they have
> I_LIKE_A_BROKEN_SYSTEM_PLEASE_IGNORE_NEWS="yes" in make.conf.... ;]
> 
>>Although, a better solution for users who cron sync would be to have
>>said cron mail them all the relevant news files...
> 
> We don't have control over what they do in cron, we do have control over
> portage itself.
> 

The cron thing is a *really* good idea. Its so good that its an example
in the Gentoo Cron How-to. A few developers actively debugging the sync
process might enjoy watching the output of a sync scroll by, but
normal/sane people have better things to do. (Note: I'm not bashing
Chris's statement here; I honestly don't know what point he was trying
to make).

So don't implement the --news thing in such a way that in the future a
developer might be tempted to tell a complaining user "whats the matter
with you? don't you read the output when you sync? no? what a loser; no
wonder your system is b0rked." (or something to that effect)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarFQ2QTTR4CNEQARAgWDAJ0cW1xpOKCy+jjaYCoGBbfOOXSGwwCgojNk
flBm0MnXXXRLsBGC3XXcYts=
=1Ls9
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 19:45:08 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| Just keep in mind that portage is supposed to be non-interactive and
| most users like it that way. (Although the countdown when cleaning out
| old packages kinda breaks that idea, but I digress.)

You really should give the GLEP a read. It's quite nice, you know...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 19:29:45 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | Flat files can be great in certain situations. Flat files do indeed
> | make the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST
> | IMPORTANT REQUIREMENT. In the case of this GLEP, the most important
> | requirement is getting the proper migration info to the users in the
> | best possible way.
> 
> Read the list of requirements in the GLEP. The plain text solution
> meets all of them. XML fails on several.

If readability isn't a requirement, your list is wrong.

> And, incidentally, I came up with the requirements list *before*
> dismissing XML.

Given your past public statement about XML; I highly doubt that. Whether
you were concious of it or not, I suspect that XML bashing was always in
the mix.

> | So what are the trade-offs of the 'flat file'? If you store a
> | migration guide as a 'flat file', its not going to be very readable.
> 
> Who said anything about storing a migration guide as a flat file? Read
> the GLEP.

No, *you* need to read my previous response. I was using 'flat file' to
mean whatever it is you're calling your less-than-GuideXML scheme.

> | GuideXML is the standard for Gentoo docs for some damn good reasons!
> 
> No, it's the standard because Daniel said so. And the reasons behind
> which web publishing setup we use have little relation to good reasons
> for a news delivery system.
> 
> Why do you think we still send email in plain text?

Why do you think news is sent as an RSS feed? Answer: Because it has
proven to be the best way!

> *shrug* Anyway, if you want to come up with an alternate GLEP based
> around XML, bittorrent, Java and CORBA, go right ahead.

I never mentioned bittorrent, Java, or CORBA. If you don't have a valid
arguement, please don't try to distract everyone by putting words into
the mouths of those you're arguing with.

> The GLEP system
> is quite happy with handling multiple competing proposals for a given
> topic, and at the end of it we can select the best proposal, reject all
> the proposals or go and come up with a new proposal with bits from
> both.

So if you didn't want people to actually review and comment on *your*
GLEP, why did you write:

"The attached GLEP is a draft proposal for the emerge --news thing
that's been under discussion. There are still some TODO items. These are
calls for people to weigh in with suggestions. Of course, suggestions on
other items are good too..."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarNC2QTTR4CNEQARAkvgAJ91X9MQyPVLE20VPYhAVq5O36jV3gCeI/nY
swzdhW0+/C84vVN9UQ8aes4=
=DiXn
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 19:45:08 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | Just keep in mind that portage is supposed to be non-interactive and
> | most users like it that way. (Although the countdown when cleaning out
> | old packages kinda breaks that idea, but I digress.)
> 
> You really should give the GLEP a read. It's quite nice, you know...
> 

Your explanations hint at interacting with portage during an emerge.
Specifically you floated the idea of having emerge print a red flashy
message before doing the emerge. *That* is what I was commenting on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarPp2QTTR4CNEQARAkkbAKCn8yDt7D17Ls+/huZkg4TkKjmXVwCgntbs
BrrWIziJCF2M8RckaINyMNA=
=Ytle
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 20:02:58 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| So if you didn't want people to actually review and comment on *your*
| GLEP, why did you write:
| 
| "The attached GLEP is a draft proposal for the emerge --news thing
| that's been under discussion. There are still some TODO items. These
| are calls for people to weigh in with suggestions. Of course,
| suggestions on other items are good too..."

I want people to review and comment on it after they've actually read
the thing.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 20:05:45 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| Ciaran McCreesh wrote:
| > On Thu, 03 Nov 2005 19:45:08 -0500 "Nathan L. Adams"
| > <nadams@ieee.org>
| > wrote:
| > | Just keep in mind that portage is supposed to be non-interactive
| > | and most users like it that way. (Although the countdown when
| > | cleaning out old packages kinda breaks that idea, but I digress.)
| > 
| > You really should give the GLEP a read. It's quite nice, you know...
| > 
| 
| Your explanations hint at interacting with portage during an emerge.
| Specifically you floated the idea of having emerge print a red flashy
| message before doing the emerge. *That* is what I was commenting on.

Ever noticed any of the other red flashies that emerge gives? For
example, if you try emerge -C glibc? Doesn't break the non-interactive
requirement, it's just yet another way of shoving something in the
user's face if they somehow ignore all the normal warnings.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 20:02:58 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | So if you didn't want people to actually review and comment on *your*
> | GLEP, why did you write:
> | 
> | "The attached GLEP is a draft proposal for the emerge --news thing
> | that's been under discussion. There are still some TODO items. These
> | are calls for people to weigh in with suggestions. Of course,
> | suggestions on other items are good too..."
> 
> I want people to review and comment on it after they've actually read
> the thing.
> 

I have read it, and I find it lacking; thus the comments. Or are you
claiming that the idea of having a central website like errata.g.o with
GuideXML-ized migrations guides is in your GLEP? Its not. I'm proposing
adding that as the definative source of the errata, and feeding it to
other places (emerge --news, mailing lists, forums, GWN) as desired.

I'm also commenting on the part that *wrongly* states "It is not
reasonable to expect all users to have an MTA, *web browser*, email
client, cron daemon or text processing suite available on their system.
In particular, this means that any markup to be parsed must be in a very
simple format."

*ALL* of the official docs are GuideXML; Gentoo *expects* users to have
a web browser by default. Otherwise a vast majority of users would never
get Gentoo installed in the first place. The "lightweight" requirement
appears to just be your way of subverting the current documentation
standards (because of your XML hatred).

The news directory shouldn't the main source of the migration guides;
the website should be (one central page that can feed other sources).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarhL2QTTR4CNEQARAr+KAJ9v5iy+i5tvqNx9woib/cJUZI+eMwCgohIo
acuUUmVYcI1TsBDX0dg/K0s=
=bWEF
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 20:05:45 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | Ciaran McCreesh wrote:
> | > On Thu, 03 Nov 2005 19:45:08 -0500 "Nathan L. Adams"
> | > <nadams@ieee.org>
> | > wrote:
> | > | Just keep in mind that portage is supposed to be non-interactive
> | > | and most users like it that way. (Although the countdown when
> | > | cleaning out old packages kinda breaks that idea, but I digress.)
> | > 
> | > You really should give the GLEP a read. It's quite nice, you know...
> | > 
> | 
> | Your explanations hint at interacting with portage during an emerge.
> | Specifically you floated the idea of having emerge print a red flashy
> | message before doing the emerge. *That* is what I was commenting on.
> 
> Ever noticed any of the other red flashies that emerge gives? For
> example, if you try emerge -C glibc? Doesn't break the non-interactive
> requirement, it's just yet another way of shoving something in the
> user's face if they somehow ignore all the normal warnings.
> 

Yes, I've noticed them. My point is that you need to be careful that the
red-flashy doesn't the primary way of delivering the message.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarid2QTTR4CNEQARAq+gAKCZ0e1kZHeuYvQcjqxKwTZ+XsbXRACgh2ef
gSZ1q0Of1t6SA6u5oMQkp5c=
=oKCA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 20:24:27 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| I'm also commenting on the part that *wrongly* states "It is not
| reasonable to expect all users to have an MTA, *web browser*, email
| client, cron daemon or text processing suite available on their
| system. In particular, this means that any markup to be parsed must
| be in a very simple format."
| 
| *ALL* of the official docs are GuideXML; Gentoo *expects* users to
| have a web browser by default. Otherwise a vast majority of users
| would never get Gentoo installed in the first place. The
| "lightweight" requirement appears to just be your way of subverting
| the current documentation standards (because of your XML hatred).

I don't have a web browser installed on my server. Do you?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Brian Harring]

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

On Thu, Nov 03, 2005 at 08:24:27PM -0500, Nathan L. Adams wrote:
> I'm also commenting on the part that *wrongly* states "It is not
> reasonable to expect all users to have an MTA, *web browser*, email
> client, cron daemon or text processing suite available on their system.
> In particular, this means that any markup to be parsed must be in a very
> simple format."
> 
> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> a web browser by default. Otherwise a vast majority of users would never
> get Gentoo installed in the first place. The "lightweight" requirement
> appears to just be your way of subverting the current documentation
> standards (because of your XML hatred).

We actually have links in the base profile iirc, either way, the 
example of where this breaks down is headless servers...

> The news directory shouldn't the main source of the migration guides;
> the website should be (one central page that can feed other sources).
Not necessarily the website imo, some central store where it's pushed 
out to all of the locations though (which I suspect you're getting 
at).
~harring

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 20:24:27 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | I'm also commenting on the part that *wrongly* states "It is not
> | reasonable to expect all users to have an MTA, *web browser*, email
> | client, cron daemon or text processing suite available on their
> | system. In particular, this means that any markup to be parsed must
> | be in a very simple format."
> | 
> | *ALL* of the official docs are GuideXML; Gentoo *expects* users to
> | have a web browser by default. Otherwise a vast majority of users
> | would never get Gentoo installed in the first place. The
> | "lightweight" requirement appears to just be your way of subverting
> | the current documentation standards (because of your XML hatred).
> 
> I don't have a web browser installed on my server. Do you?
> 

So you installed your server without reading *any* documenation? (Don't
lie). And you expect that the average user installs a Gentoo server
without at least referencing the documentation? Pa-leaze.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarsD2QTTR4CNEQARAuZhAJ49FHBjVbDQbC6+nyBIw6wRjLZE+QCeO/yW
dPY2A20OJcwJ/NTOwZqg434=
=SPIh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Brian Harring wrote:
> On Thu, Nov 03, 2005 at 08:24:27PM -0500, Nathan L. Adams wrote:
> 
>>I'm also commenting on the part that *wrongly* states "It is not
>>reasonable to expect all users to have an MTA, *web browser*, email
>>client, cron daemon or text processing suite available on their system.
>>In particular, this means that any markup to be parsed must be in a very
>>simple format."
>>
>>*ALL* of the official docs are GuideXML; Gentoo *expects* users to have
>>a web browser by default. Otherwise a vast majority of users would never
>>get Gentoo installed in the first place. The "lightweight" requirement
>>appears to just be your way of subverting the current documentation
>>standards (because of your XML hatred).
> 
> 
> We actually have links in the base profile iirc, either way, the 
> example of where this breaks down is headless servers...

Actually, a headless server would be administered from a workstation
that would actually have a head. (Unless you like the idea of
installing things by typing blindly on a keyboard ;))

And as I mentioned in my last reply to Ciaran, I doubt anyone installing
a server doesn't have access to the web (another computer for example).

And having the GuideXML as the main source does NOT preclude having the
other sources (such as emerge --news) for people sitting in the dark.

>>The news directory shouldn't the main source of the migration guides;
>>the website should be (one central page that can feed other sources).
> 
> Not necessarily the website imo, some central store where it's pushed 
> out to all of the locations though (which I suspect you're getting 
> at).

If I understand his position correctly, Ciaran doesn't want the GuideXML
version at all, which is a supremely stupid idea IMHO.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarxP2QTTR4CNEQARAvnNAJ4gJb41KcQuE2lsSDoTY4Se9wg+8wCfQKqQ
TMwatb4SkjOLfuUJyv7xTf0=
=f/nj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Brian Harring wrote:
> Not necessarily the website imo, some central store where it's pushed 
> out to all of the locations though (which I suspect you're getting 
> at).

I forgot to clarify one point. I'm saying that http://errata.g.o/ should
be the *official* source where users go to find the info, not
neccessarity the place where the raw data is stored and pushed to other
places (although it certainly could be).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarzS2QTTR4CNEQARAlB7AJsHfqCVL160KApWZU7iuqNtCb9SWwCcCtRR
D2e1H1U208kQQNzLDo9CpGk=
=kiyo
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Stephen P. Becker]

> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> a web browser by default. Otherwise a vast majority of users would never
> get Gentoo installed in the first place. The "lightweight" requirement
> appears to just be your way of subverting the current documentation
> standards (because of your XML hatred).

How about getting some facts straight before running your mouth?  Gentoo 
most certainly does not expect users to have a web browser to install. 
The last time I actually installed on x86 (which was some time ago 
admittedly), there was a .txt version of the install guide on the livecd.

Even then, the web browser you are speaking of runs directly off the 
livecd.  So, what happens when there is critical news to be read during 
the install phase inside the chroot, but no web browser is yet 
installed?  Are you suggesting we bloat stage1 and stage2 with some sort 
of XML parser so that the user can read news without having to kill the 
emerge and read the news outside the chroot?  I think you would have a 
seriously hard time convincing the release folks this is a good idea.

Furthermore, it is not possible to include any sort of XML parser with 
installers for certain arches which use very minimal netboots for the 
default installation method.  So really, your complaints about the 
"lightweight" requirement appears to just be a way of subverting 
attention away from the real reasons it is a good idea, and towards 
maintaining a flamewar with ciaran that you will surely lose.

-Steve

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Stephen P. Becker]

> So you installed your server without reading *any* documenation? (Don't
> lie). And you expect that the average user installs a Gentoo server
> without at least referencing the documentation? Pa-leaze.

Funny, I've done three fresh installs on my various mips machines in the 
past couple of weeks, and I didn't read even a word of documentation to 
do it.

Besides, if somebody is installing gentoo on a server, do you really 
think that would be their only box?  Surely they have a workstation of 
some sort, since a proper server certainly would not be also used as a 
desktop.

-Steve

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 20:36:03 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| So you installed your server without reading *any* documenation?

Actually, yes, I did. I can quite easily do installs without the
documentation, as can most other people who really know how Gentoo
works.

| (Don't lie). And you expect that the average user installs a Gentoo
| server without at least referencing the documentation? Pa-leaze.

I bet there're lots of people who don't read the documentation using
the machine on which they're installing.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Lance Albertson]

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

Nathan L. Adams wrote:

> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> a web browser by default. Otherwise a vast majority of users would never
> get Gentoo installed in the first place. The "lightweight" requirement
> appears to just be your way of subverting the current documentation
> standards (because of your XML hatred).

Since when did GuideXML become the standard for all our websites?
Currently, the only website that uses it is www. Nothing else uses it.
If any solution to the errata site idea is going to come out, it doesn't
need to be guidexml, it can be anything.

After reading through the heated thread, I have yet to see your valid
point of pushing xml for such a simple task. All I have seen is two 3rd
grade kids arguing over a swing set. Please give some calm reasons for
your opinion instead of voicing things in such a heated manner. Making
assumptions about someone else's opinions gets you no where.

Please keep your discussion to this thread a discussion and not an
argument between you and ciaranm. Please take those off this list.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Thu, 03 Nov 2005 20:41:36 -0500 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| If I understand his position correctly, Ciaran doesn't want the
| GuideXML version at all, which is a supremely stupid idea IMHO.

Read GLEP. GLEP good.

Especially the bit about interoperability with existing news sources.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Stephen P. Becker wrote:
>> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
>> a web browser by default. Otherwise a vast majority of users would never
>> get Gentoo installed in the first place. The "lightweight" requirement
>> appears to just be your way of subverting the current documentation
>> standards (because of your XML hatred).
> 
> 
> How about getting some facts straight before running your mouth?  Gentoo
> most certainly does not expect users to have a web browser to install.
> The last time I actually installed on x86 (which was some time ago
> admittedly), there was a .txt version of the install guide on the livecd.
> 
> Even then, the web browser you are speaking of runs directly off the
> livecd.  So, what happens when there is critical news to be read during
> the install phase inside the chroot, but no web browser is yet
> installed?  Are you suggesting we bloat stage1 and stage2 with some sort
> of XML parser so that the user can read news without having to kill the
> emerge and read the news outside the chroot?  I think you would have a
> seriously hard time convincing the release folks this is a good idea.
> 
> Furthermore, it is not possible to include any sort of XML parser with
> installers for certain arches which use very minimal netboots for the
> default installation method.  So really, your complaints about the
> "lightweight" requirement appears to just be a way of subverting
> attention away from the real reasons it is a good idea, and towards
> maintaining a flamewar with ciaran that you will surely lose.
>

Let me say it one more time. I'm not saying you have to have a web
browser installed on the system that you are updating or installing. I'm
saying that the GuideXML docs are the standard, official source of
documentation and the same should hold true for the migration guides.
I'm also saying that feedback from users said they want ONE official
place to find this stuff. Therefor any plan that doesn't take both of
those things into account is silly. And having the GuideXML-ized guides
on a central website marked as the 'official-one-stop-for-errata' does
not in any way shape or form preclude anyone from mirroring that info in
a text file, forum post, emerge --news, mailing list, etc. etc. ad nauseum.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDar7y2QTTR4CNEQARAkK2AJ9W+uofXxiuNc86gzsfHISvD7XkPgCeMeue
kDgucVFWYYLAb74WbcLQWpM=
=6A4p
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Stephen P. Becker wrote:
> 
>> So you installed your server without reading *any* documenation? (Don't
>> lie). And you expect that the average user installs a Gentoo server
>> without at least referencing the documentation? Pa-leaze.
> 
> 
> Funny, I've done three fresh installs on my various mips machines in the
> past couple of weeks, and I didn't read even a word of documentation to
> do it.
> 
> Besides, if somebody is installing gentoo on a server, do you really
> think that would be their only box?  Surely they have a workstation of
> some sort, since a proper server certainly would not be also used as a
> desktop.

And therefore they would have a access to a web browser. Thank you for
helping to explain my point.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDar8m2QTTR4CNEQARAvlAAJ9cXIqGHzojBSkz6XEACuXefbBE1ACaAsE2
p2wxad72pF3iHPAf+LU2x7s=
=z0nr
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Ciaran McCreesh wrote:
> On Thu, 03 Nov 2005 20:36:03 -0500 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | So you installed your server without reading *any* documenation?
> 
> Actually, yes, I did. I can quite easily do installs without the
> documentation, as can most other people who really know how Gentoo
> works.

And as a long time developer, I'm sure you represent the typical user...

> | (Don't lie). And you expect that the average user installs a Gentoo
> | server without at least referencing the documentation? Pa-leaze.
> 
> I bet there're lots of people who don't read the documentation using
> the machine on which they're installing.

See above.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDar+G2QTTR4CNEQARAqTdAJ9LT4bx+nrPJpdwpttZaKFoOCVTSgCfYbvy
ozqoUGfbXM57FLxBMYp9UWg=
=Alrz
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Grant Goodyear]

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

Nathan L. Adams wrote: [Thu Nov 03 2005, 07:02:58PM CST]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ciaran McCreesh wrote:
> > Read the list of requirements in the GLEP. The plain text solution
> > meets all of them. XML fails on several.
> 
> If readability isn't a requirement, your list is wrong.

I would argue that reading raw xml is a lot less fun than reading minimally
marked-up plain text (such as an e-mail).

> > | So what are the trade-offs of the 'flat file'? If you store a
> > | migration guide as a 'flat file', its not going to be very readable.
> > 
> > Who said anything about storing a migration guide as a flat file? Read
> > the GLEP.
> 
> No, *you* need to read my previous response. I was using 'flat file' to
> mean whatever it is you're calling your less-than-GuideXML scheme.

*Sigh*  I think you might be misinterpreting the GLEP.  The news items
are likely to be fairly short, such as the "YourSQL" example that's in
the GLEP.  The news item would then point to a migration guide that
resides elsewhere, if needed.

The point behind having the news pulled by portage is that the headless
server, for example,  would only report news items that are relevant to
that machine.  The server's admin could then fire up a web browser on a
desktop machine to read any necessary additional info.

> > | GuideXML is the standard for Gentoo docs for some damn good reasons!

True, but at the same time there's a reason that GLEPs can be written in
restructured text as well as guidexml.  I doubt that it's accidental
that almost all GLEPs have been submitted in restructured text rather
than guidexml.  (Incidentally, I like our guidexml.  I think that it
renders quite well for what we want.  I'm not so fond of writing it,
however.)

That's really beside the point, though.  The real point is that plain
text news items are going to be the easiest to create and the easiest to
read on a console screen.

As for having an errata page, it wouldn't be difficult to write a
program to automatically convert news items to guidexml.  I suspect that
ciaranm could even be talked into writing it, if such a page were to
become reality.

-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] GLEP ??: Critical News Reporting

[Lance Albertson]

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

Grant Goodyear wrote:

>>>| GuideXML is the standard for Gentoo docs for some damn good reasons!
> 
> 
> True, but at the same time there's a reason that GLEPs can be written in
> restructured text as well as guidexml.  I doubt that it's accidental
> that almost all GLEPs have been submitted in restructured text rather
> than guidexml.  (Incidentally, I like our guidexml.  I think that it
> renders quite well for what we want.  I'm not so fond of writing it,
> however.)

Here here ... I like how GLEPs are primarily in RST format which is
really easy to read in raw form. My vote/opinion is to use a similar
format for news items which I'm pretty sure can be easily converted to
whatever format we end up using (GuideXML or not) for the site portion
of this GLEP.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Luis F. Araujo]

Nathan L. Adams wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Stephen P. Becker wrote:
>  
>
>>>So you installed your server without reading *any* documenation? (Don't
>>>lie). And you expect that the average user installs a Gentoo server
>>>without at least referencing the documentation? Pa-leaze.
>>>      
>>>
>>Funny, I've done three fresh installs on my various mips machines in the
>>past couple of weeks, and I didn't read even a word of documentation to
>>do it.
>>
>>Besides, if somebody is installing gentoo on a server, do you really
>>think that would be their only box?  Surely they have a workstation of
>>some sort, since a proper server certainly would not be also used as a
>>desktop.
>>    
>>
>
>And therefore they would have a access to a web browser. Thank you for
>helping to explain my point.
>  
>
The point is not about havig access to a web browser, but to have it 
installed
in the respective box reading news.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Qian Qiao]

On 11/4/05, Nathan L. Adams <nadams@ieee.org> wrote:
> And as a long time developer, I'm sure you represent the typical user...

Well, I'm a normal user here, and I can install gentoo quite easily
without reading the documentation. it's dead simple:
prepare the disks -> get the stage tarballs -> chroot ->
bootstrap/emerge -e system -> build the kernel -> build the bootloader
-> a few config tweaks.

Onces one gets the idea, i don't see how a gentoo installation is
harder than a RH or debian or suse one.

-- Joe

--
There are 3 kinds of people in the world:
Those who can count, and those who can't.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Lance Albertson wrote:
> Nathan L. Adams wrote:
> 
> 
>>*ALL* of the official docs are GuideXML; Gentoo *expects* users to have
>>a web browser by default. Otherwise a vast majority of users would never
>>get Gentoo installed in the first place. The "lightweight" requirement
>>appears to just be your way of subverting the current documentation
>>standards (because of your XML hatred).
> 
> 
> Since when did GuideXML become the standard for all our websites?
> Currently, the only website that uses it is www. Nothing else uses it.
> If any solution to the errata site idea is going to come out, it doesn't
> need to be guidexml, it can be anything.

http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml#doc_chap3

"However, when the document is finished, it should be transformed into
GuideXML and made available on the Gentoo CVS infrastructure. It must
also be registered in the metadoc.xml file if applicable."

I never said "all [Gentoo] website"; just documentation. Errata is
documentation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDavH02QTTR4CNEQARAryaAJkB4DCRYSxwrskI20hzqkC7nmcmggCgpkUu
TaEAOVda9tjLj1CQZK1YIkg=
=FO5/
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Grant Goodyear wrote:
> Nathan L. Adams wrote: [Thu Nov 03 2005, 07:02:58PM CST]
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Ciaran McCreesh wrote:
>>
>>>Read the list of requirements in the GLEP. The plain text solution
>>>meets all of them. XML fails on several.
>>
>>If readability isn't a requirement, your list is wrong.
> 
> 
> I would argue that reading raw xml is a lot less fun than reading minimally
> marked-up plain text (such as an e-mail).

Oh good grief! Nobody is arguing that the user should have to read raw XML.

> 
>>>| So what are the trade-offs of the 'flat file'? If you store a
>>>| migration guide as a 'flat file', its not going to be very readable.
>>>
>>>Who said anything about storing a migration guide as a flat file? Read
>>>the GLEP.
>>
>>No, *you* need to read my previous response. I was using 'flat file' to
>>mean whatever it is you're calling your less-than-GuideXML scheme.
> 
> *Sigh*  I think you might be misinterpreting the GLEP.  The news items
> are likely to be fairly short, such as the "YourSQL" example that's in
> the GLEP.  The news item would then point to a migration guide that
> resides elsewhere, if needed.

No, I happen to understand the that point. Emerge outputting a short
summary is great. But the GLEP should cover the "hey mr. end user, the
central repository for errata/full fledged migration guides is here:
[insert url]" as well.

> 
> The point behind having the news pulled by portage is that the headless
> server, for example,  would only report news items that are relevant to
> that machine.  The server's admin could then fire up a web browser on a
> desktop machine to read any necessary additional info.

Great; I'm not against that. Now where does that admin point her web
browser? Mailing list archive? GWN archive? The Forums? The stated
feedback is that users what a central place for the errata (whether the
errata be large or small).

> 
>>>| GuideXML is the standard for Gentoo docs for some damn good reasons!
> 
> 
> True, but at the same time there's a reason that GLEPs can be written in
> restructured text as well as guidexml.  I doubt that it's accidental
> that almost all GLEPs have been submitted in restructured text rather
> than guidexml.  (Incidentally, I like our guidexml.  I think that it
> renders quite well for what we want.  I'm not so fond of writing it,
> however.)
> 
> That's really beside the point, though.  The real point is that plain
> text news items are going to be the easiest to create and the easiest to
> read on a console screen.
> 
> As for having an errata page, it wouldn't be difficult to write a
> program to automatically convert news items to guidexml.  I suspect that
> ciaranm could even be talked into writing it, if such a page were to
> become reality.

I happen to think that the assumption that the errata are going to be
small is a bad one. I think if errata is neccessary in the first place
then its going to be something larger than a screen's worth of console
output and worth the supposed trouble of GuideXML. So why not approach
it from the GuideXML end first, and extract the summary from that?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDavVI2QTTR4CNEQARAnMnAKCAir22mvnCgoKXc8xPDIYaQMmReACdELKr
aa1l8avqCC7nIvV/VypyJj8=
=LxgP
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Wernfried Haas]

On Fri, Nov 04, 2005 at 12:42:47AM +0000, Ciaran McCreesh wrote:
> Read the list of requirements in the GLEP. The plain text solution
> meets all of them. XML fails on several.
>
> And, incidentally, I came up with the requirements list *before*
> dismissing XML.

Sorry, but this is too funny. 
You don't like XML.
You wrote the requirements.
You decided XML doesn't meet those requirements.
So even if you come up with the requirements *before* chances are
approximately 97% XML will fail.

I don't know if XML _is_ the right thing for this job, but i think you
are definitely biased towards it.

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 ??: Critical News Reporting

[John Myers]

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

[[ACK! I sent this out from the wrong address before. Hope you don't get it 
twice!]]
On Thursday 03 November 2005 21:44, Nathan L. Adams wrote:
> No, I happen to understand the that point. Emerge outputting a short
> summary is great. But the GLEP should cover the "hey mr. end user, the
> central repository for errata/full fledged migration guides is here:
> [insert url]" as well.
[snip]
> I happen to think that the assumption that the errata are going to be
> small is a bad one. I think if errata is neccessary in the first place
> then its going to be something larger than a screen's worth of console
> output and worth the supposed trouble of GuideXML. So why not approach
> it from the GuideXML end first, and extract the summary from that?
Here's an idea for a compromise solution. Sorry it's so messy:

The errata entries would consist of two files per language:
- An emerge news file, identical to the format ciaranm proposed.
    This file would give a very general notice of the issue, such as that 
    given as an example in the GLEP, as well as containing the 
    machine-readable commands for portage to control display.
  This file's name would end in .news.<LC>.txt
- A GuideXML-formatted errata document.
    This would be the actual migration guide, such as the contents of the
         http://www.gentoo.org/doc/en/yoursql-upgrading.xml
    referenced by the example.
  This file's name would end in .guide.<LC>.xml
- The leading part of the filename would be as in ciaranm's GLEP

Once it is time for the errata item to be published (after review, etc.), the 
files would be placed in a standard location, where an automated process 
would pick them up. The news files would be transferred to the Portage tree 
for emerge to pick up, and simultaneously published to a central errata 
website, e.g. http://errata.gentoo.org/. On the errata website, *all* errata 
notices would be published to its front page, unless specified differently by 
each individual user (perhaps a feature storing filters in a cookie). Each 
entry in the list would contain at least the publication date, the title of 
the news item as a link to a news item page, and the title of the guideXML 
document as a link to the document. 

Errata items would be accessible in a uniform namespace with names derived 
from their source filenames. For example:
    2005-11/2005-11-01-mysql-4.0-4.1-upgrade.news.en.txt
    2005-11/2005-11-01-mysql-4.0-4.1-upgrade.guide.en.xml
might become:
    http://errata.gentoo.org/2005-11-01-mysql-4.0-4.1-upgrade/en/
    http://errata.gentoo.org/2005-11-01-mysql-4.0-4.1-upgrade/en/guide.xml
    
For user convenience, URLs with language codes the text is not yet translated 
to, as well as URLs without a language code, should be redirected to the 
English version.

Errata items may be published in other areas for wider exposure, but should 
always contain a link back to the main source.

The news item page would contain a copy of the news text typeset in a 
fixed-width font, and with links made clickable, as well as a prominent link 
to the GuideXML document. The title of the page should be the title of the 
news item, and the title of the link to the GuideXML page should be the title 
of the GuideXML document.

Questions? Comments? 

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 02:24, Nathan L. Adams wrote:
> I have read it, and I find it lacking; thus the comments. Or are you
> claiming that the idea of having a central website like errata.g.o with
> GuideXML-ized migrations guides is in your GLEP? Its not. I'm proposing
> adding that as the definative source of the errata, and feeding it to
> other places (emerge --news, mailing lists, forums, GWN) as desired.

I agree with Ciaran here. Emerge --news should be authoritive. I'm not 
opposed to erata.gentoo.org, but it is easy to generate from the tree. If 
there would be a master format to generate both from, that would also be 
OK, but news items in the tree is probably the best answer. And it is 
easy to display when pretending. One could even give a warning (in 
advance) when a user is trying to update an affected package (perhaps 
this should be an extra header item).

>
> I'm also commenting on the part that *wrongly* states "It is not
> reasonable to expect all users to have an MTA, *web browser*, email
> client, cron daemon or text processing suite available on their system.
> In particular, this means that any markup to be parsed must be in a
> very simple format."
>
> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> a web browser by default. Otherwise a vast majority of users would
> never get Gentoo installed in the first place. The "lightweight"
> requirement appears to just be your way of subverting the current
> documentation standards (because of your XML hatred).

No, gentoo expects people to have access to a webbrowser. But not all the 
time. It is perfectly reasonable to expect people to make a nice printout 
of the handbook at the office, and then take it at home to install a nice 
new gentoo box.

> The news directory shouldn't the main source of the migration guides;
> the website should be (one central page that can feed other sources).

The website should not as it a pull source of information. It requires 
users to actively acquire the information. What is worse is that some 
users might not update for a prolongued time (6 months). At that time 
they will not find the information in the erata list anymore. But they 
will get the RELEVANT news delivered by emerge/enews.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 02:36, Nathan L. Adams wrote:
> Ciaran McCreesh wrote:
> >
> > I don't have a web browser installed on my server. Do you?
>
> So you installed your server without reading *any* documenation? (Don't
> lie). And you expect that the average user installs a Gentoo server
> without at least referencing the documentation? Pa-leaze.

I expect the average user to make a nice printout of the handbook. The 
print version of the handbook was provided mainly on user request you 
know. It also works a lot easier than either flipping screens to 
links/lynx all the time or running up and down to another computer (if 
available).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 02:43, Nathan L. Adams wrote:
> Brian Harring wrote:
> > Not necessarily the website imo, some central store where it's pushed
> > out to all of the locations though (which I suspect you're getting
> > at).
>
> I forgot to clarify one point. I'm saying that http://errata.g.o/
> should be the *official* source where users go to find the info, not
> neccessarity the place where the raw data is stored and pushed to other
> places (although it certainly could be).

I'm saying that /usr/portage/news should be the *official* source where 
users should go to find the info. http://erata.g.o would be a secondary 
source, that while officially supported, is not the main source. 

The reason is that errata.g.o would not be able to offer the same user 
experience as emerge --news would. errata.g.o does NOT know about the 
local system (nor should it), and thus might be bloated with unneeded 
information. When I'm working at updating a system, I'm not interested in 
knowing that winex-cvs has been removed at transgaming's request (old 
news, as example). If however I was someone using winex-cvs, I'd be very 
interested. See the point.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 02:52, Nathan L. Adams wrote:
> Let me say it one more time. I'm not saying you have to have a web
> browser installed on the system that you are updating or installing.
> I'm saying that the GuideXML docs are the standard, official source of
> documentation and the same should hold true for the migration guides.
> I'm also saying that feedback from users said they want ONE official
> place to find this stuff. Therefor any plan that doesn't take both of
> those things into account is silly. And having the GuideXML-ized guides
> on a central website marked as the 'official-one-stop-for-errata' does
> not in any way shape or form preclude anyone from mirroring that info
> in a text file, forum post, emerge --news, mailing list, etc. etc. ad
> nauseum.

GuideXML would not be an appropriate format in any case. GuideXML is too 
bloated with presentation items to be of use for such a purpose. While 
one could argue for an xml source version, it would certainly not be 
guidexml. This is also not necessary as it is possible to easilly apply 
double transformations by first transforming a file into guidexml and 
then into html. Look at the herds.xml file or projectxml for an example 
of this.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 09:32, John Myers wrote:
> [[ACK! I sent this out from the wrong address before. Hope you don't
> get it twice!]]
>
> On Thursday 03 November 2005 21:44, Nathan L. Adams wrote:
> > No, I happen to understand the that point. Emerge outputting a short
> > summary is great. But the GLEP should cover the "hey mr. end user,
> > the central repository for errata/full fledged migration guides is
> > here: [insert url]" as well.
>
> [snip]
>
> > I happen to think that the assumption that the errata are going to be
> > small is a bad one. I think if errata is neccessary in the first
> > place then its going to be something larger than a screen's worth of
> > console output and worth the supposed trouble of GuideXML. So why not
> > approach it from the GuideXML end first, and extract the summary from
> > that?
>
> Here's an idea for a compromise solution. Sorry it's so messy:
>
> The errata entries would consist of two files per language:
> - An emerge news file, identical to the format ciaranm proposed.
>     This file would give a very general notice of the issue, such as
> that given as an example in the GLEP, as well as containing the
> machine-readable commands for portage to control display.
>   This file's name would end in .news.<LC>.txt
> - A GuideXML-formatted errata document.
>     This would be the actual migration guide, such as the contents of
> the http://www.gentoo.org/doc/en/yoursql-upgrading.xml
>     referenced by the example.
>   This file's name would end in .guide.<LC>.xml
> - The leading part of the filename would be as in ciaranm's GLEP

Oh god help. This also points to another reason why this is not such a 
good idea. Writing guideXML is a lot more work than writing an e-mail 
format file (ciaran's proposed format for those who didn't recognize it).

Also having double files containing the same information is broken by 
design. This doesn't mean that all information should be in the news 
file. Let me give an example that would have been relevant some time ago.

Title: Incompatible subversion repository change
Author: Paul de Vrieze <pauldv@gentoo.org>
Content-Type: text/plain
Posted: 2005-11-04
Version: 1
Display-If-Installed: <dev-util/subversion-0.34.0

Subversion has a new repository layout. This new layout is incompatible 
with repositories created with versions before 0.34.0. If you only use 
this machine as client, there are no consequences.

If this machine contains repositories however, these must be dumped before 
installing >=dev-util/subversion-0.34.0. After installation new 
repositories can be created and the dumps can be reloaded.

For more information on dumping and loading see the subversion migration 
guide:
http://subversion.tigris.org/subversion_migration.


<the above url is not correct, everything else would have been>

If I have to write such a file in guidexml it would be a lot more 
complicated. Further this news item would only be relevant to people 
providing older subversion repositories wanting to update. As erata would 
contain all these files, it would be a swamp, hard to wade through.

I also fail to see where such a file as illustrated above is unclear to 
read. I prefer it over a bloated webpage with all kinds of slowness and 
eyecandy.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Tres Melton]

On Thu, 2005-11-03 at 19:29 -0500, Nathan L. Adams wrote:

> <rant>
> You're just missing the fact that a flat file (or whatever it is you're
> clinging to; for the purpose of this rant, I shall refer to your simple
> data format as "flat file") has trade-offs, just like XML's trade off is
> parsing overhead. XML was designed to solve certain problems;
> portability of data, separation and portability of presentation from the
> data, etc. Complexity in the parser is the trade-off.
> 
Perhaps I'm missing something here but I thought the concept of --news
is to get information in front of as many eyes as possible.  It seems
that information could just as easily be:

------------------------------------------------------------------------
This upgrade is going to be a PITA and we highly recommend that you read
one (or more) of the following resources before proceeding:

http://www.gentoo.org/wherever/upgrade-instructions
http://forums.gentoo.org/thread=whatever
http://lists.gmane.org/link-to-mail-thread.

You have been warned.  Have a nice day. (tm)
------------------------------------------------------------------------

This would have the simplicity of a flat file and all the functionality
of XML at once so we can eat our cake too.  Just a thought.

> 
> Nathan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDaqt52QTTR4CNEQARAoQ1AJ42ItHkJ37eFUY8rSoGpN/dVoKIFACeJi7b
> KW6/pzn8VEKi3hO0Gqomsms=
> =cSQh
> -----END PGP SIGNATURE-----

Best Regards,
-- 
Tres Melton
IRC & Gentoo: RiverRat

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Thierry Carrez]

Paul de Vrieze wrote:

> Oh god help. This also points to another reason why this is not such a 
> good idea. Writing guideXML is a lot more work than writing an e-mail 
> format file (ciaran's proposed format for those who didn't recognize it).
> 
> Also having double files containing the same information is broken by 
> design.

OK so there is two options :

1- every "news" requires a GuideXML/RST/whatever errata at a central web
location
Pros:
- non-portage user can easily browse errata
- consistency in documentation
Cons:
- work overhead for errata-writing dev

2- every "news" requires just a short text-based item, extra doc is optional
Pros:
- flexibility: short news don't require writing extra doc
- external doc reuse: the documentation referenced in the news item can
be some upstream upgrade doc when sufficient
Cons:
- lack of consistency and difficulty for non-portage users to browse

We can have the best of both worlds if we find a way to reduce the work
overhead to 0 (using some kind of news2errataXml translator ?). If we
can't, I tend to favor the second solution...

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Dan Meltzer]

erm, and how exactly do you propose that the user who
doesn't-read-the-site-because-it-has-no-useful-information-currently
will learn about errata.g.o?

On 11/3/05, Nathan L. Adams <nadams@ieee.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian Harring wrote:
> > Not necessarily the website imo, some central store where it's pushed
> > out to all of the locations though (which I suspect you're getting
> > at).
>
> I forgot to clarify one point. I'm saying that http://errata.g.o/ should
> be the *official* source where users go to find the info, not
> neccessarity the place where the raw data is stored and pushed to other
> places (although it certainly could be).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFDarzS2QTTR4CNEQARAlB7AJsHfqCVL160KApWZU7iuqNtCb9SWwCcCtRR
> D2e1H1U208kQQNzLDo9CpGk=
> =kiyo
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Marius Mauch]

Thierry Carrez wrote:
> Paul de Vrieze wrote:
> 
> 
>>Oh god help. This also points to another reason why this is not such a 
>>good idea. Writing guideXML is a lot more work than writing an e-mail 
>>format file (ciaran's proposed format for those who didn't recognize it).
>>
>>Also having double files containing the same information is broken by 
>>design.
> 
> 
> OK so there is two options :
> 
> 1- every "news" requires a GuideXML/RST/whatever errata at a central web
> location
> Pros:
> - non-portage user can easily browse errata
> - consistency in documentation
> Cons:
> - work overhead for errata-writing dev
> 
> 2- every "news" requires just a short text-based item, extra doc is optional
> Pros:
> - flexibility: short news don't require writing extra doc
> - external doc reuse: the documentation referenced in the news item can
> be some upstream upgrade doc when sufficient
> Cons:
> - lack of consistency and difficulty for non-portage users to browse

I don't understand the last point really ... You can always transform 
the plain text message into GuideXML (you just might not have all the 
fancy markup, but even that could be solved).
So all in all I really don't understand this whole subthread, I'll just 
post how I see it right now:
There will be one location (either in the tree or replicated to the 
tree) which contains summary style notices for important tree updates. 
The format of the notices should be as simple as possible (I've learned 
this the hard way with the GLSA system) while allowing at least basic 
filtering rules, I think the format described in the GLEP is good for 
that. It should also be possible to easily transform those notices into 
a website (be it errata.g.o or something else) that matches the general 
look and feel of the Gentoo websites, should be simple enough with the 
given format (but then I don't know much about XSLT).
If a notice needs a more detailed explanation that should be submitted 
in the docs section (maybe a special "Upgrade Guides" section?) and 
linked to from the notice.
Should also be simple enough to replicate notices to thw www.g.o 
frontpage/GWN/-announce/...

Just to make this crystal clear again: The main point of the notices is 
to get peoples attention so they become aware that some upgrade might 
not be as smooth as usual, not necessarily to provide them with all 
potential information, that's the job of the (external) upgrade guides.

One thing I'd be interested in before adding support for this: How many 
such notices do people here expect per year? Mainly trying to get an 
idea how this would affect the tree size  and if it needs some 
"housekeeping" (e.g. five files per month aren't an issue, 500 files per 
month might be).

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Dan Meltzer wrote:
> erm, and how exactly do you propose that the user who
> doesn't-read-the-site-because-it-has-no-useful-information-currently
> will learn about errata.g.o?

If all of the other replicated sources (forums, mailing lists, GWN, etc)
and 'emerge --news' link back to errata.g.o, they'll figure it out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa2N82QTTR4CNEQARAquRAJ9mKsu0QOubuK/IdSB1eyJakHgl+QCeJQqE
qhBjRtcR6zxebGOr1IjNAp4=
=LtIp
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Paul de Vrieze wrote:
> What is worse is that some 
> users might not update for a prolongued time (6 months). At that time 
> they will not find the information in the erata list anymore. But they 
> will get the RELEVANT news delivered by emerge/enews.

Why would a "SomeSQL 1.0 to 1.1" guide ever need to dissappear? Surely
errata.g.o would have archiving/searching. But I do see your point about
emerge filtering out the unwanted stuff.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa2RQ2QTTR4CNEQARAv0fAKCFOH6RedaYBSG069nX+aAtmQ/YWgCgjVlE
RAF3N34PDvrtY88ks3QwRhc=
=b+7v
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Thierry Carrez wrote:
> Paul de Vrieze wrote:
>
>>Oh god help. This also points to another reason why this is not such a 
>>good idea. Writing guideXML is a lot more work than writing an e-mail 
>>format file (ciaran's proposed format for those who didn't recognize it).
>>
>>Also having double files containing the same information is broken by 
>>design.

By the way, we're talking about 1 source file being translated into
multiple formats (email for the mailing list, news blurb for GWN, etc),
and the idea is far from broken.

> 
> OK so there is two options :
> 
> 1- every "news" requires a GuideXML/RST/whatever errata at a central web
> location

[snip]

> 2- every "news" requires just a short text-based item, extra doc is optional
> Pros:

[snip]

> We can have the best of both worlds if we find a way to reduce the work
> overhead to 0 (using some kind of news2errataXml translator ?). If we
> can't, I tend to favor the second solution...
> 

This is a wonderful comprimise. And one might even sucker me into
helping write the tool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa2ZE2QTTR4CNEQARAvNVAJ4+q94QFV+fik4FRCywX1N1Yh1s9QCfab7m
trmF40e9e33usGS7EbpMjoQ=
=tPJE
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Thu, 2005-11-03 at 20:24 -0500, Nathan L. Adams wrote:
> *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> a web browser by default. Otherwise a vast majority of users would never
> get Gentoo installed in the first place. The "lightweight" requirement
> appears to just be your way of subverting the current documentation
> standards (because of your XML hatred).

*sigh*

Then I guess we're wasting our time getting the Handbook converted to
plain text for *every* release.  It's on the CD itself, have a look.  No
need for a web browser of any kind.

You really need to check your facts before posting.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Thu, 2005-11-03 at 19:33 -0600, Brian Harring wrote:
> On Thu, Nov 03, 2005 at 08:24:27PM -0500, Nathan L. Adams wrote:
> > I'm also commenting on the part that *wrongly* states "It is not
> > reasonable to expect all users to have an MTA, *web browser*, email
> > client, cron daemon or text processing suite available on their system.
> > In particular, this means that any markup to be parsed must be in a very
> > simple format."
> > 
> > *ALL* of the official docs are GuideXML; Gentoo *expects* users to have
> > a web browser by default. Otherwise a vast majority of users would never
> > get Gentoo installed in the first place. The "lightweight" requirement
> > appears to just be your way of subverting the current documentation
> > standards (because of your XML hatred).
> 
> We actually have links in the base profile iirc, either way, the 
> example of where this breaks down is headless servers...

There are no web browsers in the base profile, the stages, nor in the
"system" target for any architecture or project.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Thu, 2005-11-03 at 20:36 -0500, Nathan L. Adams wrote:
> So you installed your server without reading *any* documenation? (Don't
> lie). And you expect that the average user installs a Gentoo server
> without at least referencing the documentation? Pa-leaze.

less /mnt/cdrom/docs/handbook/txt/install.txt

No web browser, so can you please quit beating this dead horse.  It
isn't even funny anymore.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 14:38, Nathan L. Adams wrote:
> Paul de Vrieze wrote:
> > What is worse is that some
> > users might not update for a prolongued time (6 months). At that time
> > they will not find the information in the erata list anymore. But
> > they will get the RELEVANT news delivered by emerge/enews.
>
> Why would a "SomeSQL 1.0 to 1.1" guide ever need to dissappear? Surely
> errata.g.o would have archiving/searching. But I do see your point
> about emerge filtering out the unwanted stuff.

It would be hidden in the forrest. Even if I did a search on SomeSQL, it 
might return a number of news items on SomeSQL. That is besides the fact 
that I have 737 packages installed. I'm not going to search news on all 
of them. Archiving would of course be provided, but searching is not 
usefull for updating.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Thu, 2005-11-03 at 20:43 -0500, Stephen P. Becker wrote:
> How about getting some facts straight before running your mouth?  Gentoo 
> most certainly does not expect users to have a web browser to install. 
> The last time I actually installed on x86 (which was some time ago 
> admittedly), there was a .txt version of the install guide on the livecd.

Exactly.

> Even then, the web browser you are speaking of runs directly off the 
> livecd.  So, what happens when there is critical news to be read during 
> the install phase inside the chroot, but no web browser is yet 
> installed?  Are you suggesting we bloat stage1 and stage2 with some sort 
> of XML parser so that the user can read news without having to kill the 
> emerge and read the news outside the chroot?  I think you would have a 
> seriously hard time convincing the release folks this is a good idea.

We won't add more cruft to the stages.  We're already to the point of
trying to determine ways to reduce stage size, not increase it.

> Furthermore, it is not possible to include any sort of XML parser with 
> installers for certain arches which use very minimal netboots for the 
> default installation method.  So really, your complaints about the 
> "lightweight" requirement appears to just be a way of subverting 
> attention away from the real reasons it is a good idea, and towards 
> maintaining a flamewar with ciaran that you will surely lose.

What is it for SPARC again?  4MB for both kernel + initrd?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Fri, 2005-11-04 at 10:02 +0100, Paul de Vrieze wrote:
> No, gentoo expects people to have access to a webbrowser. But not all the 
> time. It is perfectly reasonable to expect people to make a nice printout 
> of the handbook at the office, and then take it at home to install a nice 
> new gentoo box.

We *do* provide the Handbook in PDF on our releases. ;]

> > The news directory shouldn't the main source of the migration guides;
> > the website should be (one central page that can feed other sources).
> 
> The website should not as it a pull source of information. It requires 
> users to actively acquire the information. What is worse is that some 
> users might not update for a prolongued time (6 months). At that time 
> they will not find the information in the erata list anymore. But they 
> will get the RELEVANT news delivered by emerge/enews.

Right.  This is the entire point that Stuart was making from the
beginning.  The *only* thing that we can guarantee users will look at
when doing updates is portage itself.  Anything else is ancillary to the
tree.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Fri, 2005-11-04 at 10:06 +0100, Paul de Vrieze wrote:
> I expect the average user to make a nice printout of the handbook. The 
> print version of the handbook was provided mainly on user request you 
> know. It also works a lot easier than either flipping screens to 
> links/lynx all the time or running up and down to another computer (if 
> available).

I think everyone has also missed that there *is* the ability to install
Gentoo completely offline.  I've done it before on a laptop without any
Internet access, besides doing it for QA during releases.

We do not expect the user to have a web browser, broadband, or Internet
access of any kind to perform an installation.  Using the installation
documents as an example of "requiring a web browser" is asinine.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Xavier Neys]

Ciaran McCreesh wrote:
> On Wed, 2 Nov 2005 19:33:37 +0100 Jan Kundrát <jkt@gentoo.org> wrote:
> | "Once this tool is implemented and well tested it can be integrated
> | into portage."
> 
> can ! will. It might, but don't count on it.
> 
> | GLSA already contains stuff for marking items as valid only for given
> | systems, for "injecting" them etc. Why don't use existing code? Why
> | duplication?
> 
> Because it's quicker to invent a wheel which is actually round.

Reinventing rounder wheels seems to be a common hobby.

> | > You think XML magically makes things compatible? Then I suggest you
> | > write a GuieXML to Docbook conversion tool, and see how many
> | > thousand lines of XSLT it takes. All XML does is move the
> | > conversion and parsing problems to a different, more complex level.
> | 
> | I'm not familiar with DocBook, but I doubt I'll need thousands of
> | lines of code.
> 
> Oh? Our GuideXML to HTML conversion is thousands of lines of code...

Plain wrong, but you have always made it clear that you are not only biased 
against XML for anything, but also very much XML challenged.
Don't worry, some are even worse than you are, worse enough to claim that XML 
is hard to parse because "XML files from a programming perspective require 
extra logic to parse. Compare the following key value pair and xml tag pseudo 
parsing logic for configuration:
<tag1>entry</tag1>
Hit a >, tag1 as realized tag name, read until <, read ahead one to ensure a 
closing slash, read until > to get the tag name, compare tag name with 
previous tag name to see what tag it's closing. store value attached to tag1."

Just a short sample against metadata.xml using ruby/dom instead of python/sax:
http://dev.gentoo.org/~neysx/metax.rb

Discarding XML for the reasons some are using is like recommending key=value 
flat .ini files because windows used it in the 80s.
They have to be parsed as well, and, as opposed to XML, you have to check for 
unknown keys, double keys, missing ones, then you need some grouping and you 
introduce [sections], which you have to check as well, no doubles, no missing 
ones, no illegal ones, then you need a deeper hierarchy and you use 
key=/path/to/another/file.ini...

Both have reasons to be used, neither is a one-fits-all answer.

Anyway, this is getting off-topic, and, FWIW, I believe the suggested format 
is adequate because it is light, easy to write, read, parse, and even 
transform into XML should one process ever need it. Besides, it is very much 
standard, if it's good enough for billions of mail and http messages a day, 
it's probably good enough for us.

-- 
/  Xavier Neys
\_ Gentoo Documentation Project
/  French & Internationalisation Lead
\  http://www.gentoo.org/doc/en
/\


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Xavier Neys]

Thierry Carrez wrote:
> Paul de Vrieze wrote:
> 
> 
>>Oh god help. This also points to another reason why this is not such a 
>>good idea. Writing guideXML is a lot more work than writing an e-mail 
>>format file (ciaran's proposed format for those who didn't recognize it).
>>
>>Also having double files containing the same information is broken by 
>>design.
> 
> 
> OK so there is two options :
> 
> 1- every "news" requires a GuideXML/RST/whatever errata at a central web
> location
> Pros:
> - non-portage user can easily browse errata
> - consistency in documentation
> Cons:
> - work overhead for errata-writing dev
> 
> 2- every "news" requires just a short text-based item, extra doc is optional
> Pros:
> - flexibility: short news don't require writing extra doc
> - external doc reuse: the documentation referenced in the news item can
> be some upstream upgrade doc when sufficient
> Cons:
> - lack of consistency and difficulty for non-portage users to browse
> 
> We can have the best of both worlds if we find a way to reduce the work
> overhead to 0 (using some kind of news2errataXml translator ?). If we
> can't, I tend to favor the second solution...

Both can be done.
Posting news items on our front page can be done today, publishing upgrade 
notes can be done today, grouping all upgrade documents in an upgrade category 
on the main doc index (docs.gentoo.org) can be done today, having 
upgrade.gentoo.org point to it can be done one hour later.
All of the above does not require a single line of code.

I suppose the news snippets could also be integrated in packages.gentoo.org, 
hopefully without requiring too much work.

-- 
/  Xavier Neys
\_ Gentoo Documentation Project
/  French & Internationalisation Lead
\  http://www.gentoo.org/doc/en
/\
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Lance Albertson]

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

Ciaran McCreesh wrote:

> News Item Source
> ----------------
> 
> News items are to be made available via the Portage tree. This removes any
> need for polling of a remote source.
> 
> A new directory, ``news/``, will be created in the main tree.  Commit access
> to this directory will be handled in the same way as for the rest of the
> tree. This directory will contain further subdirectories named
> ``yyyy-mm/``, where ``yyyy`` is the current year and ``mm`` is the current
> month number (01 for January through 12 for December) -- this extra level
> of separation will help keep news items more manageable.

Could we possibly use a system thats a mix of how GLSA's and GLEP's are
handled currently? The main point here being that we can move the actual
cvs location outside of gentoo-x86 and put it in somewhere more
appropriate for translators. The example here is, all the GLSA's are
currently not in the gentoo-x86 module. The regeneration script on our
master mirror syncs with the gentoo module location for GLSA's and
copies those files in its current location in the tree.

Perhaps we could do the same for the news item where they actually
reside in the documentation module and the 'plain text' versions of the
files get copied into the tree at regen time. Correct me if I'm wrong,
but I think GLEPs are currently created as RST files then you use a
converter script to make it in guidexml. Then you actually commit both
the rst and xml file to cvs. Could we possibly do the same here to make
it simple? Automation is great where it fits best. I'd rather not deal
with conversion on the server end, I'd prefer the conversion be handled
by the developer/translator as they can double check the conversion
script better than the script itself can.

Poke at that :-)

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Paul de Vrieze wrote:
> On Friday 04 November 2005 14:38, Nathan L. Adams wrote:
> 
>>Paul de Vrieze wrote:
>>
>>>What is worse is that some
>>>users might not update for a prolongued time (6 months). At that time
>>>they will not find the information in the erata list anymore. But
>>>they will get the RELEVANT news delivered by emerge/enews.
>>
>>Why would a "SomeSQL 1.0 to 1.1" guide ever need to dissappear? Surely
>>errata.g.o would have archiving/searching. But I do see your point
>>about emerge filtering out the unwanted stuff.
> 
> 
> It would be hidden in the forrest. Even if I did a search on SomeSQL, it 
> might return a number of news items on SomeSQL. That is besides the fact 
> that I have 737 packages installed. I'm not going to search news on all 
> of them. Archiving would of course be provided, but searching is not 
> usefull for updating.

You update all 737 packages with each emerge? I don't see any validity
in your point; a nice http://errata.g.o/ site with archived guides and
search wouldn't preclude 'emerge --news' in any way.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa4R12QTTR4CNEQARApTFAKCL3rZ88STZtuu1EZUw/iSFf8NJMACfXtHu
UyKLcgsYF4+nC+ezKSC4Of8=
=a4Ki
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Chris Gianelloni wrote:
> On Thu, 2005-11-03 at 20:24 -0500, Nathan L. Adams wrote:
> 
>>*ALL* of the official docs are GuideXML; Gentoo *expects* users to have
>>a web browser by default. Otherwise a vast majority of users would never
>>get Gentoo installed in the first place. The "lightweight" requirement
>>appears to just be your way of subverting the current documentation
>>standards (because of your XML hatred).
> 
> 
> *sigh*
> 
> Then I guess we're wasting our time getting the Handbook converted to
> plain text for *every* release.  It's on the CD itself, have a look.  No
> need for a web browser of any kind.
> 
> You really need to check your facts before posting.
> 

I've done several Gentoo installs and never knew the plain text versions
existed. I think you might want to check the assumption that just
because they exists they are widely known (and if they aren't known to
exist, they don't do squat for the end user). Surely we're not going to
delve into an arguement over whether the web is the best way to
distribute information...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa4U92QTTR4CNEQARAjkzAJ0YS2F/6zWLZeLQ0tbvIYNIqoe1PQCfcV53
bLnhNPoCJDNGrHuIw3pxEEA=
=rSj8
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Chris Gianelloni wrote:
> On Thu, 2005-11-03 at 20:36 -0500, Nathan L. Adams wrote:
> 
>>So you installed your server without reading *any* documenation? (Don't
>>lie). And you expect that the average user installs a Gentoo server
>>without at least referencing the documentation? Pa-leaze.
> 
> 
> less /mnt/cdrom/docs/handbook/txt/install.txt
> 
> No web browser, so can you please quit beating this dead horse.  It
> isn't even funny anymore.
> 

That's a great and wonderful alternative, but the policy is to publish
documentation in GuideXML:

http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml#doc_chap3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa4a42QTTR4CNEQARAqGnAJ4gfJLCMmK5/tU5lmnszaR1fW1MSQCfTyYK
wh/HaL69456P9eOqc7sabDc=
=D8T6
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Xavier Neys wrote:
> Thierry Carrez wrote:
> 
>> Paul de Vrieze wrote:
>>
>>
>>> Oh god help. This also points to another reason why this is not such
>>> a good idea. Writing guideXML is a lot more work than writing an
>>> e-mail format file (ciaran's proposed format for those who didn't
>>> recognize it).
>>>
>>> Also having double files containing the same information is broken by
>>> design.
>>
>>
>>
>> OK so there is two options :
>>
>> 1- every "news" requires a GuideXML/RST/whatever errata at a central web
>> location
>> Pros:
>> - non-portage user can easily browse errata
>> - consistency in documentation
>> Cons:
>> - work overhead for errata-writing dev
>>
>> 2- every "news" requires just a short text-based item, extra doc is
>> optional
>> Pros:
>> - flexibility: short news don't require writing extra doc
>> - external doc reuse: the documentation referenced in the news item can
>> be some upstream upgrade doc when sufficient
>> Cons:
>> - lack of consistency and difficulty for non-portage users to browse
>>
>> We can have the best of both worlds if we find a way to reduce the work
>> overhead to 0 (using some kind of news2errataXml translator ?). If we
>> can't, I tend to favor the second solution...
> 
> 
> Both can be done.
> Posting news items on our front page can be done today, publishing
> upgrade notes can be done today, grouping all upgrade documents in an
> upgrade category on the main doc index (docs.gentoo.org) can be done
> today, having upgrade.gentoo.org point to it can be done one hour later.
> All of the above does not require a single line of code.
> 
> I suppose the news snippets could also be integrated in
> packages.gentoo.org, hopefully without requiring too much work.
> 

Great, then I hope that the scope of the GLEP gets expanded to include:

- - central website (ugrade.g.o or errata.g.o or whatever)
- - external docs follow existing doc policy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa4d82QTTR4CNEQARApNQAJ9RzRxl1y/KRd/5xhVh0gQuwU4OEQCdFofK
pC5D+BbzmgOcSDdW3IookUs=
=J44D
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Danny van Dyk]

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

Nathan L. Adams schrieb:
| 6. Ciaran is completely biased against XML (or anything that isn't
| stored as a simple flat file) ;)
On the other hand one could say that there are Gentoo-Devs which are
biased against anything that can work without using XML.

To quote Wikipedia.org[1]:
"The Extensible Markup Language (XML) is a W3C-recommended
general-purpose markup language for *creating special-purpose markup
languages*." (Emphasis added by me.)

There are occasions where creating a completely new markup language with
XML does make sense. However, this particular enhancement does not need it.

IMHO a text based file has a big advantage in this proposed application
over fileformats which use XML: Any administrator can read it with his
editor of choice, right from the console.

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

iD8DBQFDa4bFaVNL8NrtU6IRAgQDAJ93+rj1sI6sADnq3QCLpCWE3BYx4gCfdrv3
/6p4ZR5A0kR7akOoCEuT/44=
=8moA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Fri, 2005-11-04 at 10:58 -0500, Nathan L. Adams wrote:
> I've done several Gentoo installs and never knew the plain text versions
> existed. I think you might want to check the assumption that just
> because they exists they are widely known (and if they aren't known to
> exist, they don't do squat for the end user). Surely we're not going to
> delve into an arguement over whether the web is the best way to
> distribute information...

Ehh...

It is listed in the MOTD on the installation media.  I'm not making any
assumptions on this.  It's really not our fault when the user base
doesn't read what is sitting in front of them, plainly on the screen.

Thank you for proving my point.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Chris Gianelloni]

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

On Fri, 2005-11-04 at 11:05 -0500, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> > On Thu, 2005-11-03 at 20:36 -0500, Nathan L. Adams wrote:
> > 
> >>So you installed your server without reading *any* documenation? (Don't
> >>lie). And you expect that the average user installs a Gentoo server
> >>without at least referencing the documentation? Pa-leaze.
> > 
> > 
> > less /mnt/cdrom/docs/handbook/txt/install.txt
> > 
> > No web browser, so can you please quit beating this dead horse.  It
> > isn't even funny anymore.
> > 
> 
> That's a great and wonderful alternative, but the policy is to publish
> documentation in GuideXML:

No it isn't...

> 
> http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml#doc_chap3

Yeah, see, this is a case where not understanding the structure of
Gentoo gives you the wrong impression.  The GDP's policy applies to the
GDP.  That is not a global developer policy of any kind.  It is a policy
by a project, for that project.

If I were, for example, to write up a nice guide for something on the
games team and do it all in ASCII art, that policy has no bearing on
what I do.  If I were to write something for the GDP, then it would.

At any rate, that has *zero* bearing on whether or not our update
information needs to be written in GuideXML, so there's no point in
arguing it with you.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Grobian]

Danny van Dyk wrote:
> IMHO a text based file has a big advantage in this proposed application
> over fileformats which use XML: Any administrator can read it with his
> editor of choice, right from the console.

This is an important aspect for sure, but why can't such file be 
generated from a marked up one?  Because the same message will be put in 
multiple forms (ideally) it is best to have a version with all the 
required meta-data to generate all the other formats, because if you 
have to add such meta-data it's usually much worse (= manual or 
conditional human work).

Some people like reading console messages, others plain text mail 
messages, others want html marked up mail messages, other others like 
reading an rss-feed, and of course there are people that like to read 
the full fledged funky marked up with all hyperlinks possible html 
version on the web.
I think the only real importance is that all representations can easily 
be generated from the original source, be that XML, reStructuredText or 
any other format.

With regard to being it hard to write or not, I think these kind of 
messages are very well suited for templates, so it is just a matter of 
filling in the message, which should make the underlying format not so 
important.

Just my €0.02 on the XML vs. plain text discussion.


-- 
Fabian Groffen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Chris Gianelloni wrote:
> On Fri, 2005-11-04 at 10:58 -0500, Nathan L. Adams wrote:
> 
>>I've done several Gentoo installs and never knew the plain text versions
>>existed. I think you might want to check the assumption that just
>>because they exists they are widely known (and if they aren't known to
>>exist, they don't do squat for the end user). Surely we're not going to
>>delve into an arguement over whether the web is the best way to
>>distribute information...
> 
> 
> Ehh...
> 
> It is listed in the MOTD on the installation media.  I'm not making any
> assumptions on this.  It's really not our fault when the user base
> doesn't read what is sitting in front of them, plainly on the screen.
> 
> Thank you for proving my point.
> 

And what point would that be exactly? Console messages are ineffective?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa5Ls2QTTR4CNEQARAm5NAKCiOQEkK07nz4KFfSY+5uzeUNMN2wCfUe1Q
LSTG+k4lWKo6v6Wl1AR+424=
=Ar9r
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Lance Albertson]

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

Nathan L. Adams wrote:

>>>It is listed in the MOTD on the installation media.  I'm not making any
>>>assumptions on this.  It's really not our fault when the user base
>>>doesn't read what is sitting in front of them, plainly on the screen.
>>>
>>>Thank you for proving my point.
>>>
> 
> 
> And what point would that be exactly? Console messages are ineffective?

That you haven't completely read documentation that was right on your
screen. I mean *read*, not glanced. I've finally read through ciaranm's
GLEP and I get the impression you only skimmed through it. I suggest you
stick with exact wording from the GLEP for discussion on this thread
rather than assumptions made on arguments.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Chris Gianelloni wrote:
> 
> Yeah, see, this is a case where not understanding the structure of
> Gentoo gives you the wrong impression.  The GDP's policy applies to the
> GDP.  That is not a global developer policy of any kind.  It is a policy
> by a project, for that project.
> 
> If I were, for example, to write up a nice guide for something on the
> games team and do it all in ASCII art, that policy has no bearing on
> what I do.  If I were to write something for the GDP, then it would.
> 
> At any rate, that has *zero* bearing on whether or not our update
> information needs to be written in GuideXML, so there's no point in
> arguing it with you.
> 

So you're saying that Gentoo consists of projects that are completely
'silo'd up' and have no bearing whatsoever on each other. Then the
DevRel project only has bearing on those who actually join DevRel. Neat,
a group formed for the sole purpose of coordinating itself. Security
need only concern itself with securing its members (from who knows
what!), and infra can just ignore the needs of everyone else (different
project!). I wonder how any of the other projects *ever* made it onto
the website...

The errata.g.o (not the summaries w/ link that emerge would output)
would obviously be documentation, would obviously be governed by the Doc
rules, and it would be irrelevant which staff member happened to publish
a particular guide. If Gentoo really is as balkanized as you state, then
it is a sad state of affairs indeed. Maybe the 'full fledged' versions
should be GuideXML-lite or something, I'm not sure, but your argument is
just silly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa5WH2QTTR4CNEQARAlERAKCeVue4ATD4fXBgLGdRAWt4Gi7vWgCcCs7R
w/Pvjk9vv2C00HmrTkhBnHU=
=Eiba
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Grobian wrote:
> Danny van Dyk wrote:
> 
>> IMHO a text based file has a big advantage in this proposed application
>> over fileformats which use XML: Any administrator can read it with his
>> editor of choice, right from the console.
> 
> 
> This is an important aspect for sure, but why can't such file be
> generated from a marked up one?  Because the same message will be put in
> multiple forms (ideally) it is best to have a version with all the
> required meta-data to generate all the other formats, because if you
> have to add such meta-data it's usually much worse (= manual or
> conditional human work).
> 
> Some people like reading console messages, others plain text mail
> messages, others want html marked up mail messages, other others like
> reading an rss-feed, and of course there are people that like to read
> the full fledged funky marked up with all hyperlinks possible html
> version on the web.
> I think the only real importance is that all representations can easily
> be generated from the original source, be that XML, reStructuredText or
> any other format.
> 
> With regard to being it hard to write or not, I think these kind of
> messages are very well suited for templates, so it is just a matter of
> filling in the message, which should make the underlying format not so
> important.
> 
> Just my €0.02 on the XML vs. plain text discussion.
> 
> 

A very good point. You could even offer a web form for those who don't
even want to edit the template by hand.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa5YF2QTTR4CNEQARAly+AKCjnT+yONZPAmTO+cccByWeQcaVsQCfQ4Vb
K8Cwc/QQNKxAe/Q0VknIOiU=
=2Dow
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Nathan L. Adams]

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

Lance Albertson wrote:
> Nathan L. Adams wrote:
> 
> 
>>>>It is listed in the MOTD on the installation media.  I'm not making any
>>>>assumptions on this.  It's really not our fault when the user base
>>>>doesn't read what is sitting in front of them, plainly on the screen.
>>>>
>>>>Thank you for proving my point.
>>>>
>>
>>
>>And what point would that be exactly? Console messages are ineffective?
> 
> 
> That you haven't completely read documentation that was right on your
> screen. I mean *read*, not glanced. I've finally read through ciaranm's
> GLEP and I get the impression you only skimmed through it. I suggest you
> stick with exact wording from the GLEP for discussion on this thread
> rather than assumptions made on arguments.
> 
> Cheers-
> 

Actually, Lance, I have read it. Where does it say anything about a
central web repository for the docs in question? Where does it specify
the format of those? It doesn't. It assumes that all Gentoo officially
cares about is the emerge --news output. Any external docs can live
anywhere in any format. Users have asked for a central location for
these documents and the transient nature of your current local portage
tree doesn't give that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa5cY2QTTR4CNEQARAhBcAJ4oT9Wwf5ohK4prQgDSQNGCKoE3WwCeNCct
C16jLYYC4zKemRdzcJFNrr4=
=IQ1Y
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Daniel Ostrow]

On Fri, 2005-11-04 at 12:08 -0500, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> > 
> > Yeah, see, this is a case where not understanding the structure of
> > Gentoo gives you the wrong impression.  The GDP's policy applies to the
> > GDP.  That is not a global developer policy of any kind.  It is a policy
> > by a project, for that project.
> > 
> > If I were, for example, to write up a nice guide for something on the
> > games team and do it all in ASCII art, that policy has no bearing on
> > what I do.  If I were to write something for the GDP, then it would.
> > 
> > At any rate, that has *zero* bearing on whether or not our update
> > information needs to be written in GuideXML, so there's no point in
> > arguing it with you.
> > 
> 
> So you're saying that Gentoo consists of projects that are completely
> 'silo'd up' and have no bearing whatsoever on each other. Then the
> DevRel project only has bearing on those who actually join DevRel. Neat,
> a group formed for the sole purpose of coordinating itself. Security
> need only concern itself with securing its members (from who knows
> what!), and infra can just ignore the needs of everyone else (different
> project!). I wonder how any of the other projects *ever* made it onto
> the website...

Yet more proof that you don't understand what you are talking
about...not meant to be insulting just stating that you don't. Just
because some groups (DevRel, Infra, etc.) have farther reaching tendrils
doesn't mean that every group does. 

For example, each arch team has a slightly different way to go about
allowing package maintainers to keyword their own packages on a given
arch...some teams insist that the maintainer join the arch team...some
allow for special arrangements (they all follow the same basic
guidelines).

With documentation there are actually 2 different types, those bits that
fall under the GDP and those that fall under the herd that uses them.
Take Chris' games example, the games team is free to release an FAQ in
plain text in Pig Latin if they want to, so long as it is on their own
project page. The GDP policy -only- covers the GDP...not anyone else, so
if Chris wanted to move his plain text Pig Latin doc to the official
Docs repository he would have to make an English version and make it
GuideXML. That's it plain and simple.

> The errata.g.o (not the summaries w/ link that emerge would output)
> would obviously be documentation, would obviously be governed by the Doc
> rules, and it would be irrelevant which staff member happened to publish
> a particular guide. If Gentoo really is as balkanized as you state, then
> it is a sad state of affairs indeed. Maybe the 'full fledged' versions
> should be GuideXML-lite or something, I'm not sure, but your argument is
> just silly.

Another thing you seem to be missing is that the GLEP specifically
separates the news from the documentation. The news or errata is just a
plain text *short* summary that something needs to be attended to. It
can, but does not always have to, link to further more detailed
*documentation*. Note then that what would go up on errata.g.o in this
case would be the *summary* (which would not necessarily be governed by
the GDP or it's policies) and *not* the full documentation. Said summary
would contain links to any relevant *documentation* which would then be
governed by the GDP if said documentation was in fact Gentoo created and
in the official Docs repository.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jon Portnoy]

On Fri, Nov 04, 2005 at 12:08:23PM -0500, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> > 
> > Yeah, see, this is a case where not understanding the structure of
> > Gentoo gives you the wrong impression.  The GDP's policy applies to the
> > GDP.  That is not a global developer policy of any kind.  It is a policy
> > by a project, for that project.
> > 
> > If I were, for example, to write up a nice guide for something on the
> > games team and do it all in ASCII art, that policy has no bearing on
> > what I do.  If I were to write something for the GDP, then it would.
> > 
> > At any rate, that has *zero* bearing on whether or not our update
> > information needs to be written in GuideXML, so there's no point in
> > arguing it with you.
> > 
> 
> So you're saying that Gentoo consists of projects that are completely
> 'silo'd up' and have no bearing whatsoever on each other. Then the
> DevRel project only has bearing on those who actually join DevRel. Neat,
> a group formed for the sole purpose of coordinating itself. Security
> need only concern itself with securing its members (from who knows
> what!), and infra can just ignore the needs of everyone else (different
> project!). I wonder how any of the other projects *ever* made it onto
> the website...

No, he's saying you're talking out of your behind. And you continue to 
do so

Gentoo projects have their own areas of responsibility, the GDP's area 
of responsibility is the GDP, devrel's area of responsibility is 
developers, infra's area of responsibility is infrastructure.

Thank you, come again

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Fri, 04 Nov 2005 15:26:28 +0100 Xavier Neys <neysx@gentoo.org> wrote:
| > Oh? Our GuideXML to HTML conversion is thousands of lines of code...
| 
| Plain wrong, but you have always made it clear that you are not only
| biased against XML for anything, but also very much XML challenged.

Run a wc -l on guide.xsl sometime. Either wc is lying or that alone is
thousands of lines of code.

| Don't worry, some are even worse than you are, worse enough to claim
| that XML is hard to parse because "XML files from a programming
| perspective require extra logic to parse. Compare the following key
| value pair and xml tag pseudo parsing logic for configuration:
| <tag1>entry</tag1>
| Hit a >, tag1 as realized tag name, read until <, read ahead one to
| ensure a closing slash, read until > to get the tag name, compare tag
| name with previous tag name to see what tag it's closing. store value
| attached to tag1."

That is not parsing XML. That is parsing some arbitrary markup language
you just invented. Please read the XML specification, note how complex
some of the little used side features are, and then remember that a
compliant XML parser has to implement **all** of them.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Fri, 04 Nov 2005 08:37:16 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| Could we possibly use a system thats a mix of how GLSA's and GLEP's
| are handled currently?

Sure, if that makes sense from an infra perspective.

| Perhaps we could do the same for the news item where they actually
| reside in the documentation module and the 'plain text' versions of
| the files get copied into the tree at regen time. Correct me if I'm
| wrong, but I think GLEPs are currently created as RST files then you
| use a converter script to make it in guidexml.

There is no published official RST to guidexml conversion tool that
anyone is prepared to admit to having written at this stage.

Also, you'd need to prod the docs guys to remove some of the annoying
chapter / section restrictions if you want to use guidexml as a
generated format for news items. It's hard enough mapping GLEPs onto
that...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Danny van Dyk]

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

Xavier Neys schrieb:
| Discarding XML for the reasons some are using is like recommending
| key=value flat .ini files because windows used it in the 80s.
| They have to be parsed as well, and, as opposed to XML, you have to
| check for unknown keys, double keys, missing ones, then you need some
| grouping and you introduce [sections], which you have to check as well,
| no doubles, no missing ones, no illegal ones, then you need a deeper
| hierarchy and you use key=/path/to/another/file.ini...
He suggested using a RFC822 style Header. Please stick to the facts...

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

iD8DBQFDa6+TaVNL8NrtU6IRAh7fAJ0WL6M0+KTk9uNQzIJxjS1YDVzN+ACdHMvY
OVj8WvjhXuN638d7Zs/Dvo8=
=zt9G
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Lance Albertson]

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

Ciaran McCreesh wrote:
> On Fri, 04 Nov 2005 08:37:16 -0600 Lance Albertson
> <ramereth@gentoo.org> wrote:
> | Could we possibly use a system thats a mix of how GLSA's and GLEP's
> | are handled currently?
> 
> Sure, if that makes sense from an infra perspective.

Yes, I would prefer a standardish way to distribute these types of
things. GLSA's seem to work fine, but they are XML only currently and I
don't think this GLEP is heading that way. If we can nail down the
standards for local vs. remote (www) it should work fine from the infra
side.

> | Perhaps we could do the same for the news item where they actually
> | reside in the documentation module and the 'plain text' versions of
> | the files get copied into the tree at regen time. Correct me if I'm
> | wrong, but I think GLEPs are currently created as RST files then you
> | use a converter script to make it in guidexml.
> 
> There is no published official RST to guidexml conversion tool that
> anyone is prepared to admit to having written at this stage.
> 
> Also, you'd need to prod the docs guys to remove some of the annoying
> chapter / section restrictions if you want to use guidexml as a
> generated format for news items. It's hard enough mapping GLEPs onto
> that...

Yeah, I wondered about that too. I think the jist of this whole thread
is the www presentation level of it would most likely end up as guidexml
(unless there's a good reason to use something totally different). The
mean reason I say that is because I'm guessing most of the detailed
information will reside on the actual www nodes under the GDP which at
this time I'd like to keep in xml form. (And i'm only talking about the
presentation layer, not what you'll see in the tree).

If however, we think its better to have a totally separate vhost like
errata, we can be more flexible on the format we use to display. All I'm
after from an infra POV is something simple for us to manage and scale.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Ciaran McCreesh]

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

On Fri, 04 Nov 2005 13:12:17 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| If however, we think its better to have a totally separate vhost like
| errata, we can be more flexible on the format we use to display. All
| I'm after from an infra POV is something simple for us to manage and
| scale.

As it stands, it's a trivially simple documentation format that can
easily be converted to any other sufficiently general markup format, so
long as said markup format doesn't impose any requirements for things
like heading structures. Would you like three lines of bash to convert
news items into a PDF? :)

There's nothing in this GLEP that precludes using the news files in
other locations. Being able to do so is even listed in the requirements
part. It wouldn't surprise me if someone just happened to come up with,
say, a forums auto-poster or a Gentoo news XML auto-conversion tool...
If there's anything in the GLEP that makes doing so harder than should
be necessary, please let me know because I'd consider that to be a
problem needing attention...

-- 
Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Friday 04 of November 2005 19:39 Ciaran McCreesh wrote:
> On Fri, 04 Nov 2005 15:26:28 +0100 Xavier Neys <neysx@gentoo.org> wrote:
> | > Oh? Our GuideXML to HTML conversion is thousands of lines of code...
> |
> | Plain wrong, but you have always made it clear that you are not only
> | biased against XML for anything, but also very much XML challenged.
>
> Run a wc -l on guide.xsl sometime. Either wc is lying or that alone is
> thousands of lines of code.

Run a `less` or `gvim` or anything which actually displays the contents of the 
file. Are you sure that checking for obsoleted translations, highlighting 
top-page links and other stuff is really required for simple transformations?

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Dan Meltzer]

For simple translations? No.

For translations that span the same bredth (old version checking is
probably going to be fairly needed if we used xml as a main version,
and all other pretifying stuff is necessary.

On 11/4/05, Jan Kundrát <jkt@gentoo.org> wrote:
> On Friday 04 of November 2005 19:39 Ciaran McCreesh wrote:
> > On Fri, 04 Nov 2005 15:26:28 +0100 Xavier Neys <neysx@gentoo.org> wrote:
> > | > Oh? Our GuideXML to HTML conversion is thousands of lines of code...
> > |
> > | Plain wrong, but you have always made it clear that you are not only
> > | biased against XML for anything, but also very much XML challenged.
> >
> > Run a wc -l on guide.xsl sometime. Either wc is lying or that alone is
> > thousands of lines of code.
>
> Run a `less` or `gvim` or anything which actually displays the contents of the
> file. Are you sure that checking for obsoleted translations, highlighting
> top-page links and other stuff is really required for simple transformations?
>
> WKR,
> -jkt
>
> --
> cd /local/pub && more beer > /dev/mouth
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Friday 04 of November 2005 03:30 Luis F. Araujo wrote:
> The point is not about havig access to a web browser, but to have it
> installed in the respective box reading news.

Nope, I'd substitute "in the respective box" with "on the box that you're 
doing administrative tasks from". I rarely use physical console of a server.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Friday 04 of November 2005 02:50 Lance Albertson wrote:
> After reading through the heated thread, I have yet to see your valid
> point of pushing xml for such a simple task. All I have seen is two 3rd
> grade kids arguing over a swing set. Please give some calm reasons for
> your opinion instead of voicing things in such a heated manner. Making
> assumptions about someone else's opinions gets you no where.

Well, my point is that our GLSAs and the associated code already handles stuff 
very similar to the `emerge --news` idea, namely:

a) displaying info only for users having affected package
b) support for arch-specific issues
c) version-specific messages
d) instructions on how to make a workaround and how to fix the problem 
permanently

So the code is here, as well as existing procedures to make new announcements, 
to list them on the website, forums etc.

The only disadvantage I'm aware of is that Portage would have to include XML 
parser, but as Brian said, most of Portage installations already do (sorry, 
I'm not familiar neither with stages nor with Portage, feel free to correct 
me).

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Jan Kundrát]

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

On Friday 04 of November 2005 19:48 Ciaran McCreesh wrote:
> Also, you'd need to prod the docs guys to remove some of the annoying
> chapter / section restrictions if you want to use guidexml as a
> generated format for news items. It's hard enough mapping GLEPs onto
> that...

https://bugs.gentoo.org/ please. It's quite hard to track list of wanted 
GuideXML improvements on several places.

TIA,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Xavier Neys]

Danny van Dyk wrote:
> Xavier Neys schrieb:
> | Discarding XML for the reasons some are using is like recommending
> | key=value flat .ini files because windows used it in the 80s.
> | They have to be parsed as well, and, as opposed to XML, you have to
> | check for unknown keys, double keys, missing ones, then you need some
> | grouping and you introduce [sections], which you have to check as well,
> | no doubles, no missing ones, no illegal ones, then you need a deeper
> | hierarchy and you use key=/path/to/another/file.ini...
> He suggested using a RFC822 style Header. Please stick to the facts...

Had you read that bit properly, you would have noticed I was quoting someone else.
Had you read the post to the end, you would have realised I understand that 
and that I even support it.

-- 
/  Xavier Neys
\_ Gentoo Documentation Project
/  French & Internationalisation Lead
\  http://www.gentoo.org/doc/en
/\
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Xavier Neys]

Ciaran McCreesh wrote:
> On Fri, 04 Nov 2005 15:26:28 +0100 Xavier Neys <neysx@gentoo.org> wrote:
> | > Oh? Our GuideXML to HTML conversion is thousands of lines of code...
> | 
> | Plain wrong, but you have always made it clear that you are not only
> | biased against XML for anything, but also very much XML challenged.
> 
> Run a wc -l on guide.xsl sometime. Either wc is lying or that alone is
> thousands of lines of code.

You know how to count. Well done.
You still haven't got a fscking clue what you're counting, though.
BTW, 1525 is not thousands.

Remove all the html that surrounds the content, i.e. the top bar with logo and 
menu, the left col with the menu and old news items, the right col with the 
ads and you're left with less than a thousand lines. Then remove the blank 
lines, comments and a bit of what I believe is dead wood but I know has 
nothing to do with GuideXML, and what's left already does a lot more than 
GuideXML to HTML transformation.

> | Don't worry, some are even worse than you are, worse enough to claim
> | that XML is hard to parse because "XML files from a programming
> | perspective require extra logic to parse. Compare the following key
> | value pair and xml tag pseudo parsing logic for configuration:
> | <tag1>entry</tag1>
> | Hit a >, tag1 as realized tag name, read until <, read ahead one to
> | ensure a closing slash, read until > to get the tag name, compare tag
> | name with previous tag name to see what tag it's closing. store value
> | attached to tag1."
> 
> That is not parsing XML. That is parsing some arbitrary markup language
> you just invented. Please read the XML specification, note how complex
> some of the little used side features are, and then remember that a
> compliant XML parser has to implement **all** of them.

I did not invent that, I was quoting another dev. FYI, the quote is the bit 
between the " characters.


-- 
/  Xavier Neys
\_ Gentoo Documentation Project
/  French & Internationalisation Lead
\  http://www.gentoo.org/doc/en
/\
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Danny van Dyk]

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

Xavier Neys schrieb:
| Danny van Dyk wrote:
|
|> Xavier Neys schrieb:
|> | Discarding XML for the reasons some are using is like recommending
|> | key=value flat .ini files because windows used it in the 80s.
|> | They have to be parsed as well, and, as opposed to XML, you have to
|> | check for unknown keys, double keys, missing ones, then you need some
|> | grouping and you introduce [sections], which you have to check as well,
|> | no doubles, no missing ones, no illegal ones, then you need a deeper
|> | hierarchy and you use key=/path/to/another/file.ini...
|> He suggested using a RFC822 style Header. Please stick to the facts...

| Had you read that bit properly, you would have noticed I was quoting
| someone else.
| Had you read the post to the end, you would have realised I understand
| that and that I even support it.

I did read your post to the end. Still, adding things like the above
quoted INI-File talk has nothing to do with this discussions. Therefore
my demand to 'stick to the facts'.

As to the quoting: Please mark quotes as such. There maybe people who
can memorize this whole thread and recognize unmarked quotes... i can't...

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

iD8DBQFDbAs9aVNL8NrtU6IRAmjKAKCNfYNw7SBbPttEK5ROy7PUgvWkGgCeM+ch
y/e6M4sYUp2/o3aZjBRREyI=
=pN17
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP ??: Critical News Reporting

[R Hill]

Nathan L. Adams wrote:
> Just keep in mind that portage is supposed to be non-interactive and
> most users like it that way. (Although the countdown when cleaning out
> old packages kinda breaks that idea, but I digress.)

This must be some definition of the word interactive i'm not aware of. 
;)  Displaying something on the screen for a user to read is not 
interaction.

> So just make sure that the scheme doesn't involve forcing the user to
> notice anything during a 'normal' non-interactive emerge in order for it
> to be effective. Thats why I keep pushing having a nice GuideXML version
> in a central location like http://errata.g.o/ and just having emerge
> output a summary and a link (however/at what point/with what mechanism
> you decide to actually have portage output it).

Forcing the user to see it is exactly the point.  There are already many 
sources for news that the user can go to.  We don't need another.

And while the idea of having portage give the user a summary and link is 
a step in the right direction, it'd be even nicer if the message itself 
was available without an internet connection (ie. kept in the tree).

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Marius Mauch]

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

On Fri, 4 Nov 2005 22:50:42 +0100
Jan Kundrát <jkt@gentoo.org> wrote:

> On Friday 04 of November 2005 02:50 Lance Albertson wrote:
> > After reading through the heated thread, I have yet to see your
> > valid point of pushing xml for such a simple task. All I have seen
> > is two 3rd grade kids arguing over a swing set. Please give some
> > calm reasons for your opinion instead of voicing things in such a
> > heated manner. Making assumptions about someone else's opinions
> > gets you no where.
> 
> Well, my point is that our GLSAs and the associated code already
> handles stuff very similar to the `emerge --news` idea, namely:
> 
> a) displaying info only for users having affected package
> b) support for arch-specific issues
> c) version-specific messages
> d) instructions on how to make a workaround and how to fix the
> problem permanently

All of these steps are more or less trivial, there is little to no gain
in reusing glsa related code. Moving the relevant code from glsa.py to
some other location would be more work that rewriting these parts.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Paul de Vrieze]

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

On Friday 04 November 2005 16:55, Nathan L. Adams wrote:
> Paul de Vrieze wrote:
> > On Friday 04 November 2005 14:38, Nathan L. Adams wrote:
> >>Paul de Vrieze wrote:
> >>>What is worse is that some
> >>>users might not update for a prolongued time (6 months). At that
> >>> time they will not find the information in the erata list anymore.
> >>> But they will get the RELEVANT news delivered by emerge/enews.
> >>
> >>Why would a "SomeSQL 1.0 to 1.1" guide ever need to dissappear?
> >> Surely errata.g.o would have archiving/searching. But I do see your
> >> point about emerge filtering out the unwanted stuff.
> >
> > It would be hidden in the forrest. Even if I did a search on SomeSQL,
> > it might return a number of news items on SomeSQL. That is besides
> > the fact that I have 737 packages installed. I'm not going to search
> > news on all of them. Archiving would of course be provided, but
> > searching is not usefull for updating.
>
> You update all 737 packages with each emerge? I don't see any validity
> in your point; a nice http://errata.g.o/ site with archived guides and
> search wouldn't preclude 'emerge --news' in any way.

No, not all 737, but when I update one of my machines that I didn't update 
in those 6 months (perhaps except security updates), I'm going to have to 
remerge the majority of them. There might be quite some trivial updates 
in those, but I wouldn't be able to find out before I update.

Paul

ps. Even if it were 50 updates (which happens often enough for me), it 
would be too much to search info for all of them.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] GLEP ??: Critical News Reporting

[Luca Barbato]

Nathan L. Adams wrote:
> 
> So you're saying that Gentoo consists of projects that are completely
> 'silo'd up' and have no bearing whatsoever on each other. Then the
> DevRel project only has bearing on those who actually join DevRel. Neat,
> a group formed for the sole purpose of coordinating itself. Security
> need only concern itself with securing its members (from who knows
> what!), and infra can just ignore the needs of everyone else (different
> project!). I wonder how any of the other projects *ever* made it onto
> the website...

Sigh, every project can set up it's own rules for internal project 
tasks, that means that internal docs could be a set of nice ascii art 
and then, you have a nice GuideXML page to point to them than happens to 
be translated on html/pdf/plaintext/whatever upon the necessities.


> 
> The errata.g.o (not the summaries w/ link that emerge would output)
> would obviously be documentation, would obviously be governed by the Doc
> rules, and it would be irrelevant which staff member happened to publish
> a particular guide. If Gentoo really is as balkanized as you state, then
> it is a sad state of affairs indeed. Maybe the 'full fledged' versions
> should be GuideXML-lite or something, I'm not sure, but your argument is
> just silly.

ARGH looks like MANY people do not get what is good about xml and what 
is not so good.

The whole point of using GuideXML is to make EASY convert to something 
else. NOT to use it.

The problem of using xml everywhere is that it is harder to write and 
has some work required in order to be parsed and translated.

So, if I have to set up an infrastructure that would require me to 
generate pdf, webpages, text, younameitwegetit and to update/write it 
not so often and not so quickly, I'd use xml.

If there is something that I'd have to write often by hand and quickly 
and has to be used as is mostly. I'd stay with a simpler format (that 
maybe is still machine parsable).

That said the format Ciaranm suggests for news looks ok for me. XML 
won't add anything but slowing me.

For an errata site GuideXML or an _extended_ version of it could be useful.

lu

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDa5WH2QTTR4CNEQARAlERAKCeVue4ATD4fXBgLGdRAWt4Gi7vWgCcCs7R
> w/Pvjk9vv2C00HmrTkhBnHU=
> =Eiba
> -----END PGP SIGNATURE-----


-- 

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 ??: Critical News Reporting

[Stuart Herbert]

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

Hi Nathan,

On Thu, 2005-11-03 at 20:36 -0500, Nathan L. Adams wrote:
> So you installed your server without reading *any* documenation? (Don't
> lie). And you expect that the average user installs a Gentoo server
> without at least referencing the documentation? Pa-leaze.

I've been following your posts in this thread.  I'm not finding your
contribution to be very helpful to what we're trying to achieve here.
What are *you* trying to achieve, other than making yourself look like
an idiot?

Or, to put it another way ...

Stop being a muppet.  If Ciaran needed to refer to the documentation
(which I very much doubt), he could read the text-only version included
on the install media, or he could use a browser on another machine to
access it.

Please start taking a moment to *think* before putting your foot into
your mouth.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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