[gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

Attached is a substantially reworked draft. I've restructured the whole
thing, fleshed it out in places, clarified some parts and incorporated
the useful stuff from previous discussions.

Note: this is now GLEP 42 as allocated by Grant. AFAIK ChrisWhite's GLEP
of the same number never made it to official status.

Feedback from people who have something useful to say would be very much
welcomed, assuming of course that they've read the GLEP.

If you're going to rant on about XML or anything that assumes we have a
static release Debian-style against which we somehow make
'corrections', you'll be ignored unless you come up with a very good
justification based upon requirements and implementation rather than
hand waving and incoherent rants. If you don't like it, you're welcome
to write a competing GLEP.

To give those who like arguing endlessly something else to go on about,
the eselect news module is now upgraded to the 'suggested' tool for
displaying news items. Look! I'm sneakily and evilly pushing a sekrit
agenda here! Also, I murdered three puppies last night.

Grant, please commit this to CVS. I'm too scared of docutils to do it
myself.

-- 
Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

GLEP: 42
Title: Critical News Reporting
Version: $Revision: $
Author: Ciaran McCreesh <ciaranm@gentoo.org>
Last-Modified: $Date: $
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 31-October-2005
Post-Date: 1-November-2005, 5-November-2005

Abstract
========

This GLEP proposes a new way of informing users about 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
* RSS feeds of Gentoo news

A more reliable way of getting news of critical updates out to users is required
to avoid repeats of the various recent upgrade debacles. This GLEP proposes a
solution based around pushing news items out to the user via the ``rsync`` tree.

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

An adequate solution must meet all of the following requirements:

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

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.

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

Lightweight
    It is not reasonable to expect all users to have an MTA, web browser, email
    client, cron daemon or text processing suite available on their system.

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

Multiple delivery method support
    Some users may wish to view news items via email, some via a terminal and
    some via a web browser. A solution should either support all of these
    methods or (better still) make it trivial to write clients for displaying
    news items in different ways.

The following characteristics would be desirable:

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

Quality control
    There should be some way to ensure that badly written or irrelevant messages
    are not sent out, for example by inexperienced developers, 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 and future news sources
    A news system would ideally be able to be integrated with existing news
    sources (for example, Forums, GWN, the main Gentoo website) without
    excessive difficulty. Similarly, easy interoperation with any future news
    sources should not be precluded.

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

Overview
--------

News items are published and delivered to users as follows:

1. A news item is written. The format to be used is described in
   `News Item File Format`_.
2. The news item is reviewed, following the process described in
   `News Item Quality Control`_.
3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository.
   From here, it is merged with the rsync tree. This is described in `News Item
   Distribution`_.
4. The news item is merged with the rsync tree. Implementation details of this
   point are beyond the scope of this GLEP; existing solutions are in place
   for merging GLSAs to the tree.
5. Users fetch the news item when they sync. This ensures that the news items in
   question are pushed to the user before the user accidentally makes an
   unwanted change. No changes to the existing rsync process are required by
   this GLEP.
6. Portage filters the news item and, if it is relevant, installs it in a
   special location to be read by a news item reader. Messages are also
   displayed to inform the user that news is available.
7. The news item is handled by the user's choice of news item reader. See `News
   Item Clients`_.

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

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 short name
must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-`` (hyphen).

News items may be signed using GPG. If this is done, a detached signature should
be used.

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

A news item's content 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 ignore any unrecognised header.

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

The following headers describe the purpose and format of the news item:

``Title:``
    A short (maximum 44 characters) descriptive title. Mandatory.
``Author:``
    Author's name and email address, in the form ``Real Name <email@address>``.
    Mandatory, multiple author 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). UTC time in
    ``hh-mm-ss +0000`` format may also be included. This field is 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-Format:``
    Must be ``1.0``. Future revisions to the format may increment the minor
    number for backwards-compatible changes, or the major number for major
    changes.

The following headers are used for filtering. If none of these headers are
specified, the news item is displayed for all users. Otherwise, the news item is
displayed if *at least one* header 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.

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

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.

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

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

The following hypothetical news item could be used for an upgrade to the
``YourSQL`` database format which breaks forward compatibility. It should be
named ``2005-11/2005-11-01-yoursql-upgrades.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.

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

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

Thus, 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. The importance of the message to its
intended audience should be justified with the proposal.

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

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

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

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

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

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

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

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

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

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

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

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.

The unread news message will also be displayed immediately after an
``emerge sync``.

Portage may also warn of unread news items using, for example, a red flashy
before actions such as merging a package.

Portage must keep track of news items which have already been installed to avoid
repeatedly reinstalling a deleted news item.

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

News Item Clients
-----------------

Once a news item is 'installed', third party tools (or a traditional Unix pager
and ``rm``) can be used to display and view the news files. An ``eselect``
[#eselect]_ module shall be created as the 'suggested' display tool; other
display tools (for example, a news to email forwarder, which would be ideal for
users who sync on a cron) are left as options for those who desire them -- the
simple file format make this relatively simple.

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

News items can be removed (by removing the news file from the main tree) when
they are no longer relevant, if they are made obsolete by a future news item or
after a long period of time. This is the same as the method used for ``updates``
entries.

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

It would be 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 [#forums-glsa]_ for posting GLSAs to the
forums. A similar tool can be used for these news items.

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

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

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

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

TODO

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

A demonstration ``eselect`` news display script follows:

::

    # Copyright 1999-2005 Gentoo Foundation
    # Distributed under the terms of the GNU General Public License v2
    # $Id: $

    DESCRIPTION="Read important Gentoo news items"
    MAINTAINER="ciaranm@gentoo.org"
    SVN_DATE='$Date: $'
    VERSION=$(svn_date_to_version "${SVN_DATE}" )

    get_news_item_list() {
        [[ -d "${ROOT}/var/lib/gentoo/news" ]] || return
        (
           local news
           for news in "${ROOT}/var/lib/gentoo/news/"*.txt ; do
               echo $(basename ${news%%.*} )
           done
        ) | sort -u
    }

    get_filename() {
        local best_lang=${LANG%%_*} lang= filename="${1}"
        [[ -e "/${filename}" ]] || for lang in "${best_lang}" "en" ; do
            filename="${ROOT}/var/lib/gentoo/news/${1}.${lang}.txt"
            [[ -e "${filename}" ]] && break
        done
        [[ -e "${filename}" ]] && echo "${filename}" || die -q "Can't find '${1}'"
    }

    get_all_filenames() {
        if [[ -z "${1}" ]] ; then
            echo "${ROOT}/var/lib/gentoo/news/"*.??".txt"
        else
            echo "${ROOT}/var/lib/gentoo/news/${1}."??".txt"
        fi
    }

    get_headers() {
        sed -e '/^$/Q' < $(get_filename "${1}" )
    }

    get_body() {
        sed -e '1,/^$/d' < $(get_filename "${1}" )
    }

    get_title() {
        get_headers "${1}" | sed -n -e '/^[Tt]itle: /s/^[^:]\+:[ \t]*//p'
    }

    ### list action

    ## {{{ list stuff
    describe_list() {
        echo "List available news items"
    }

    do_list() {
        write_list_start "Available news items:"
        local empty=yes n=1
        for news in $(get_news_item_list ) ; do
            write_numbered_list_entry ${n} "$(highlight $(get_title ${news} ) ) (${news})"
            n=$(( n + 1 ))
        done
    }
    ## }}}

    ## {{{ show stuff
    describe_show(){
        echo "Show a news item"
    }

    do_show() {
        [[ -z "${1}" ]] && die -q "You didn't tell me which news item to read"

        local target=${1} filename=
        if is_number "${target}" && [[ ${target} -ge 1 ]] ; then
            targets=( $(get_news_item_list ) )
            target=${targets[$(( ${target} - 1 ))]}
        fi

        (
            get_headers "${target}" | grep -v '^Display-If-\|Content-Type:'
            echo
            get_body "${target}"
        ) | ${PAGER:-cat}
    }
    ## }}}

    # {{{ delete stuff
    describe_delete() {
        echo "Delete a news item"
    }

    do_delete() {
        [[ -z "${1}" ]] && die -q "You didn't tell me which news item to delete"

        for target in $@ ; do
            if is_number "${target}" && [[ ${target} -ge 1 ]] ; then
                targets=( $(get_news_item_list ) )
                target=${targets[$(( ${target} - 1 ))]}
            fi

            rm $(get_all_filenames "${target}" ) || die -q "Couldn't delete ${target}"
        done
    }
    # }}}

    # {{{ delete-all
    describe_delete-all() {
        echo "Delete all news items"
    }

    do_delete-all() {
        rm $(get_all_filenames ) || die -q "Couldn't delete news items"
    }
    # }}}

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

A demonstration shell script which delivers news items via email follows:

::

    #!/bin/bash

    to_address="root@localhost"
    mail="mailx"
    best_lang="${LANG%%_*}"

    for news in /var/lib/gentoo/news/*.*.txt ; do
        [[ -z "${best_lang}" ]] || news="${news%%.*}.${best_lang}.txt"
        [[ -f "${news}" ]] || news="${news%%.*}.en.txt"
        [[ -f "${news}" ]] || continue
        title=$(sed -n -e '/^Title:/ { s,^[^:]\+:[ \t]\+,,p ; q }' < ${news} )
        sed -e '1,/^$/ { /^Display-If\|Content-Type/d }' < "${news}" | \
            ${mail} -s "Gentoo news: ${title}" "${to_address}" && \
            for file in ${news%%.*}.*.txt ; do rm "${file}" ; done
    done

Credits
=======

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

Thanks to Lance Albertson, Donnie Berkholz, Grant Goodyear, Brian Harring, Dan
Meltzer, Paul de Vrieze and Alec Warner for input.  Some of the ideas presented
here are theirs, others go completely against their suggestions.

References
==========

.. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al.,
     http://www.gentoo.org/doc/en/xml-guide.xml
.. [#eselect] eselect modular framework for configuration and
     administration utilities,
     http://www.gentoo.org/proj/en/eselect/index.xml
.. [#forums-glsa] Forums user GLSA,
     http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648
.. [#forums-whining] Forums thread "Gentoo Apache2 Config Change Idiocy",
     http://forums.gentoo.org/viewtopic-t-384368.html
.. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
     userlands/kernels/archs", Grant Goodyear,
     http://www.gentoo.org/proj/en/glep/glep-0022.html
.. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
     McCreesh,
     http://www.gentoo.org/proj/en/glep/glep-0031.html
.. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
     http://www.gentoo.org/proj/en/glep/glep-0034.html
.. [#glep-36] GLEP 36: "Subversion/CVS for Gentoo Hosted Projects", Aaron
     Walker,
     http://www.gentoo.org/proj/en/glep/glep-0036.html
.. [#iso-639] ISO 639 "Code for the representation of names of languages"
.. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
     Albertson,
     http://marc.theaimsgroup.com/?l=gentoo-dev&m=113111585907703&w=2
.. [#rfc-822] RFC 822 "Standard for the format of ARPA Internet text messages"
.. [#stuart-blog] "Favouring an automatic news mechanism", Stuart Herbert,
     http://stu.gnqs.org/diary/gentoo.php/2005/10/28/favouring_an_automatic_news_mechanism

Copyright
=========

This document has been placed in the public domain.

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

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stephen Bennett]

On Sat, 5 Nov 2005 00:58:14 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> Feedback from people who have something useful to say would be very
> much welcomed, assuming of course that they've read the GLEP.

I think you might be missing a 'not' from the first Requirements
section. Unless you're secretly pushing an evil agenda to make everyone
use Debian by breaking everyone's Gentoo systems, that is.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Dan Meltzer]

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

Why have this header at all then?

>   ``Posted:``
>   Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). UTC time in
>   ``hh-mm-ss +0000`` format may also be included. This field is mandatory.
How will prescendse be handled if two have the same date, and one has
a time and the other doesn't?

On 11/4/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> Attached is a substantially reworked draft. I've restructured the whole
> thing, fleshed it out in places, clarified some parts and incorporated
> the useful stuff from previous discussions.
>
> Note: this is now GLEP 42 as allocated by Grant. AFAIK ChrisWhite's GLEP
> of the same number never made it to official status.
>
> Feedback from people who have something useful to say would be very much
> welcomed, assuming of course that they've read the GLEP.
>
> If you're going to rant on about XML or anything that assumes we have a
> static release Debian-style against which we somehow make
> 'corrections', you'll be ignored unless you come up with a very good
> justification based upon requirements and implementation rather than
> hand waving and incoherent rants. If you don't like it, you're welcome
> to write a competing GLEP.
>
> To give those who like arguing endlessly something else to go on about,
> the eselect news module is now upgraded to the 'suggested' tool for
> displaying news items. Look! I'm sneakily and evilly pushing a sekrit
> agenda here! Also, I murdered three puppies last night.
>
> Grant, please commit this to CVS. I'm too scared of docutils to do it
> myself.
>
> --
> Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy)
> Mail            : ciaranm at gentoo.org
> Web             : http://dev.gentoo.org/~ciaranm
>
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Fri, 4 Nov 2005 20:44:13 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| >``Content-Type:``
| >   Must be ``text/plain``. Mandatory.
| 
| Why have this header at all then?

Forwards compatibility.

| >   ``Posted:``
| >   Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
| > UTC time in ``hh-mm-ss +0000`` format may also be included. This
| > field is mandatory.
| How will prescendse be handled if two have the same date, and one has
| a time and the other doesn't?

Every existing client just sorts by filename... Multiple news items in
a day which require specific ordering is not exactly likely...

-- 
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 42 "Critical News Reporting" Round Two

[Grobian]

Ciaran McCreesh wrote:
> Motivation
> ==========
> 
> There are currently several ways of getting news out to our users, none of them
> particularly effective:

This assumes the following ways are really ineffective, something which 
you don't prove or give any reason for.  Hence it's eligable for another 
big discussion.  To avoid that, I would suggest to add a number of 
reasons, or whatever to make this assumption sound (more) valid.  It is 
important, I think, that the reader can understand your grounds for 
saying this.
(I personally disagree on this statement now, but it makes no use 
discussing it since you haven't given any ground as on why.  Maybe if 
you would give a definition, I could adjust my own definition and agree.)

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

Perhaps you want to add a small footnote here, to give a small example 
of such debacle, and using that example point out what is the problem 
you think is important, and hence will address in this paper... eh GLEP.

> This GLEP proposes a
> solution based around pushing news items out to the user via the ``rsync`` tree.

This is a minor side issue, but I think that GLEP 2 states that you 
should use ' instead of `.  No discussion on it please, I might be wrong 
or you just didn't know.

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

style suggestion for unambigous interpretation:
perhaps a "because if applied afterwards" instead of "after"

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

You implicitly state that many users do not read the gentoo-announce 
list and RSS-feeds because they are subscription based.  This sounds 
like a too quick assumption to me.  At least it is not founded in any 
way.  Consider that for RSS-feeds one typically doesn't have to 
subscribe, but just add it to his/her reader.  Make clear why you think 
the subscription model stops users from reading, and why a push-based 
alternative (as you suggest here) will work.  Remember that it is easy 
to say here that users don't read what's on their consoles as well, as 
in post emerge messages etc.  So make sure you deal with it upfront, why 
you think now it *will* work.

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

Apart from that this point seems to repeat much of the previous one, it 
introduces a new unfounded claim (users do read, but now too late) which 
somehow contradicts previous statements.  Beware that you clearly deal 
with this, or just introduce it earlier so it doesn't look you're 
contradicting yourself.

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

Direct question that follows from this: what *do* we expect a 
user/system to have available?  I think it's good to state that as well, 
since you're excluding a lot here in once sentence.

> 3. The news item is committed to a CVS (or Subversion [#glep-36]_) repository.
>    From here, it is merged with the rsync tree. This is described in `News Item
>    Distribution`_.
> 4. The news item is merged with the rsync tree. Implementation details of this
>    point are beyond the scope of this GLEP; existing solutions are in place
>    for merging GLSAs to the tree.

Where does point 4 differ from the second part of point 3?  Also, point 
3 implies that the merging into the rsync tree is being described 
further on, while point 4 states the oposite of not discussing it (out 
of scope).  Maybe split point 3 and merge with 4?

> 5. Users fetch the news item when they sync. This ensures that the news items in
>    question are pushed to the user before the user accidentally makes an
>    unwanted change. No changes to the existing rsync process are required by
>    this GLEP.

I would suggest a reference to a place where you will explain this 
'pushing' to the user in detail.  Especially the time and the way how 
are important.  Or maybe I was just confused by "pushed" and is the only 
thing this point wants to say that all news items are just synced 
together with the rest of the portage tree upon a emerge --sync.  The 
latter sounds logical considering the last sentence quoted above.

> 6. Portage filters the news item and, if it is relevant, installs it in a
>    special location to be read by a news item reader. Messages are also
>    displayed to inform the user that news is available.

So, same as for point 5, the exact details on how this works and what a 
'news item reader' is (since you previously defined a requirement of 
having almost nothing available on the system) should be refered to 
here.  I want to be sure that you will elaborate on it lateron, so I can 
stack up my many questions for now.

> 7. The news item is handled by the user's choice of news item reader. See `News
>    Item Clients`_.

Wow.  Seems like point 6 mentioned 'news item reader' too early!  Same 
for point 5 of mentioning "pushing" which is only dealt with in point 6. 
  In any case, the reference is there: good.

> 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 short name
> must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-`` (hyphen).

Consider replacing hyphen with an underscore to ease parsing.

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

This might sound a bit 'attacking'.  Try to rephrase it a bit to sound 
more formal.  Also, note that probably noone cares about it and takes it 
for granted.  You included support for other languages, so there's 
nothing to make a sharp point on here, I guess.
(Maybe: "An English (''en'') version must be available for all news 
items as per GLEP 34 [#glep-34]_.  Other languages ...")

> A news item's content 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 ignore any unrecognised header.

Ah, a clear sight on the future.  Good!  (Also from the perspective of 
the paper.)

> ``Author:``
>     Author's name and email address, in the form ``Real Name <email@address>``.
>     Mandatory, multiple author fields may be specified if appropriate.

Separated how?  Using commas, semicolons, spaces or whatever?

> ``Posted:``
>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). UTC time in
>     ``hh-mm-ss +0000`` format may also be included. This field is mandatory.

Consider stressing the requirement for UTC time by stating it in a 
separate sentence.

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

Perhaps you want to track trivial changes as well in the minor, in order 
to be able to quickly see a change was made, and prevent people from 
considering a non-trivial change as trivial.  Maybe you should 
explicitly state this field is optional and why.  I could think of some 
reasons why this header should be mandatory, but perhaps you add a 
completely different value to the header than I do now.

> The following headers are used for filtering. If none of these headers are
> specified, the news item is displayed for all users. Otherwise, the news item is
> displayed if *at least one* header matches.

 From a completeness perspective, it would perhaps be a option to 
include a special header that contains a boolean expression that 
resolves to true if the message is relevant to the user, and false 
otherwise.  This would allow AND and NOT to be included instead of only 
OR semantics.
In any case, elaborate on why supporting only OR was chosen and why 
other (probably investigated) options were discarded (and hence make my 
statement above unnecessary).

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

Elaborate some more on "No fancy formatting or tab characters".  People 
might want/like to include a bulleted/numbered list or insert a small 
(shell) code example.  Also make some note on the average length (number 
of paragraphs) and perhaps a predefined structure (ie.: 
introduction/abstract, impact, solutions/actions, links/more-information)

>     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

Note that this indenting of the URL can be considered 'fancy 
formatting'.  Hence there is a clear need to define the term.

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

Consider including a new paragraph in the example just to show your 
proposed structure.

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

The idea is great, but perhaps the current docs teams should deal with 
this, as they are currently responsible for the webpages as well?
In any case:
- 72 hours is a lot (is there a way to shorten it when everything is
   there?)
- consider using either -dev or -core not both in an "OR" relation,
   clarity if good for everyone.
- what if noone feels like commenting on the submission?
- how do you know a certain dev is a competent English speaker?
- when do you know that it has been read, approved?
This raises many questions.  I suggest to define the process a bit more 
and include a scheme that deals with this kind of concerns to actually 
make it water (and fool) proof.

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

Somehow there needs to be a voting/selection process to figure out 
whether something is **important** or not.  Be aware that there are bugs 
that indicate that users would like to see all einfo messages being 
delivered to them in some way.  It might be confusing to the user what 
is the difference (and for me as well... when is something considered 
important?).  Try to define what you think is important, or maybe give 
some well explanatory examples and what the advantage is over einfo.  To 
comment on your YourSQL example: perhaps YourSQL just gives an error 
about an incompatible database when starting it, and points itself to a 
migration site.  One could consider for this reason a message on it not 
important, as nothing gets unrepairable broken.  Linking back to your 
'preemptive' requirement: define damage and broken.

> The unread news message will also be displayed immediately after an
> ``emerge sync``.

Include a note on configurability, i.e. disabling such behaviour for 
users that don't like it.  Elaborating on other ways to inform the 
administrator (ie. via email) would be great too.  Consider automated 
installs, end-user/desktop installs (basically everything from big to 
small) such that for each situation the information being supplied can 
be pushed to the admin in the way that is desirable (for him/her).

> Portage may also warn of unread news items using, for example, a red flashy
> before actions such as merging a package.
> 
> Portage must keep track of news items which have already been installed to avoid
> repeatedly reinstalling a deleted news item.
> 
> Users who really don't care about news items can use ``rsync_excludes`` to
> filter out the ``news/`` directory.

Does portage only 'warn' and still continue, or does it completely stop 
when an unread news item is found for a package that is to be upgraded? 
  In the first case, the 'preemptive' requirement is being violated, in 
the latter, the option for a '--force' or something must be discussed. 
(Users with multiple systems might already know the message, or users 
might not be interested in it since they don't run the application in 
production.)

A concluding note on this Section is that I have the impression that 
only one use-scenario has been dealt with.  Both this scenario is not 
described, as well as that this scenario doesn't reflect 99.9% of our 
user base.  Many alternative opinions will stem from the fact that 
different people envision different scenarios.  I think that elaborating 
on a number of representative (need not to be most popular) scenarios 
and how the proposed setup functions in there is good to get a grip on 
the many different demands of users.  I could help to define a scenario 
for a larger scale more or less automated/cronned install.

> News Item Clients
> -----------------
> 
> Once a news item is 'installed', third party tools (or a traditional Unix pager
> and ``rm``) can be used to display and view the news files. An ``eselect``
> [#eselect]_ module shall be created as the 'suggested' display tool; other
> display tools (for example, a news to email forwarder, which would be ideal for
> users who sync on a cron) are left as options for those who desire them -- the
> simple file format make this relatively simple.

This Section is too short in this form to live on its own.  It should 
either be extended or merged with text above where I made a comment on 
the details.  Perhaps you can elaborate on how to implement such 
forwarders, especially in the light of my comments on the previous Section.

> News Item Removal
> -----------------
> 
> News items can be removed (by removing the news file from the main tree) when
> they are no longer relevant, if they are made obsolete by a future news item or
> after a long period of time. This is the same as the method used for ``updates``
> entries.

This sounds much alike what 'mail' used to (and still) does.  It has the 
ability to see which messages are waiting, select them to read with a 
pager and delete them.  Make sure you explain why this is better, and 
why you 'seemingly' reinvent the wheel here.  I think I can think of 
some reasons, but I think you need to make it clear.

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

Yes, and make it a requirement that all news messages get posted 
somewhere on public channels.  Some admins really like to see all news 
items, so your GLEP should cover the possibility for that, I think.
Somewhat related to my suggestion for using scenarios, this also implies 
that there will be users that want to turn this off completely, as such 
doing the right rsync_exclude should be documented somewhere.



I hope I have not created a new opportunity for large flame wars.  I 
tried being quite constructive, and reviewed the GLEP as a scientific 
paper.  Given the fact I had a lot to add, indicates for me there are a 
lot of questions to be asked regarding this GLEP.  Many of those 
questions can simply be answered by providing the underlying rationales 
and background information that is not made explicit.  I hope you can do 
something useful with my comments.  If you don't like them, ignore them 
and throw them away.  If you want to use them, feel free to do so.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jan Kundrát]

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

On Saturday 05 of November 2005 11:28 Grobian wrote:
> Remember that it is easy
> to say here that users don't read what's on their consoles as well, as
> in post emerge messages etc.  So make sure you deal with it upfront, why
> you think now it *will* work.

"Emerge messages" are usually hidden by compilation output, so this argument 
doesn't apply here, IMHO. Or am I missing your point here?

> In any case, elaborate on why supporting only OR was chosen and why 
> other (probably investigated) options were discarded (and hence make my 
> statement above unnecessary).

Good point. How is it handled by (<rant>er, XML-based, hehe</rant>) GLSAs?

Cheers,
-jkt

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

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[kloeri]

On Sat, Nov 05, 2005 at 11:28:33AM +0100, Grobian wrote:
> Ciaran McCreesh wrote:
> >Motivation
> >==========
> >
> >There are currently several ways of getting news out to our users, none of 
> >them
> >particularly effective:
> 
> This assumes the following ways are really ineffective, something which 
> you don't prove or give any reason for.  Hence it's eligable for another 
> big discussion.  To avoid that, I would suggest to add a number of 
> reasons, or whatever to make this assumption sound (more) valid.  It is 
> important, I think, that the reader can understand your grounds for 
> saying this.
> (I personally disagree on this statement now, but it makes no use 
> discussing it since you haven't given any ground as on why.  Maybe if 
> you would give a definition, I could adjust my own definition and agree.)
> 
You must not have read the [#forums-whining]_ reference as that makes it
quite clear that existing methods isn't adequate. Even if you think the
apache maintainers made lots of mistakes you can't really fault us for
not trying to get the news of config changes out to all users.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Jan Kundrát wrote:
> On Saturday 05 of November 2005 11:28 Grobian wrote:
>> Remember that it is easy
>> to say here that users don't read what's on their consoles as well, as
>> in post emerge messages etc.  So make sure you deal with it upfront, why
>> you think now it *will* work.
> 
> "Emerge messages" are usually hidden by compilation output, so this argument 
> doesn't apply here, IMHO. Or am I missing your point here?

You give an example here of why console messages aren't read.  But if 
that is your rationale here, I would like to see it stated in the GLEP 
why it *will* work there.  On the previous discussion there was an 
example of a console message not being read fully/properly.  This will 
happen to more people.  What I was asking for is that such situation is 
either outlawed (ie. "People should just read, if they don't then it's 
not my problem") or recognised (ie. "It is known that people do not 
read, hence we propose to use a text-to-speech module and play the 
produced audio file, so the user can listen to the imporant message" -- 
idiotic example of course).

Just to make things clear and properly defined.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Brian Harring]

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

On Sat, Nov 05, 2005 at 12:58:14AM +0000, Ciaran McCreesh wrote:
> 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.
> 
<snip>

> Multiple delivery method support
>     Some users may wish to view news items via email, some via a terminal and
>     some via a web browser. A solution should either support all of these
>     methods or (better still) make it trivial to write clients for displaying
>     news items in different ways.

Drop the lightweight bit and merge it into multiple delivery.  You're 
after lightweight _default_, which is fine, but the phrasing is a bit 
screwed.

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

While it may be fun getting a reaction out of people, nuke the nitro 
laced words please.  Same for the forums_whining ref (there's enough 
contention over the glep already ;)


> News items are published and delivered to users as follows:
<snip>
> 6. Portage filters the news item and, if it is relevant, installs it in a
>    special location to be read by a news item reader. Messages are also
>    displayed to inform the user that news is available.

Out of curiousity, how are you planning on having 101 general notices 
reigned down on a users head during an initial install?  Yes, you have 
the atom filter, but what about general notices?

Further, how are notices going to apply to users who don't have the 
package installed, then go and merge it?  Your statement above implies 
the irrevalent (at the time of sync) notices are ignored, which breaks 
down under the scenario where a news item is pushed out that apache 
configuration is going to change, I merge old style apache after 
sync'ing the news, portage (due to your news id cache) considers it 
deleted, and doesn't display it.


> News Item File Format
> ---------------------
<snip>
> News items may be signed using GPG. If this is done, a detached signature should
> be used.

I'd argue for must be, personally.  A bogus news item claiming to be 
from portage devs, telling users to change their SYNC setting could 
cause massive mayhem.


> The following headers are used for filtering. If none of these headers are
> specified, the news item is displayed for all users. Otherwise, the news item is
> displayed if *at least one* header 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.

Still haven't address my point about
A) package moves combined with news entries
B) N packages

Assume you mean that the bit above is a full DepSet, not a single atom 
(if that's the case, clarify that N atoms are allowed).

Should clarify USE conditionals are a no go- might be worth 
considering the full atom syntax (despite the fact portage doesn't 
currently support it for depends), use flags, slot, etc.

Yes it's more work, but it should be spelled out from where I'm 
sitting.

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

N keywords == N Header entries?

> 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.
> 
> Thus, all proposed news items must be posted to the ``gentoo-dev`` or
> ``gentoo-core`` mailing list

No go on -core imo; it's a community/dev issue, should be visible to 
the general public rather then hidden away in the ml we do our flaming 
in.

> Client Side
> '''''''''''
> 
> Whenever relevant unread news items are found, ``emerge`` will copy or symlink
> the news file into ``/var/lib/gentoo/news/``.

Already pointed out that this won't fly looking forward, it implicitly 
assumes a single repository.

Need to allow for each repo to have their own news, preferably 
seperated directory wise; either that or you're going to have to track 
where a news item came from and mangle the new entry.

> 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.
> 
> The unread news message will also be displayed immediately after an
> ``emerge sync``.
> 
> Portage may also warn of unread news items using, for example, a red flashy
> before actions such as merging a package.

Nuke flashy (any phrasing that allows for blinking crap sliding into portage I 
instinctively dislike).

> Portage must keep track of news items which have already been installed to avoid
> repeatedly reinstalling a deleted news item.

Track it how, via the directory, or a secondary list?
Wording implies portage is going to have to maintain it's own newsid 
list; if that's the case, explicitly state so, and keep it limited to 
per repo (not global as the proposal seems to indicate).

> News Item Removal
> -----------------
> 
> News items can be removed (by removing the news file from the main tree) when
> they are no longer relevant, if they are made obsolete by a future news item or
> after a long period of time. This is the same as the method used for ``updates``
> entries.

Might want to consider a maximum period of time for news entries to 
linger by default; perhaps a header for controlling deletion (this is 
would require commit access for whatever does the scans obviously).

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

Stop using trivial (no it's not in reference to above, just hit the 
right word count where I'm whinging about it).


> Reference Implementation
> ========================
> 
> Portage Code
> ------------
> 
> TODO

Points above regarding working sanely for N repos need be addressed, 
plus any implementation needs to be integrated, not handing off to an 
external tool (don't want 2 different implementations of atom 
parsing).

Personally... I still think package level news should not be treated 
as repository level information.  It makes any attempt at glep19 a bit 
trickier and stores package data in two different locations.
So... reiterating jasons question, example where news items transcend 
package specific?
~harring

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

kloeri@gentoo.org wrote:
> You must not have read the [#forums-whining]_ reference as that makes it
> quite clear that existing methods isn't adequate. Even if you think the
> apache maintainers made lots of mistakes you can't really fault us for
> not trying to get the news of config changes out to all users.

I haven't, that's correct.  However, a reference should be a source for 
additional information.  A small exerpt or recap of that thread is not 
in the GLEP.  Also, [#forums-whining]_ was not referenced in the quoted 
part, the reference only follows later on.

Going into answering your question, the thread suggests for instance an 
RSS-feed with this info.  Also the GLEP mentions 5 distinct sources, of 
which I personally think at least two will be effective for a certain 
group of people.

That last thing was what I was aiming at.  For some it might work quite 
well if the apache2 upgrade stuff (as sent out on gentoo-dev) was 
communicated through gentoo-announce.  Hence my doubts on whether "[they 
are not] particularly effective" is a general statement that applies to 
any situation.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Lisa Seelye]

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

On Sat, 2005-11-05 at 00:58 +0000, Ciaran McCreesh wrote:
> Feedback from people who have something useful to say would be very much
> welcomed, assuming of course that they've read the GLEP.


It is written in the GLEP (Requirements):

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.

And later in Specification->Overview:

5. Users fetch the news item when they sync. This ensures that the news
items in question are pushed to the user before the user accidentally
makes an unwanted change. No changes to the existing rsync process are
required by this GLEP.

My concerns are twofold:

The first is the method of delivery:  Through 'emerge sync', which
requires that users run this on a regular basis to receive relevant
news.  Further, this process can take a very long time and transfers a
relatively large amount of data along with the news.

My second concern is the frequency that users sync.  A stated concern is
getting news to users before it is too late.  Is there any way to gauge
the number of unique users which sync on a regular basis?  When is "too
late"?  Is there an acceptable window for delivering news?  It is not
uncommon for me to refrain from running emerge sync (or even cvs up on
the entire gentoo-x86 tree) for weeks or months on machines I wish to
keep somewhat static.

-- 
Regards,
Lisa Seelye
GPG: 09CF5 2D6B8 2B72B 997A7 601BC B46B5 561E4 96FC5
http://www.thedoh.com/~lisa/site

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Brian Harring]

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

Additional issue/question...

On Sat, Nov 05, 2005 at 12:58:14AM +0000, Ciaran McCreesh wrote:
> 6. Portage filters the news item and, if it is relevant, installs it in a
>    special location to be read by a news item reader. Messages are also
>    displayed to inform the user that news is available.
> 7. The news item is handled by the user's choice of news item reader. See `News
>    Item Clients`_.
> 
<snip>
> 
> Client Side
> '''''''''''
> 
> 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.
> 
> The unread news message will also be displayed immediately after an
> ``emerge sync``.

Your example readers delete from the news directory, yet I'd expect 
that's not going to be desirable for all setups- nor is leaving the 
news item in the news directory, and having it flagged every sync by 
emerge as unread.

Might want to consider some way to mark an item as read without waxing 
it from the directory, if against it, clarify in the glep why.
~harring

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[kloeri]

On Sat, Nov 05, 2005 at 12:29:28PM +0100, Grobian wrote:
> kloeri@gentoo.org wrote:
> >You must not have read the [#forums-whining]_ reference as that makes it
> >quite clear that existing methods isn't adequate. Even if you think the
> >apache maintainers made lots of mistakes you can't really fault us for
> >not trying to get the news of config changes out to all users.
> 
> I haven't, that's correct.  However, a reference should be a source for 
> additional information.  A small exerpt or recap of that thread is not 
> in the GLEP.  Also, [#forums-whining]_ was not referenced in the quoted 
> part, the reference only follows later on.
> 
> Going into answering your question, the thread suggests for instance an 
> RSS-feed with this info.  Also the GLEP mentions 5 distinct sources, of 
> which I personally think at least two will be effective for a certain 
> group of people.
> 
> That last thing was what I was aiming at.  For some it might work quite 
> well if the apache2 upgrade stuff (as sent out on gentoo-dev) was 
> communicated through gentoo-announce.  Hence my doubts on whether "[they 
> are not] particularly effective" is a general statement that applies to 
> any situation.
> 
If we were only aiming at a certain group of people there would be no
need to change anything. The apache announcements reached lots of users
but still left a large chunk of users in the dark. Moving the news to
-announce or some RSS feed wouldn't change anything as the basic problem
with these methods is that people have to actively search out important
news instead of news getting pushed to them.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jan Kundrát]

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

On Saturday 05 of November 2005 12:34 Lisa Seelye wrote:
> The first is the method of delivery:  Through 'emerge sync', which
> requires that users run this on a regular basis to receive relevant
> news.  Further, this process can take a very long time and transfers a
> relatively large amount of data along with the news.
>
> My second concern is the frequency that users sync.  A stated concern is
> getting news to users before it is too late.  Is there any way to gauge
> the number of unique users which sync on a regular basis?  When is "too
> late"?  Is there an acceptable window for delivering news?  It is not
> uncommon for me to refrain from running emerge sync (or even cvs up on
> the entire gentoo-x86 tree) for weeks or months on machines I wish to
> keep somewhat static.

How can users who don't run `emerge --sync` or any other syncing methods 
perform possibly dangerous upgrades of packages?

Cheers,
-jkt

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

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

kloeri@gentoo.org wrote:
> If we were only aiming at a certain group of people there would be no
> need to change anything. The apache announcements reached lots of users
> but still left a large chunk of users in the dark. Moving the news to
> -announce or some RSS feed wouldn't change anything as the basic problem
> with these methods is that people have to actively search out important
> news instead of news getting pushed to them.

I disagree.  A lot Gentoo users I know read gentoo-announce and the GWN. 
  For me it works quite well if I see a message with a warning on 
something.  I can quickly find it back if I am in need for it.  I would 
typically disable the whole news feature of portage and just watch the 
announce ML with all the news announcements.  Works fine for me.

The GLEP *is* targetted at a certain group of people, since it is there 
mainly to help those that complained in [forum_whining] and those -- I 
think -- mostly desktop end-users to prevent them from breaking their 
system and complain with us.

I broke my webserver too after the apache update.  Too bad I was stupid 
enough to 'just do it' on a webserver that should *not* have been 
offline for a while.  I just ignored the message the init.d script gave 
when it refused to stop my apache.  To cut a long story shory, I have 
solved the problem myself, knowing I was stupid for ignoring the message 
on gentoo-dev.  I never blamed the apache herd or anyone else but myself 
and just fixed it myself.  Sys-admins are supposed to try updates on a 
toy box first.  A warning is nice, documentation on how to solve it the 
best is even nicer.  Think of "knowledge books" of many commercial systems.

What the GLEP does is twofold:
1. Suggest special (**important**) news items to be accepted within
    Gentoo, and them being stored somewhere
2. Desparately push this news to users, because it seems that they don't
    read information which is not available (yet! see 1).

So thank you for letting me realise that this GLEP should be splitted in 
two.  One for just realising and standardising a way to publish news 
items on normal and known media: mailing lists, RSS feeds and WWW pages. 
  It should include topics regarding what information (like solutions or 
workarounds) should be there.

Then an additional GLEP which suggests the pushing of information to the 
user -- like this current GLEP -- can be written when it becomes clear 
after a reasonable amount of time after realising the GLEP mentioned 
above doesn't work sufficiently.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jason Stubbs]

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

Examples of the "recent upgrade debacles" aren't needed, but you should at 
least state some of the outcomes that occurred, whether it be unscheduled 
downtime, data corruption or whatever.

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

s/after/when/ perhaps? This sentence takes a couple of reads...

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

Could you use "complaints" instead of "whining" or whatever will represent 
what the users are doing from an unbiased point of view please?

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

"morons" is not needed either.

> The following headers are used for filtering. If none of these headers are
> specified, the news item is displayed for all users. Otherwise, the news
> item is displayed if *at least one* header matches.

It would seem more useful if the headers were sorted into the three classes 
first. A news item would then only be displayed if a header from the class 
matches or the class is empty. This would allow for rules such as 
"net-www/apache is installed and the keyword is either mips or sparc".

> ``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.
>
> ``Display-If-Profile:``
>     A profile path, for example ``default-linux/sparc/sparc64/server``. If 
>     the user is using the exact profile in question, the news item should be
>     displayed. This header may be used to replace ``deprecated`` files in 
>     the future.

Isn't keyword just a generalization of profile? Why have both?

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

Why gentoo-core? It's a news item; it's purpose is to be made public.

> Client Side
> '''''''''''
> 
> Whenever relevant unread news items are found, ``emerge`` will copy or
> symlink the news file into ``/var/lib/gentoo/news/``.
> 
> 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.
> 
> The unread news message will also be displayed immediately after an
> ``emerge sync``.
> 
> Portage may also warn of unread news items using, for example, a red flashy
> before actions such as merging a package.
> 
> Portage must keep track of news items which have already been installed to
> avoid repeatedly reinstalling a deleted news item.

Why put this in portage at all? Post sync hooks will likely be available in 
2.0.54. If adding hooks were as easy as adding a file to a portage config 
directory, would adding the package that does the above to the system package 
set be enough to force this new information dispersal method on users?

> Once a news item is 'installed', third party tools (or a traditional Unix
> pager and ``rm``) can be used to display and view the news files. An 
> ``eselect`` [#eselect]_ module shall be created as the 'suggested' display 
> tool; other display tools (for example, a news to email forwarder, which 
> would be ideal for users who sync on a cron) are left as options for those 
> who desire them -- the simple file format make this relatively simple.

This is just more reasoning that nothing should be added to portage at all...

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Bryan Ãstergaard]

On Sat, Nov 05, 2005 at 01:58:00PM +0100, Grobian wrote:
> kloeri@gentoo.org wrote:
<snip>
> I disagree.  A lot Gentoo users I know read gentoo-announce and the GWN. 
>  For me it works quite well if I see a message with a warning on 
> something.  I can quickly find it back if I am in need for it.  I would 
> typically disable the whole news feature of portage and just watch the 
> announce ML with all the news announcements.  Works fine for me.
> 
> The GLEP *is* targetted at a certain group of people, since it is there 
> mainly to help those that complained in [forum_whining] and those -- I 
> think -- mostly desktop end-users to prevent them from breaking their 
> system and complain with us.
> 
> I broke my webserver too after the apache update.  Too bad I was stupid 
> enough to 'just do it' on a webserver that should *not* have been 
> offline for a while.  I just ignored the message the init.d script gave 
> when it refused to stop my apache.  To cut a long story shory, I have 
> solved the problem myself, knowing I was stupid for ignoring the message 
> on gentoo-dev.  I never blamed the apache herd or anyone else but myself 
> and just fixed it myself.  Sys-admins are supposed to try updates on a 
> toy box first.  A warning is nice, documentation on how to solve it the 
> best is even nicer.  Think of "knowledge books" of many commercial systems.
> 
<snip>

Even if you don't realise that this will be a big help for many users or
you just don't think those users deserver any help (not sure which one
it is tbh) - you might at least consider the fact that only having to
push news about major / critical changes in one place is going to make
things a lot easier for devs.

Frankly, I don't see any reason not to follow through with this GLEP as
it's going to be very useful for many people and the current "system"
has shown itself to be inadequate lots of times already.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Brian Harring]

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

On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote:
> > ``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.
> >
> > ``Display-If-Profile:``
> >     A profile path, for example ``default-linux/sparc/sparc64/server``. If 
> >     the user is using the exact profile in question, the news item should be
> >     displayed. This header may be used to replace ``deprecated`` files in 
> >     the future.
> 
> Isn't keyword just a generalization of profile? Why have both?
You would have to specify a common subprofile, and have the code know 
to dig through the ancestors of a profile.

Breaks down when dealing with profiles that lack a common base 
(conversion from flat profiles to cascaded for example).

~harring

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jason Stubbs]

On Saturday 05 November 2005 22:24, Brian Harring wrote:
> On Sat, Nov 05, 2005 at 10:18:14PM +0900, Jason Stubbs wrote:
> > > ``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.
> > >
> > > ``Display-If-Profile:``
> > >     A profile path, for example
> > > ``default-linux/sparc/sparc64/server``. If     the user is using the
> > > exact profile in question, the news item should be     displayed.
> > > This header may be used to replace ``deprecated`` files in     the
> > > future.

Where'd those funny "A"s come from?

> > Isn't keyword just a generalization of profile? Why have both?
>
> You would have to specify a common subprofile, and have the code know
> to dig through the ancestors of a profile.

"If a user is using the exact profile in question"... Common subprofiles seem 
to be irrelevant. I was going to bring up that point as well, but then I 
recalled that some utilized profiles have children also (such as amd64/2005.1 
and amd64/2005.1/no-multilib). If subprofiles were also picked up, there 
would be no way to specify a news item that only pertained to multilib amd64 
systems.

> Breaks down when dealing with profiles that lack a common base
> (conversion from flat profiles to cascaded for example).

My understanding is that each class of header can appear multiple times. As 
far as I can tell Display-If-Keyword would just prevent having to specify 
Display-If-Profile for each profile of the keyword specified. I'd just like 
to clarify that it has no purpose beyond that.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

"Bryan �������������������������������" wrote:
> Even if you don't realise that this will be a big help for many users or
> you just don't think those users deserver any help (not sure which one
> it is tbh) - you might at least consider the fact that only having to
> push news about major / critical changes in one place is going to make
> things a lot easier for devs.

Any help that you can give is great.  I am not against the ideas in this 
GLEP.  It's are good ideas.  However, you cannot push something that is 
not there, and you cannot say you *have* to push it because other ways 
don't work -- ways which aren't yet explored.  News items as described 
have never been published before, IMHO, and hence the effect of 
un-filtered, un-personalised publishing of these news items is *not* 
known.  I would priorise on getting them published somehow, and in the 
meanwhile continue on this GLEP from another perspective: "personalising 
news messages based on the user's portage".  Such GLEP can elaborate 
much more on support for mailing automatically to root or another user, 
pushing forcibly on the screen or reading via 'news-update', just to 
suit every installation/user scenario that we can dream up.

It also is in the two separate issues that you snipped from my previous 
mail.

I think we're not going to agree here, so to prevent any more lengthy 
discussions over gentoo-dev on this topic, you can contact me off-list.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 05 Nov 2005 11:28:33 +0100 Grobian <grobian@gentoo.org> wrote:
| > Preemptive
| >     Users should be told of changes *before* they break the user's
| > system, after the damage has already been done.
| 
| style suggestion for unambigous interpretation:
| perhaps a "because if applied afterwards" instead of "after"

Ugh. Wonder how many comments I'm going to get on that one... There
should be a "not" before "system", which I accidentally killed by
pressing the wrong key in Vim.

| Apart from that this point seems to repeat much of the previous one,
| it introduces a new unfounded claim (users do read, but now too late)

Read the linked forums thread and all will become clear.

| > 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.
| 
| Direct question that follows from this: what *do* we expect a 
| user/system to have available?  I think it's good to state that as
| well, since you're excluding a lot here in once sentence.

Anything that's in the system target, and as little as is reasonably
possible extra.

| Where does point 4 differ from the second part of point 3?

Oops.

| > 6. Portage filters the news item and, if it is relevant, installs
| > it in a special location to be read by a news item reader. Messages
| > are also displayed to inform the user that news is available.
| 
| So, same as for point 5, the exact details on how this works and what
| a 'news item reader' is (since you previously defined a requirement
| of having almost nothing available on the system) should be refered
| to here.  I want to be sure that you will elaborate on it lateron, so
| I can stack up my many questions for now.

A news item reader is something which reads news items.

| > 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 short name
| > must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-``
| > (hyphen).
| 
| Consider replacing hyphen with an underscore to ease parsing.

Mixing hyphens and underscores? That's just going to start confusing
things...

| (Maybe: "An English (''en'') version must be available for all news 
| items as per GLEP 34 [#glep-34]_.  Other languages ...")

GLEP 34 doesn't say anything about news items...

| > ``Author:``
| >     Author's name and email address, in the form ``Real Name
| > <email@address>``. Mandatory, multiple author fields may be
| > specified if appropriate.
| 
| Separated how?  Using commas, semicolons, spaces or whatever?

Multiple fields. Maybe that'd be clearer were it to say "Mandatory;
multiple author headers may ...".

| > ``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.
| 
| Perhaps you want to track trivial changes as well in the minor, in
| order to be able to quickly see a change was made, and prevent people
| from considering a non-trivial change as trivial.

Well, if you want to see that it was made, it's not trivial.

| Maybe you should explicitly state this field is optional and why.  I
| could think of some reasons why this header should be mandatory, but
| perhaps you add a completely different value to the header than I do
| now.

Maybe I should just mark it as mandatory instead.

|  From a completeness perspective, it would perhaps be a option to 
| include a special header that contains a boolean expression that 
| resolves to true if the message is relevant to the user, and false 
| otherwise.  This would allow AND and NOT to be included instead of
| only OR semantics.
|
| In any case, elaborate on why supporting only OR was chosen and why 
| other (probably investigated) options were discarded (and hence make
| my statement above unnecessary).

The previous draft had an option for and or none-of modes. I took it
out because I don't think it's going to be anywhere near as useful as
one might initially think.

| > 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.
| 
| Elaborate some more on "No fancy formatting or tab characters".
| People might want/like to include a bulleted/numbered list or insert
| a small (shell) code example.  Also make some note on the average
| length (number of paragraphs) and perhaps a predefined structure
| (ie.: introduction/abstract, impact, solutions/actions,
| links/more-information)

These're things to be decided when news items are sent for review. Once
we have some real material there'll be a more useful way of judging
what is acceptable and what has gone too far.

| > Thus, 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.
| 
| The idea is great, but perhaps the current docs teams should deal
| with this, as they are currently responsible for the webpages as well?

There's nothing saying "don't Cc: the docs people". By all means Cc:
them if they are relevant...

| In any case:
| - 72 hours is a lot (is there a way to shorten it when everything is
|    there?)

For a major change? If you don't have a major change planned out at
least 72 hours in advance you shouldn't be making it.

| - what if noone feels like commenting on the submission?

Then it's assumed correct.

| - how do you know a certain dev is a competent English speaker?

*shrug* If we ever get onto linguistics arguments, there're enough of
us with copies of Fowler and the OUP Style Guide to settle things.

| This raises many questions.  I suggest to define the process a bit
| more and include a scheme that deals with this kind of concerns to
| actually make it water (and fool) proof.

Pfff, no system is fool proof. All adding more tricky little items will
do is piss people off.

| > News items must only be for **important** changes that may cause
| > serious upgrade or compatibility problems. Ordinary upgrade
| > messages and non-critical news items should remain in ``einfo``
| > notices. The importance of the message to its intended audience
| > should be justified with the proposal.
| 
| Somehow there needs to be a voting/selection process to figure out 
| whether something is **important** or not. 

It's important if you can justify it as such on -dev.

| Does portage only 'warn' and still continue, or does it completely
| stop when an unread news item is found for a package that is to be
| upgraded? In the first case, the 'preemptive' requirement is being
| violated, in the latter, the option for a '--force' or something must
| be discussed. (Users with multiple systems might already know the
| message, or users might not be interested in it since they don't run
| the application in production.)

Portage only *warns* you if you try to unmerge glibc...

| This Section is too short in this form to live on its own.  It should 
| either be extended or merged with text above where I made a comment
| on the details.  Perhaps you can elaborate on how to implement such 
| forwarders, especially in the light of my comments on the previous
| Section.

See "Reference Implementation".

| This sounds much alike what 'mail' used to (and still) does.  It has
| the ability to see which messages are waiting, select them to read
| with a pager and delete them.  Make sure you explain why this is
| better, and why you 'seemingly' reinvent the wheel here.  I think I
| can think of some reasons, but I think you need to make it clear.

It's vaguely like mail, but without the MTA requirement.

| Yes, and make it a requirement that all news messages get posted 
| somewhere on public channels.

I don't see any particular need to *require* that all news items are
posted to a specific place.

| I hope I have not created a new opportunity for large flame wars.  I 
| tried being quite constructive, and reviewed the GLEP as a scientific 
| paper.

It's a technical paper rather than a scientific one, so I'm not
bothering to justify things that every developer should already know.
It's mostly a question of space... I *could* bog everyone down in
twenty pages of references, but why bother?

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 05:24:51 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| Drop the lightweight bit and merge it into multiple delivery.  You're 
| after lightweight _default_, which is fine, but the phrasing is a bit 
| screwed.

Hrm, I don't see those as contradictory. There's a requirement that the
solution does not require anything fancy, and a requirement that the
solution does not force one particular reading method upon the user.
There's no requirement that the solution must not be usable with
anything which is not lightweight.

| > News items are published and delivered to users as follows:
| <snip>
| > 6. Portage filters the news item and, if it is relevant, installs
| > it in a special location to be read by a news item reader. Messages
| > are also displayed to inform the user that news is available.
| 
| Out of curiousity, how are you planning on having 101 general notices 
| reigned down on a users head during an initial install?  Yes, you
| have the atom filter, but what about general notices?

People who've just done an initial install won't have lots of packages
installed. As for general notices, if there're lots of them we have
serious issues...

| Further, how are notices going to apply to users who don't have the 
| package installed, then go and merge it?  Your statement above
| implies the irrevalent (at the time of sync) notices are ignored,
| which breaks down under the scenario where a news item is pushed out
| that apache configuration is going to change, I merge old style
| apache after sync'ing the news, portage (due to your news id cache)
| considers it deleted, and doesn't display it.

Wording perhaps could be clearer... News items are added to the "don't
copy again" list when they're copied, not when they're checked.

| > News items may be signed using GPG. If this is done, a detached
| > signature should be used.
| 
| I'd argue for must be, personally.  A bogus news item claiming to be 
| from portage devs, telling users to change their SYNC setting could 
| cause massive mayhem.

Signing elsewhere isn't mandatory yet.

| Still haven't address my point about
| A) package moves combined with news entries

Gotta handle those manually / with epkgmove. Someone could write a
server-side handler for automatic updates if they want, but given that
package moves are already a case of "do all the things on a big list",
it's not much added complexity...

| B) N packages
| 
| Assume you mean that the bit above is a full DepSet, not a single
| atom (if that's the case, clarify that N atoms are allowed).

A single atom is probably sanest...

| Should clarify USE conditionals are a no go- might be worth 
| considering the full atom syntax (despite the fact portage doesn't 
| currently support it for depends), use flags, slot, etc.

I'd rather not try to guess what Portage may or may not support in the
future. There's nothing precluding using :slot and [use] atoms if
portage ever supports them.

| > ``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.
| 
| N keywords == N Header entries?

Yup.

| No go on -core imo; it's a community/dev issue, should be visible to 
| the general public rather then hidden away in the ml we do our
| flaming in.

There *might* be legit security reasons for using -core, for example
for nasty "upgrade required" security bugs that we can't disclose
before a given date. Hopefully this will never happen.

| Already pointed out that this won't fly looking forward, it
| implicitly assumes a single repository.

Again, we can deal with that if Portage ever gets multiple repo
support. Until it does, I'm not trying to guess how it's going to end
up being implemented.

| Nuke flashy (any phrasing that allows for blinking crap sliding into
| portage I instinctively dislike).

Is there a technical name for the big red !!!!! messages?

| > Portage must keep track of news items which have already been
| > installed to avoid repeatedly reinstalling a deleted news item.
| 
| Track it how, via the directory, or a secondary list?

The GLEP doesn't require any particular implementation.

| > News items can be removed (by removing the news file from the main
| > tree) when they are no longer relevant, if they are made obsolete
| > by a future news item or after a long period of time. This is the
| > same as the method used for ``updates`` entries.
| 
| Might want to consider a maximum period of time for news entries to 
| linger by default; perhaps a header for controlling deletion (this is 
| would require commit access for whatever does the scans obviously).

We don't do this with updates or ebuilds or anything else, so I don't
really see the point.

| Stop using trivial (no it's not in reference to above, just hit the 
| right word count where I'm whinging about it).

But it's such a nice word!

| Points above regarding working sanely for N repos need be addressed, 

Which I'll do right before Portage gets N repo support.

| So... reiterating jasons question, example where news items transcend 
| package specific?

Easy example? There might be changes in vim7 which would warrant a news
item covering vim, gvim, vim-core, kvim.

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 05 Nov 2005 11:34:23 +0000 Lisa Seelye <lisa@gentoo.org> wrote:
| The first is the method of delivery:  Through 'emerge sync', which
| requires that users run this on a regular basis to receive relevant
| news.  Further, this process can take a very long time and transfers a
| relatively large amount of data along with the news.
| 
| My second concern is the frequency that users sync.  A stated concern
| is getting news to users before it is too late.  Is there any way to
| gauge the number of unique users which sync on a regular basis?  When
| is "too late"?  Is there an acceptable window for delivering news?
| It is not uncommon for me to refrain from running emerge sync (or
| even cvs up on the entire gentoo-x86 tree) for weeks or months on
| machines I wish to keep somewhat static.

Well... If a user doesn't sync, they're not going to get hit by upgrade
problems. So so long as news items are kept around for a "sufficiently
long" period of time, there aren't going to be issues.

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 05:43:12 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| Your example readers delete from the news directory, yet I'd expect 
| that's not going to be desirable for all setups- nor is leaving the 
| news item in the news directory, and having it flagged every sync by 
| emerge as unread.
| 
| Might want to consider some way to mark an item as read without
| waxing it from the directory, if against it, clarify in the glep why.

Hrm. Append '.read' to the filename?

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 22:18:14 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| > A more reliable way of getting news of critical updates out to
| > users is required to avoid repeats of the various recent upgrade
| > debacles.
| 
| Examples of the "recent upgrade debacles" aren't needed, but you
| should at least state some of the outcomes that occurred, whether it
| be unscheduled downtime, data corruption or whatever.

I'm trying to avoid throwing in too many unnecessary references, but I
guess a couple here would be useful.

| 
| > Preemptive
| >     Users should be told of changes *before* they break the user's
| > system, after the damage has already been done.
| 
| s/after/when/ perhaps? This sentence takes a couple of reads...

Ring up another one for me hitting . in Vim forgetting that I'd done a
daw after the gq} ...

| > 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.
| 
| "morons" is not needed either.

No, but it's funny!

| > The following headers are used for filtering. If none of these
| > headers are specified, the news item is displayed for all users.
| > Otherwise, the news item is displayed if *at least one* header
| > matches.
| 
| It would seem more useful if the headers were sorted into the three
| classes first. A news item would then only be displayed if a header
| from the class matches or the class is empty. This would allow for
| rules such as "net-www/apache is installed and the keyword is either
| mips or sparc".

Hrm. I'll need to think about that. But it's starting to sound nicer
than the and/or/none voodoo I'd removed previously.

| Isn't keyword just a generalization of profile? Why have both?

Simplicity.

| > Thus, 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.
| 
| Why gentoo-core? It's a news item; it's purpose is to be made public.

Possible security concerns. Hopefully this will never happen.

| Why put this in portage at all? Post sync hooks will likely be
| available in 2.0.54. If adding hooks were as easy as adding a file to
| a portage config directory, would adding the package that does the
| above to the system package set be enough to force this new
| information dispersal method on users?

Performance. I have a bash script which does the installs that could
easily be called by a hook, but it has to call portageq quite a bit.
Otherwise a hook would be fine... Possibly it's fine anyway?

-- 
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 42 "Critical News Reporting" Round Two

[Ferris McCormick]

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

On Sat, 5 Nov 2005, Ciaran McCreesh wrote:

> On Sat, 05 Nov 2005 11:28:33 +0100 Grobian <grobian@gentoo.org> wrote:
> | > Preemptive
> | >     Users should be told of changes *before* they break the user's
> | > system, after the damage has already been done.
> |
> | style suggestion for unambigous interpretation:
> | perhaps a "because if applied afterwards" instead of "after"
>
> Ugh. Wonder how many comments I'm going to get on that one... There
> should be a "not" before "system", which I accidentally killed by
> pressing the wrong key in Vim.
>

I can't resist.  I think you mean '"not" after "system,"': "...*before* 
they break the user's system, not after ...."

Regards,

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc, devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDbPLTQa6M3+I///cRAsAhAKDgotmZ+E9TMdLAgzUbVj8s3++mVwCfeVoj
9TSuRiLKvIofQFPp/RRrC4I=
=1MKl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 17:58:40 +0000 (UTC) Ferris McCormick
<fmccor@gentoo.org> wrote:
| I can't resist.  I think you mean '"not" after "system,"':
| "...*before* they break the user's system, not after ...."

Uh oh, I think I finally cracked. Now I'm craaaaaaaaazzyyyyyyy!!!

-- 
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 42 "Critical News Reporting" Round Two

[Ned Ludd]

On Sat, 2005-11-05 at 17:53 +0000, Ciaran McCreesh wrote:
> On Sat, 5 Nov 2005 05:43:12 -0600 Brian Harring <ferringb@gentoo.org>
> wrote:
> | Your example readers delete from the news directory, yet I'd expect 
> | that's not going to be desirable for all setups- nor is leaving the 
> | news item in the news directory, and having it flagged every sync by 
> | emerge as unread.
> | 
> | Might want to consider some way to mark an item as read without
> | waxing it from the directory, if against it, clarify in the glep why.
> 
> Hrm. Append '.read' to the filename?

chmod -r filename


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Philip Webb]

051105 Ciaran McCreesh wrote:
 ...
> News Item File Format
 ...
> The news item will be named in the form ``yyyy-mm-dd-item-name.en.txt``
 ...
> News Item Headers
 ...
>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).

</spectate>
Why the change in date format ?  Let's use the proper international style,
ie ``yyyy-mm-dd``, in both places, which has the added advantage
of not creating problems for non-Anglophones with different month names.
<spectate>

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 05 Nov 2005 14:13:32 -0500 Ned Ludd <solar@gentoo.org> wrote:
| > Hrm. Append '.read' to the filename?
| 
| chmod -r filename

Makes writing clients a pain in the ass.

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 14:24:01 -0500 Philip Webb <purslow@sympatico.ca>
wrote:
| 051105 Ciaran McCreesh wrote:
| > News Item File Format
|  ...
| > The news item will be named in the form
| > ``yyyy-mm-dd-item-name.en.txt``
|  ...
| > News Item Headers
|  ...
| >     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
| 
| </spectate>
| Why the change in date format ?  Let's use the proper international
| style, ie ``yyyy-mm-dd``, in both places, which has the added
| advantage of not creating problems for non-Anglophones with different
| month names. <spectate>

Consistency with GLEPs.

-- 
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 42 "Critical News Reporting" Round Two

[Brian Harring]

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

On Sat, Nov 05, 2005 at 05:45:35PM +0000, Ciaran McCreesh wrote:
> | > News items may be signed using GPG. If this is done, a detached
> | > signature should be used.
> | 
> | I'd argue for must be, personally.  A bogus news item claiming to be 
> | from portage devs, telling users to change their SYNC setting could 
> | cause massive mayhem.
> 
> Signing elsewhere isn't mandatory yet.

Deal with it ;)

New additions to the tree that don't require signing 
just shove more load onto anyone who is trying to make the entire tree 
signed- you're already placing it in the tree so it doesn't make screw 
with future portage plans (news directory), this isn't much different.

Note also I'm not stating your example clients must handly signing- 
it'll ugly up the trivial exmples a bit, but the messages delivered 
*must* be signed from where I'm sitting.

It's easy to state that "well others don't have to sign"; the problem 
here is that you must start somewhere.  If the whole effort of signing 
is abandoned, the restriction that all news items be signed is easily 
dropped- going in reverse (retroactively getting authors to sign their 
old news) is a bit of work that could be avoided.


> | Still haven't address my point about
> | A) package moves combined with news entries
> 
> Gotta handle those manually / with epkgmove. Someone could write a
> server-side handler for automatic updates if they want, but given that
> package moves are already a case of "do all the things on a big list",
> it's not much added complexity...

Note it please; it's a concern.

> | No go on -core imo; it's a community/dev issue, should be visible to 
> | the general public rather then hidden away in the ml we do our
> | flaming in.
> 
> There *might* be legit security reasons for using -core, for example
> for nasty "upgrade required" security bugs that we can't disclose
> before a given date. Hopefully this will never happen.

Valid point, which will hopefully be noted in v3 of the glep? :)

> | Already pointed out that this won't fly looking forward, it
> | implicitly assumes a single repository.
> 
> Again, we can deal with that if Portage ever gets multiple repo
> support. Until it does, I'm not trying to guess how it's going to end
> up being implemented.

*cough* PORTDIR_OVERLAY *cough*

Already have multiple repo support.  Assumed you meant standalone, in 
which case I still think you're dodging support that must be there.

Changing it after the fact because it wasn't design with an extra bit 
of forward thinking isn't something I'm incredibly game for.  Yes it's 
extra work for you, but you're proposing the change ;)

You're going for forward compatibility... this is just that.

> | Nuke flashy (any phrasing that allows for blinking crap sliding into
> | portage I instinctively dislike).
> 
> Is there a technical name for the big red !!!!! messages?

Freaking annoying, is the technical term I use.
~harring

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Philip Webb]

051105 Ciaran McCreesh wrote:
> 5 Nov 2005 14:24:01 -0500 Philip Webb <purslow@sympatico.ca> wrote:
>> 051105 Ciaran McCreesh wrote:
>> > News Item File Format
>>  ...
>> > The news item will be named in the form
>> > ``yyyy-mm-dd-item-name.en.txt``
>>  ...
>> > News Item Headers
>>  ...
>> >     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
>> 
>> </spectate>
>> Why the change in date format ?  Let's use the proper international
>> style, ie ``yyyy-mm-dd``, in both places, which has the added
>> advantage of not creating problems for non-Anglophones with different
>> month names. <spectate>
> Consistency with GLEPs.

Sorry, that doesn't mean anything:
could you offer something which makes more sense ?

(I do realise you have put a lot of effort into this & appreciate it)

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Ciaran McCreesh wrote:
> | Apart from that this point seems to repeat much of the previous one,
> | it introduces a new unfounded claim (users do read, but now too late)
> 
> Read the linked forums thread and all will become clear.

the forums thread advocates against the new unfounded claim, IMHO.

> | > 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 short name
> | > must consist only of characters ``a-z``, ``A-Z``, ``0-9`` and ``-``
> | > (hyphen).
> | 
> | Consider replacing hyphen with an underscore to ease parsing.
> 
> Mixing hyphens and underscores? That's just going to start confusing
> things...

I was referring to the item-name.  It is defined to allow "-", whild the 
fields are also separated with "-".  Hence I suggested to allow "_" in 
the item-name instead of "-" to avoid (possible) problems when parsing 
the field.

> | In any case, elaborate on why supporting only OR was chosen and why 
> | other (probably investigated) options were discarded (and hence make
> | my statement above unnecessary).
> 
> The previous draft had an option for and or none-of modes. I took it
> out because I don't think it's going to be anywhere near as useful as
> one might initially think.

I'd appreciate it if that would be documented and grounded.

> | Elaborate some more on "No fancy formatting or tab characters".
> | People might want/like to include a bulleted/numbered list or insert
> | a small (shell) code example.  Also make some note on the average
> | length (number of paragraphs) and perhaps a predefined structure
> | (ie.: introduction/abstract, impact, solutions/actions,
> | links/more-information)
> 
> These're things to be decided when news items are sent for review. Once
> we have some real material there'll be a more useful way of judging
> what is acceptable and what has gone too far.

I guess then it's better to state that, and make no assumptions or 
partial decisions on it.  If it is out of scope of the GLEP, make it 
like that.

> | - what if noone feels like commenting on the submission?
> 
> Then it's assumed correct.
> 
> | - how do you know a certain dev is a competent English speaker?
> 
> *shrug* If we ever get onto linguistics arguments, there're enough of
> us with copies of Fowler and the OUP Style Guide to settle things.

Then what is the point in requiring it is correct English?  (Not even 
considering the big difference between UK/US English)  You can and will 
not enforce it.  Everyone writing such news item will do her/his best to 
make it sound like real English, and perhaps ask for help, but that's 
it.  Hence my suggestion to put the doc writers in the loop somehow.

> | Does portage only 'warn' and still continue, or does it completely
> | stop when an unread news item is found for a package that is to be
> | upgraded? In the first case, the 'preemptive' requirement is being
> | violated, in the latter, the option for a '--force' or something must
> | be discussed. (Users with multiple systems might already know the
> | message, or users might not be interested in it since they don't run
> | the application in production.)
> 
> Portage only *warns* you if you try to unmerge glibc...

Which means you won't be able to satisfy your "preemptive" requirement.

> | Yes, and make it a requirement that all news messages get posted 
> | somewhere on public channels.
> 
> I don't see any particular need to *require* that all news items are
> posted to a specific place.

You might be right, as the how, when and why of news items should be a 
completely separate thing, as I see it right now.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 17:24:14 -0500 Philip Webb <purslow@sympatico.ca>
wrote:
| > Consistency with GLEPs.
| 
| Sorry, that doesn't mean anything:
| could you offer something which makes more sense ?

GLEP 1 mandates date headers in that format.

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 05 Nov 2005 23:32:19 +0100 Grobian <grobian@gentoo.org> wrote:
| I was referring to the item-name.  It is defined to allow "-", whild
| the fields are also separated with "-".  Hence I suggested to allow
| "_" in the item-name instead of "-" to avoid (possible) problems when
| parsing the field.

The fields are separated with .s. Underscores for the name don't make
parsing any more or less difficult.

| > | In any case, elaborate on why supporting only OR was chosen and
| > | why other (probably investigated) options were discarded (and
| > | hence make my statement above unnecessary).
| > 
| > The previous draft had an option for and or none-of modes. I took it
| > out because I don't think it's going to be anywhere near as useful
| > as one might initially think.
| 
| I'd appreciate it if that would be documented and grounded.

Actually, I'm starting to think Jason's idea works best.

| Then what is the point in requiring it is correct English?  (Not even 
| considering the big difference between UK/US English)  You can and
| will not enforce it.  Everyone writing such news item will do her/his
| best to make it sound like real English, and perhaps ask for help,
| but that's it.  Hence my suggestion to put the doc writers in the
| loop somehow.

What makes you suppose that the doc writers are the most qualified
English language speakers?

| > | Does portage only 'warn' and still continue, or does it completely
| > | stop when an unread news item is found for a package that is to be
| > | upgraded? In the first case, the 'preemptive' requirement is being
| > | violated, in the latter, the option for a '--force' or something
| > | must be discussed. (Users with multiple systems might already
| > | know the message, or users might not be interested in it since
| > | they don't run the application in production.)
| > 
| > Portage only *warns* you if you try to unmerge glibc...
| 
| Which means you won't be able to satisfy your "preemptive"
| requirement.

Not at all. You can warn users repeatedly, but there comes a point when
trying to warn them any further becomes futile.


-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sat, 5 Nov 2005 14:29:31 -0600 Brian Harring <ferringb@gentoo.org>
wrote:
| > Signing elsewhere isn't mandatory yet.
| 
| Deal with it ;)

In order to deal with it, I'd also have to come up with a solution to
distributing keys for Gentoo developers. That's a separate issue which
must be addressed separately.

A wording change from "may" to "should be" is fine by me, but "must be"
is not, at least until we have a real signing system in place.

| > | Already pointed out that this won't fly looking forward, it
| > | implicitly assumes a single repository.
| > 
| > Again, we can deal with that if Portage ever gets multiple repo
| > support. Until it does, I'm not trying to guess how it's going to
| > end up being implemented.
| 
| *cough* PORTDIR_OVERLAY *cough*
| 
| Already have multiple repo support.  Assumed you meant standalone, in 
| which case I still think you're dodging support that must be there.

Overlays override on conflicts, they don't run in parallel.

| Changing it after the fact because it wasn't design with an extra bit 
| of forward thinking isn't something I'm incredibly game for.  Yes
| it's extra work for you, but you're proposing the change ;)
| 
| You're going for forward compatibility... this is just that.

I'm going for not making any design decisions which will preclude
reasonable future changes.

-- 
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 42 "Critical News Reporting" Round Two

[Jason Stubbs]

On Sunday 06 November 2005 02:57, Ciaran McCreesh wrote:
> On Sat, 5 Nov 2005 22:18:14 +0900 Jason Stubbs <jstubbs@gentoo.org>
> | > The following headers are used for filtering. If none of these
> | > headers are specified, the news item is displayed for all users.
> | > Otherwise, the news item is displayed if *at least one* header
> | > matches.
> |
> | It would seem more useful if the headers were sorted into the three
> | classes first. A news item would then only be displayed if a header
> | from the class matches or the class is empty. This would allow for
> | rules such as "net-www/apache is installed and the keyword is either
> | mips or sparc".
>
> Hrm. I'll need to think about that. But it's starting to sound nicer
> than the and/or/none voodoo I'd removed previously.

My sentences aren't making much sense either, even if you got my intention 
anyway. ;)  A news item would then only be displayed if a header from the 
class matches or the class is empty *for each class*.

> | Isn't keyword just a generalization of profile? Why have both?
>
> Simplicity.

Ok. Just confirming.

> | > Thus, 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.
> |
> | Why gentoo-core? It's a news item; it's purpose is to be made public.
>
> Possible security concerns. Hopefully this will never happen.

Ok.

> | Why put this in portage at all? Post sync hooks will likely be
> | available in 2.0.54. If adding hooks were as easy as adding a file to
> | a portage config directory, would adding the package that does the
> | above to the system package set be enough to force this new
> | information dispersal method on users?
>
> Performance. I have a bash script which does the installs that could
> easily be called by a hook, but it has to call portageq quite a bit.
> Otherwise a hook would be fine... Possibly it's fine anyway?

The script could be converted to Python. Or we can have a go at speeding up 
portageq a bit. (Or both ;). It's just that there's only a small part of 
integrated into portage as far as the current GLEP goes, which then partially 
locks people out of working with the news items in alternative ways... Could 
you send over the bash version of the post-sync script?

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Ciaran McCreesh wrote:
> | Which means you won't be able to satisfy your "preemptive"
> | requirement.
> 
> Not at all. You can warn users repeatedly, but there comes a point when
> trying to warn them any further becomes futile.

Then what is the point of this GLEP?  Instead, just warn people through 
existing intrastructure, which is cheap from an engineering perspective 
because everything is already there in place, and don't think of 
implementing all kinds of extras just to warn a user one extra time, 
since "trying to warn them any further becomes futile" anyway.

The motivation of your GLEP is based solely on the assumption that 
critical news is not effectively delivered to the user, however, the 
GLEP implicitly introduces this critical news, so how can it be ignored 
by users?  It's not there.

If you don't plan to solve the requirements you state yourself, either 
don't state them, or make clear you will not satisfy them for what 
reason.  To me it looks as if you just would like to remove the 
'preemptive' requirement because it suggests some behaviour that you 
don't (plan to) implement.  And hence, you should also rewrite the 
motivation to reflect your statement in the quote above.

I like the idea of the GLEP, since it will be helpful for many users I 
think, but the grounds on which and the reasons why should be valid 
points, IMHO.  I also think that the idea comes very close to things 
proposed and or desired by many users that would like to have all the 
einfo messages being sent out to them, or accumulated after portage has 
done it's compiling.  See the respective super bug and ml discussions on 
it.  Hence, the GLEP itself doesn't differentiate itself, is not defined 
to be generic enough or reusable, should include configurability and, 
last but not least as I mentioned before, should be grounded in valid 
points.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Sat, 2005-11-05 at 13:58 +0100, Grobian wrote:
> A lot Gentoo users I know read gentoo-announce and the GWN. 

But *many* more don't.  That's what we learned from the Apache package
refresh, and what we've also learned from the PHP5 work.

> Works fine for me.

What works for you is irrelevant to this conversation.  

What matters is getting news out to 100% of our userbase - or as near to
that as possible.  Saying that it works for you, and so there isn't a
problem, isn't a useful contribution.

> The GLEP *is* targetted at a certain group of people

It is targeted at every single Gentoo user.  Without exception or
discrimination.

> What the GLEP does is twofold:
> 1. Suggest special (**important**) news items to be accepted within
>     Gentoo, and them being stored somewhere
> 2. Desparately push this news to users, because it seems that they don't
>     read information which is not available (yet! see 1).

The information was available via several sources, but this did not
reach a wide enough audience.  As a result, we're proposing a new
mechanism for delivering news - one that we believe will be much more
successful.

> So thank you for letting me realise that this GLEP should be splitted in 
> two.

No thanks.  

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

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Stuart Herbert posted <1131309435.8543.16.camel@mogheiden.gnqs.org>,
excerpted below,  on Sun, 06 Nov 2005 20:37:14 +0000:

> On Sat, 2005-11-05 at 13:58 +0100, Grobian wrote:
>> A lot Gentoo users I know read gentoo-announce and the GWN.
> 
> But *many* more don't.  That's what we learned from the Apache package
> refresh, and what we've also learned from the PHP5 work.

While I agree with the point you make, I don't believe the apache upgrade
issues were announced on the announce list.  The news in the tree thing is
a good idea, IMO, but it'll take some time to implement.  "Earth changing"
(for some Gentoo users) announcements can and should go to announce --
that's what it's there for.

If I'm wrong about the apache upgrade, and it /was/ on announce, and I
just forgot about seeing it /there/ as I had already seen it discussed
here, which I /do/ remember, great!  I just don't recall seeing it there,
and tho I don't run apache myself, am of the opinion changes as big as
those described for apache /should/ have been on announce.

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sun, 06 Nov 2005 14:38:47 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| While I agree with the point you make, I don't believe the apache
| upgrade issues were announced on the announce list.  The news in the
| tree thing is a good idea, IMO, but it'll take some time to
| implement.  "Earth changing" (for some Gentoo users) announcements
| can and should go to announce -- that's what it's there for.

Why should every user have to sign up to be spammed with irrelevant
GLSAs and news items for packages which they do not use?

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sun, 06 Nov 2005 09:33:50 +0100 Grobian <grobian@gentoo.org> wrote:
| Ciaran McCreesh wrote:
| > | Which means you won't be able to satisfy your "preemptive"
| > | requirement.
| > 
| > Not at all. You can warn users repeatedly, but there comes a point
| > when trying to warn them any further becomes futile.
| 
| Then what is the point of this GLEP?  Instead, just warn people
| through existing intrastructure, which is cheap from an engineering
| perspective because everything is already there in place, and don't
| think of implementing all kinds of extras just to warn a user one
| extra time, since "trying to warn them any further becomes futile"
| anyway.

The current warning levels we have are insufficient. This GLEP proposes
a new system for warnings which will be far harder to accidentally
ignore. There are, however, limits to how far we can reasonably go
before we make the solution worse than the problem.

-- 
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] Re: GLEP 42 "Critical News Reporting" Round Two

[John Myers]

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

On Sunday 06 November 2005 13:38, Duncan wrote:
> I don't believe the apache upgrade issues were announced on the announce 
> list.   
For the record, it was sent to the announce list on 2004-12-24.
Message-Id: <200412240924.35397.stuart@gentoo.org>
Subject: [gentoo-announce] Apache packages refresh on 8th January 2005

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

On Sun, Nov 06, 2005 at 09:56:35PM +0000, Ciaran McCreesh wrote:
> | Then what is the point of this GLEP?  Instead, just warn people
> | through existing intrastructure, which is cheap from an engineering
> | perspective because everything is already there in place, and don't
> | think of implementing all kinds of extras just to warn a user one
> | extra time, since "trying to warn them any further becomes futile"
> | anyway.
> 
> The current warning levels we have are insufficient. This GLEP proposes
> a new system for warnings which will be far harder to accidentally
> ignore. There are, however, limits to how far we can reasonably go
> before we make the solution worse than the problem.

Remember that there are packages in the tree that satisfy the preemptive
requirement, since they simply die when trying to upgrade and a certain
amount of prerequisites is not met.  This prevents the user from losing
data files or making them inaccesible, while at the same pointing out
what needs to be done and why, using a short message.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jakub Moc]

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


7.11.2005, 9:41:04, Grobian wrote:

> On Sun, Nov 06, 2005 at 09:56:35PM +0000, Ciaran McCreesh wrote:
>> | Then what is the point of this GLEP?  Instead, just warn people
>> | through existing intrastructure, which is cheap from an engineering
>> | perspective because everything is already there in place, and don't
>> | think of implementing all kinds of extras just to warn a user one
>> | extra time, since "trying to warn them any further becomes futile"
>> | anyway.
>> 
>> The current warning levels we have are insufficient. This GLEP proposes
>> a new system for warnings which will be far harder to accidentally
>> ignore. There are, however, limits to how far we can reasonably go
>> before we make the solution worse than the problem.

> Remember that there are packages in the tree that satisfy the preemptive
> requirement, since they simply die when trying to upgrade and a certain
> amount of prerequisites is not met.  This prevents the user from losing
> data files or making them inaccesible, while at the same pointing out
> what needs to be done and why, using a short message.

Uhm, breaking the emerge chain in *not* an alternative to this GLEP, in no
way... Leaving the rest of the upcoming rant/flame for ciaranm's pleasure. :=)


-- 
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 42 "Critical News Reporting" Round Two

[Paul de Vrieze]

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

On Saturday 05 November 2005 01:58, Ciaran McCreesh wrote:
> ``Posted:``
>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001). UTC
> time in ``hh-mm-ss +0000`` format may also be included. This field is
> mandatory.

What about also allowing the yyyy-mm-dd format (with or without hyphens). 
Using English month names is not the most convenient for many people.

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 42 "Critical News Reporting" Round Two

[Henrik Brix Andersen]

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

On Mon, Nov 07, 2005 at 11:50:22AM +0100, Paul de Vrieze wrote:
> What about also allowing the yyyy-mm-dd format (with or without hyphens). 
> Using English month names is not the most convenient for many people.

I would go as far as suggesting to make it a requirement to use an
ISO-8601 compliant UTC date string with a resolution of minutes.

$ date -u --iso-8601=minutes
2005-11-07T10:59+0000

This is international, standardized and easily parsable for both
humans and computers.

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

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

[gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

John Myers posted <200511062318.44284.electronerd@monolith3d.com>,
excerpted below,  on Sun, 06 Nov 2005 23:18:33 -0800:

> On Sunday 06 November 2005 13:38, Duncan wrote:
>> I don't believe the apache upgrade issues were announced on the announce 
>> list.   
> For the record, it was sent to the announce list on 2004-12-24.
> Message-Id: <200412240924.35397.stuart@gentoo.org>
> Subject: [gentoo-announce] Apache packages refresh on 8th January 2005

Thanks!  Glad it was me that forgot about it, and not an important
announcement that didn't happen!  =8^)

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 7 Nov 2005 09:41:04 +0100 Grobian <grobian@gentoo.org> wrote:
| Remember that there are packages in the tree that satisfy the
| preemptive requirement, since they simply die when trying to upgrade
| and a certain amount of prerequisites is not met.  This prevents the
| user from losing data files or making them inaccesible, while at the
| same pointing out what needs to be done and why, using a short
| message.

Yick! We really really really don't want to do that. A die in an ebuild
would ideally only be triggered for unexpected build errors caused by
things like the user running out of disk space. Getting hit by a die
on something you've left to run overnight is a real nuisance.

As it stands, we have a few unfortunate situations (built_with_use)
where it's currently necessary to do premeditated dies, but the aim is
to reduce these (eg by adding foo[bar] deps to portage), not add in
even more.

-- 
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 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 7 Nov 2005 11:50:22 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Saturday 05 November 2005 01:58, Ciaran McCreesh wrote:
| > ``Posted:``
| >     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
| > UTC time in ``hh-mm-ss +0000`` format may also be included. This
| > field is mandatory.
| 
| What about also allowing the yyyy-mm-dd format (with or without
| hyphens). Using English month names is not the most convenient for
| many people.

Runs contrary to GLEP 1... Guess I should back that one up with a
reference.

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

[gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Ciaran McCreesh posted <20051106214747.4e6a9cff@snowdrop.home>, excerpted
below,  on Sun, 06 Nov 2005 21:47:47 +0000:

> On Sun, 06 Nov 2005 14:38:47 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | While I agree with the point you make, I don't believe the apache
> | upgrade issues were announced on the announce list.  The news in the
> | tree thing is a good idea, IMO, but it'll take some time to
> | implement.  "Earth changing" (for some Gentoo users) announcements
> | can and should go to announce -- that's what it's there for.
> 
> Why should every user have to sign up to be spammed with irrelevant
> GLSAs and news items for packages which they do not use?

They shouldn't /have/ to, but the option is there.  Those who care about
security and care about getting a heads-up on "major" changes of this
nature, will find several opportunities to be notified of them.  The
announce list is one.  Lurking the dev list is another.  Reading GWN is a
third, and RSSing or regularly visiting the front page is yet another.

However, as I said, I agree with the point made, and believe something
like this "push" proposal is a /good/ thing.  I'm just not sure how much
I'd /personally/ prioritize it, given that there are plenty of information
sources for those that care, already.  That only means I'd find other
things of higher priority, but just the same, I'm glad /someone/ finds
doing it worthwhile, and I'll be /very/ glad to add it to my list of
information sources, when it eventually becomes available (notification
in depth, to modify a phrase). Until then, however, I'm just saying lets
make the best of what we have, and when there's an announcement of
something big happening, let's ensure it gets to the announce list, among
other places (as it apparently did in this case, I just forgot, as it was
old news already, since I'd seen it on the dev list, one of the reasons I
/read/ the dev list!).

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Mon, 2005-11-07 at 09:27 -0700, Duncan wrote:
> They shouldn't /have/ to, but the option is there.  Those who care about
> security and care about getting a heads-up on "major" changes of this
> nature, will find several opportunities to be notified of them.  

That's not the point behind the push for this approach.

I kicked this off in my blog article because we've used those
opportunities to notify users, and it didn't work well enough.  We've
had users and Gentoo developers alike who didn't know about the changes.
Add 'php' to your away logging, and sit in #gentoo-dev and
#gentoo-apache for a week or so, and make a count of the number of users
and devs who still don't know about the (delayed) PHP5 changes.

From my point of view, as a Gentoo developer pushing large
service-affecting changes out to users, our existing mechanisms are at
least a partial failure when it comes to getting the news out.

If you want a timely example, take a look at this week's GWN's
description of this debate, and see for yourself how it matches the
changes I've blogged about ;-)

> The announce list is one.  

By your own admission, you're on the announce list, and but you didn't
know about the Apache changes.  Imagine how many other users were in the
same situation.  Imagine how many other users never signed up to the
announce list in the first place.

We can sit here all day and blame those users for their actions, or lack
thereof.

Or, we can do better, and pro-actively put the news right in front of
them.  Even game systems like Steam already do this :)

> I'm just not sure how much
> I'd /personally/ prioritize it, given that there are plenty of information
> sources for those that care, already.

Take a moment to re-examine the argument from the viewpoint that the
existing information sources are not getting the news out to the people
that matter - our devs and our users.

From that point of view, this work is worth making a high priority.

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

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Stuart Herbert wrote:
> By your own admission, you're on the announce list, and but you didn't
> know about the Apache changes.  Imagine how many other users were in the
> same situation.  Imagine how many other users never signed up to the
> announce list in the first place.

On gentoo-dev, gentoo-user, gentoo-devel, gentoo-server and 
gentoo-web-user on 2005-09-08 01:48 UTC a message titled "Stabilization 
of new-style Apache" was posted.

Quoting John Myers:
> For the record, it was sent to the announce list on 2004-12-24.
> Message-Id: <200412240924.35397.stuart@gentoo.org>
> Subject: [gentoo-announce] Apache packages refresh on 8th January 2005

giving me the impression that the new-style apache changes were not 
announced (though they did cause some trouble), and that this message -- 
which unfortunately is not on Gmane, so I cannot check -- probably deals 
*not* with those new-style apache changes.  If it does, then it might be 
'badly timed'.

In the whole of 2005 I can see one message on gentoo-announce which is 
not a GLSA, which is a release announcement for Gentoo Linux 2005.0.

Considering the description of gentoo-announce "General Gentoo 
announcements list (new releases, security fixes)" perhaps this list 
might not the the right place for such **important** announcements as 
the new-style apache message.

However, suppose I was a normal user, and I would like to receive these 
messages, where should I sign up for?
gentoo-user?
   "General Gentoo user support and discussion mailing list" sounds like
    a lot of spam to me, and if I don't have questions myself, or prefer
    using the (excellent) forums for that, then why should I sign up for
    that?
gentoo-dev perhaps?
   "General Gentoo developer discussion mailing list" sounds like a lot
    of spam too, and certainly not as source for important messages from
    a user perspective.
gentoo-security?
   "For the discussion of security issues and fixes"  Well, as user I
    might only be interested in the announcement of security fixes,
    don't need discussions on them, and since I want those important
    messages about changes in gentoo psckages... nope, this is not it.
gentoo-gwn?
   "Gentoo Weekly Newsletter" well, might come in handy, doesn't say
    anything about what it does exactly and might contain a lot of
    noise considering what I'm looking for.
doc, doc-cvs, translator, ppc-user, ppc-dev, <arch>, kernel, laptop:
   not applicable
gentoo-desktop:
    might be, though not interested in window managers
<etc etc etc>
gentoo-server?
   "Discussions about Gentoo in production environments" ok, I don't need
   discussions, I just want messages on **important** changes.

After going through the list, I got the impression there is simply no 
place where such messages clearly would go.  gentoo-announce sounds as 
the best option to go for, but its description somehow suggests not. 
Though, subscribed to gentoo-announce means you get nothing but GLSA 
announcements and sometimes a new release announcements.

So, what list should the user that wants to receive those **important** 
messages sign up to?
I still think that *this* is the reason why people don't seem to know 
about the important changes, because there is no obvious place where to 
get them.  It's quite likely that a user that wanted to see the 
new-style apache message didn't see it because it simply didn't appear 
on a list the user hoped to see it.  It was in the GWN of 2005-09-12, 
but I can imagine a user didn't expect it to be there, as there is no 
description at al for GWN list, and the **important** information will 
always have to be extracted from the GWN, since each GWN covers multiple 
items in a few categories which not every user might interest.

Send **important** messages separate to a non-discussion mailing list, 
and I'm sure that many people will be happy to read it -- just like 
gentoo-announce.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 07 Nov 2005 19:32:38 +0100 Grobian <grobian@gentoo.org> wrote:
| So, what list should the user that wants to receive those
| **important** messages sign up to?

That's your first misconception right there. Most users don't sign up
for things.

-- 
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] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Daniel Ostrow]

[snip]

> After going through the list, I got the impression there is simply no 
> place where such messages clearly would go.  gentoo-announce sounds as 
> the best option to go for, but its description somehow suggests not. 
> Though, subscribed to gentoo-announce means you get nothing but GLSA 
> announcements and sometimes a new release announcements.
> 
> So, what list should the user that wants to receive those **important** 
> messages sign up to?
> I still think that *this* is the reason why people don't seem to know 
> about the important changes, because there is no obvious place where to 
> get them.  It's quite likely that a user that wanted to see the 
> new-style apache message didn't see it because it simply didn't appear 
> on a list the user hoped to see it.  It was in the GWN of 2005-09-12, 
> but I can imagine a user didn't expect it to be there, as there is no 
> description at al for GWN list, and the **important** information will 
> always have to be extracted from the GWN, since each GWN covers multiple 
> items in a few categories which not every user might interest.
> 
> Send **important** messages separate to a non-discussion mailing list, 
> and I'm sure that many people will be happy to read it -- just like 
> gentoo-announce.

[/snip]

Above and beyond Ciaran's point...

You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already "signed up" for something that can track and filter, portage.

I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org
-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Daniel Ostrow]

[snip]

> After going through the list, I got the impression there is simply no 
> place where such messages clearly would go.  gentoo-announce sounds as 
> the best option to go for, but its description somehow suggests not. 
> Though, subscribed to gentoo-announce means you get nothing but GLSA 
> announcements and sometimes a new release announcements.
> 
> So, what list should the user that wants to receive those **important** 
> messages sign up to?
> I still think that *this* is the reason why people don't seem to know 
> about the important changes, because there is no obvious place where to 
> get them.  It's quite likely that a user that wanted to see the 
> new-style apache message didn't see it because it simply didn't appear 
> on a list the user hoped to see it.  It was in the GWN of 2005-09-12, 
> but I can imagine a user didn't expect it to be there, as there is no 
> description at al for GWN list, and the **important** information will 
> always have to be extracted from the GWN, since each GWN covers multiple 
> items in a few categories which not every user might interest.
> 
> Send **important** messages separate to a non-discussion mailing list, 
> and I'm sure that many people will be happy to read it -- just like 
> gentoo-announce.

[/snip]

Above and beyond Ciaran's point...

You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already "signed up" for something that can track and filter, portage.

I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Ciaran McCreesh wrote:
> On Mon, 07 Nov 2005 19:32:38 +0100 Grobian <grobian@gentoo.org> wrote:
> | So, what list should the user that wants to receive those
> | **important** messages sign up to?
> 
> That's your first misconception right there. Most users don't sign up
> for things.

Doesn't matter.  If the important messages aren't posted or you have to 
extract them yourself the effect is the same.

Besides that, I see no arguments why users don't.  No proof either.

Forcing a push-based method on someone who likes pull-based methods is 
evil.  The least you can do to make everybody happy, is allow pull-based 
access to the important news items, and devote some more words on how to 
disable your 'feature'.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Daniel Ostrow]

On Mon, 2005-11-07 at 14:02 -0500, Daniel Ostrow wrote:
> [snip]
> 
> > After going through the list, I got the impression there is simply no 
> > place where such messages clearly would go.  gentoo-announce sounds as 
> > the best option to go for, but its description somehow suggests not. 
> > Though, subscribed to gentoo-announce means you get nothing but GLSA 
> > announcements and sometimes a new release announcements.
> > 
> > So, what list should the user that wants to receive those **important** 
> > messages sign up to?
> > I still think that *this* is the reason why people don't seem to know 
> > about the important changes, because there is no obvious place where to 
> > get them.  It's quite likely that a user that wanted to see the 
> > new-style apache message didn't see it because it simply didn't appear 
> > on a list the user hoped to see it.  It was in the GWN of 2005-09-12, 
> > but I can imagine a user didn't expect it to be there, as there is no 
> > description at al for GWN list, and the **important** information will 
> > always have to be extracted from the GWN, since each GWN covers multiple 
> > items in a few categories which not every user might interest.
> > 
> > Send **important** messages separate to a non-discussion mailing list, 
> > and I'm sure that many people will be happy to read it -- just like 
> > gentoo-announce.
> 
> [/snip]
> 
> Above and beyond Ciaran's point...
> 
> You are correct, there is no clear cut place for them to go...that's how
> this thing got started in the first place. However why force users to
> sign up for something which can't be appropriately filtered (installed
> packages, keywords, use flags, profiles, etc.) when all of them are
> already "signed up" for something that can track and filter, portage.
> 
> I wouldn't necessarily bother signing up for an errata list if said list
> was going to provide me with *all* the errata out there. The reason that
> a mailing list works for RedHat is because RHN tracks what packages you
> have installed on your system on *their* server (again something you
> have to sign up for, and worse send them info about your configuration),
> so the filtering is done for you. We will *never* do something like
> this, we have a client side tool that can identify what is installed
> already...why not use it?

Err...sorry for the double post...mail client error.

Oh...and before anyone goes nuts...note I said "why force users to sign
up" to such a list *not* "we will not provide such a list".

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 07 Nov 2005 20:11:23 +0100 Grobian <grobian@gentoo.org> wrote:
| Besides that, I see no arguments why users don't.  No proof either.

Have a look at how amazingly well certain recent upgrades have gone...

| Forcing a push-based method on someone who likes pull-based methods
| is evil.  The least you can do to make everybody happy, is allow
| pull-based access to the important news items, and devote some more
| words on how to disable your 'feature'.

Why does it need more words? It already has a sentence, and that's all
that's needed.

-- 
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 42 "Critical News Reporting" Round Two

[Grobian]

Daniel Ostrow wrote:
>> You are correct, there is no clear cut place for them to go...that's how
>> this thing got started in the first place. However why force users to
>> sign up for something which can't be appropriately filtered (installed
>> packages, keywords, use flags, profiles, etc.) when all of them are
>> already "signed up" for something that can track and filter, portage.
>>
>> I wouldn't necessarily bother signing up for an errata list if said list
>> was going to provide me with *all* the errata out there. The reason that
>> a mailing list works for RedHat is because RHN tracks what packages you
>> have installed on your system on *their* server (again something you
>> have to sign up for, and worse send them info about your configuration),
>> so the filtering is done for you. We will *never* do something like
>> this, we have a client side tool that can identify what is installed
>> already...why not use it?

What if an admin just wants to see all errata messages because (s)he
doesn't feel like aggregating the unique messages from a whole cluster
of machines running Gentoo with all different packages installed?

It is a well-known fact that removing seemingly useless background noise
can cause relations between problems not to be recognised.  Some users
know that and hence would like to see all errata.

Our GLSAs are sent out exactly in the same way, but there is not a word 
on them in the GLEP, neither does anyone seem to care about them, while 
they seem to me at least ***VERY*** important, that is, much more 
important than a message about breaking my installation.  And they 
aren't even personalised!

Users don't care about security[1], adminstrators do.
Administrators don't care about breaking installations[2], users do.

About the RHN subscription thing, that service is IMHO quite expensive
(certainly not free) and not available to Fedora Core users.  I don't 
think you _want_ to compare Gentoo Linux Free support to support 
provided by commercial entities for an annual membership fee.


The issue whether news or GLSAs are important and whether they can be 
read or not is of relevance with regard to the motivation of the GLEP 
which assumes it doesn't work for anybody, while I claim it 1) doesn't 
work because the information is hard to find and 2) it will work for a 
certain group of people very well if the information would be there.

To conclude my far too lengthy replies here:
I'd like to see some recognition that the world isn't that flat as the 
GLEP suggests, thereby including opportunities for everyone to be happy 
with the GLEP.  I already stated this in my first reply in my part on 
"use-scenarios".

Don't worry I'll shut up now as there is clearly no interest for a bit 
broader thinking.


[1] (linux) desktop users are of a much lower target than big companies 
for security exploits
[2] administrators try out package upgrades on a spare box first, users 
usually don't have such box, or risk the potential impact


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Philip Webb]

051107 Ciaran McCreesh wrote:
> 7 Nov 2005 11:50:22 +0100 Paul de Vrieze <pauldv@gentoo.org> wrote:
>> On Saturday 05 November 2005 01:58, Ciaran McCreesh wrote:
>>> ``Posted:``
>>>     Date of posting, in ``dd-mmm-yyyy`` format (e.g. 14-Aug-2001).
>>> UTC time in ``hh-mm-ss +0000`` format may also be included. This
>>> field is mandatory.
>> What about also allowing the yyyy-mm-dd format (with or without hyphens).
>> Using English month names is not the most convenient for many people.
> Runs contrary to GLEP 1.
> Guess I should back that one up with a reference.

Maybe it's time for GLEP 43 :

  " blah blah ...
  Gentoo date formats shall always correspond to the international standard,
  ie be in the form 'yyyy-mm-dd'
  blah blah ... "

I'm serious -- Gentoo should try to follow international standards -- ,
but have a (smile) to recognise it's a small point.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Jakub Moc]

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


7.11.2005, 20:11:23, Grobian wrote:

> Ciaran McCreesh wrote:
>> On Mon, 07 Nov 2005 19:32:38 +0100 Grobian <grobian@gentoo.org> wrote:
>> | So, what list should the user that wants to receive those
>> | **important** messages sign up to?
>> 
>> That's your first misconception right there. Most users don't sign up
>> for things.

> Doesn't matter.  If the important messages aren't posted or you have to 
> extract them yourself the effect is the same.

> Besides that, I see no arguments why users don't.  No proof either.

OK, I'd really suggest you join #gentoo-apache for a week, if you want some
proof. Browsing forums.g.o. rants wrt the Apache layout changes is also helpful in
this respect. ;p


--
Jakub

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 07 Nov 2005 21:10:35 +0100 Grobian <grobian@gentoo.org> wrote:
| It is a well-known fact that removing seemingly useless background
| noise can cause relations between problems not to be recognised.
| Some users know that and hence would like to see all errata.

And, conveniently enough, the GLEP sticks all the news items (errata is
a bad choice of word, since we don't have a single release against
which we make corrections) in a single place.

| Our GLSAs are sent out exactly in the same way, but there is not a
| word on them in the GLEP, neither does anyone seem to care about
| them, while they seem to me at least ***VERY*** important, that is,
| much more important than a message about breaking my installation.

Yes, because it's better to have a system which is immune to denial of
service attacks from local users who all have physical access to the
system than one which actually works. Riiiiight.

-- 
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 42 "Critical News Reporting" Round Two

[Jan Kundrát]

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

On Monday 07 of November 2005 21:10 Grobian wrote:
> Our GLSAs are sent out exactly in the same way, but there is not a word
> on them in the GLEP, neither does anyone seem to care about them, while
> they seem to me at least ***VERY*** important, that is, much more
> important than a message about breaking my installation.  And they
> aren't even personalised!

Are you sure about that? See glsa-integration [1] and `glsa-check` manpage 
[2].

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

WKR,
-jkt

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

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Jan Kundrát]

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

On Monday 07 of November 2005 21:12 Philip Webb wrote:
> 051107 Ciaran McCreesh wrote:
> I'm serious -- Gentoo should try to follow international standards -- ,
> but have a (smile) to recognise it's a small point.

See the first line of the quotation :-P

Cheers,
-jkt

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

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Mon, 7 Nov 2005 15:12:20 -0500 Philip Webb <purslow@sympatico.ca>
wrote:
| I'm serious -- Gentoo should try to follow international standards

The format specified in GLEP 1 is an international standard. It's just
not the same international standard that you're after.

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

[gentoo-dev] Re: Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Stuart Herbert posted <1131382994.8546.34.camel@mogheiden.gnqs.org>,
excerpted below,  on Mon, 07 Nov 2005 17:03:14 +0000:

>> The announce list is one.  
> 
> By your own admission, you're on the announce list, and but you didn't
> know about the Apache changes.  Imagine how many other users were in the
> same situation.  Imagine how many other users never signed up to the
> announce list in the first place.

I guess I wasn't quite clear, then.  Yes, I KNEW about the changes, from
several sources.  The first source I knew about them from was here, I
believe, seeing the earlier discussion.  Because of that, it was old news
by the time I saw it on announce and I wasn't sure I'd seen it there
because I'd lost track of all the locations and threads I'd seen it in by
then.

I wasn't sure it was on announce, not because I didn't see it there, but
because it was old news by then.  Actually, from my perspective, that's a
/good/ thing, because one of the reasons I'm subscribed here is to get as
early a heads-up on things as possible.  The news SHOULD go to announce
and it did (tho I hadn't been sure of it in that case), but by definition,
before it gets announced, it will need discussed, and likely as not, at
least mention of that discussion will be seen here, well ahead of it
actually happening or appearing on announce or on the news thing.

Then seeing it on announce would jog my memory, if necessary, and remind
me of the decision made, as sometimes the discussion here remains up in
the air and I don't know the decision until later.  (That's normal, not a
bad thing.)

Then seeing it in emerge would be another warning (for me), just in case
I'd slept thru things, and to jog my memory once more.  For me, and for
those that care, that's all it should be, another warning, thus I'd call
it fairly low priority.  However, it's still good to have, and for those
that don't care enough to go looking elsewhere, it might be the first
warning they get.  I personally wouldn't want to operate that way, nor
could I imagine doing so, but I realize the point made that obviously,
others are missing all the warning signs and seeing it there might  be the
last warning that does some good.  That's a GOOD thing!  It's just not
personally good enough that I'd prioritize it real heavily, but it's still
a good thing to have, so I won't argue with OTHERS prioritizing it. =8^)

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Philip Webb]

051107 Ciaran McCreesh wrote:
> 7 Nov 2005 15:12:20 -0500 Philip Webb <purslow@sympatico.ca> wrote:
>> I'm serious -- Gentoo should try to follow international standards
> The format specified in GLEP 1 is an international standard.
> It's just not the same international standard that you're after.

I'm not sure how it can be an international standard
when it uses an English abbreviation 'Aug' for the month (raised eyebrow),
but as someone said: "I love standards: there are so many to choose from".

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Dan Meltzer]

An internation standard that utilizes an international language... hrm

On 11/7/05, Philip Webb <purslow@sympatico.ca> wrote:
> 051107 Ciaran McCreesh wrote:
> > 7 Nov 2005 15:12:20 -0500 Philip Webb <purslow@sympatico.ca> wrote:
> >> I'm serious -- Gentoo should try to follow international standards
> > The format specified in GLEP 1 is an international standard.
> > It's just not the same international standard that you're after.
>
> I'm not sure how it can be an international standard
> when it uses an English abbreviation 'Aug' for the month (raised eyebrow),
> but as someone said: "I love standards: there are so many to choose from".
>
> --
> ========================,,============================================
> SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
> ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
> TRANSIT    `-O----------O---'  University of Toronto
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Mon, 2005-11-07 at 20:11 +0100, Grobian wrote:
> Ciaran McCreesh wrote:
> > That's your first misconception right there. Most users don't sign up
> > for things.
> 
> Doesn't matter.

I think it does.  I believe that is the root cause of our difficulty in
getting news to our users.  We rely on our users coming to us to find
the news.  If they don't do that, they don't get the news.

Our aim is to put the news in front of 100% of our userbase.  Not the
small fractions who check each of the places where news is currently
published.

> Besides that, I see no arguments why users don't.  No proof either.

No proof?!?  

Did you read the original blog posting which kicked this off?  Or the
thread in the forums where our users claim the Apache upgrade was a
surprise - even though this was a well-trailed change?  That's just one
change.

I don't understand the problem from your point of view.  No, scratch
that.  I don't understand your point of view.  You're coming across to
me as someone who doesn't believe there's a problem that needs solving.

I'm tempted to forcibly co-opt you into the PHP team before we put
dev-lang/php live.  This would allow you to experience the situation for
yourself.  Maybe that would give you another perspective? ;-)

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Mon, 2005-11-07 at 21:10 +0100, Grobian wrote:
> Users don't care about security[1], adminstrators do.
> Administrators don't care about breaking installations[2], users do.

That's the problem with sweeping generalisations .... they're just too
general to be of any value in a discussion.

> while I claim it 1) doesn't 
> work because the information is hard to find and 2) it will work for a 
> certain group of people very well if the information would be there.

I agree with 1) ... in fact, it's mentioned in the blog entry that
kicked all of this off.

But your second claim ... 

I personally don't care about trying target and satisfy a "certain group
of people".  I really don't.  I'm after 100% of the userbase.  Nothing
less is fit for purpose.  I'm not interested in small fractionals in
this case.  And especially not *only* small fractionals.

You don't seem to share this aim.  To me, you're coming across as
wanting the news delivered to your exact personal preferences only, with
no regard for the wider issue or what may be best for the Gentoo project
and especially our userbase as a whole.

My personal conclusion was that there is only one place where we can
have any degree of certainty that we have the attention of 100% of the
userbase - or as near as damn it.  I believe that place is right beneath
the message that tells the user they have CONFIG_PROTECTED files that
need updating.

Hence emerge --news.

If you have found *one* place where we are even more likely to have the
attention of 100% of the userbase, please share it with us.  If there's
a better place, we should use that instead, and I will very happily
support it.

If we can put something together that takes the news available through
emerge --news, and pushes it out via other places (web, mailing lists,
whatever), I have no real problem with that.  

But I think that there is a very good reason why it needs to come later,
why now is *not* the time.

We need to establish *one* authoritative source of news.  We can't do
that if we simultaneously launch several sources of news all at once.
We have to launch *one* service first, give the userbase time to adjust
to that, and then start making the news available via additional
sources.

> Don't worry I'll shut up now as there is clearly no interest for a bit 
> broader thinking.

I find your thinking anything but broad on this topic.

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Sat, 2005-11-05 at 00:58 +0000, Ciaran McCreesh wrote:
> Feedback from people who have something useful to say would be very much
> welcomed, assuming of course that they've read the GLEP.

Apologies if this has already been picked up by someone else in this
monster thread ;-)

Should the GLEP explain how Portage will know how many unread news items
there are in /var/lib/gentoo/news?  I couldn't spot where this is
covered in the text, or in the example code.

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Thu, 10 Nov 2005 23:12:28 +0000 Stuart Herbert <stuart@gentoo.org>
wrote:
| Should the GLEP explain how Portage will know how many unread news
| items there are in /var/lib/gentoo/news?  I couldn't spot where this
| is covered in the text, or in the example code.

Well, I was going to go with the plain but simple "once you've read it,
delete it" approach, but some people didn't like that. Next draft will
propose being able to append .read to a filename to mark it read
without deleting it. Either way, it's just a case of looking
for ????-??-??-*.??.txt, chopping off the .??.txt, removing duplicates
and counting.

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Mike Owen]

On 11/10/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Thu, 10 Nov 2005 23:12:28 +0000 Stuart Herbert <stuart@gentoo.org>
> wrote:
> | Should the GLEP explain how Portage will know how many unread news
> | items there are in /var/lib/gentoo/news?  I couldn't spot where this
> | is covered in the text, or in the example code.
>
> Well, I was going to go with the plain but simple "once you've read it,
> delete it" approach, but some people didn't like that. Next draft will
> propose being able to append .read to a filename to mark it read
> without deleting it. Either way, it's just a case of looking
> for ????-??-??-*.??.txt, chopping off the .??.txt, removing duplicates
> and counting.
>


What about something like "/etc/portage/news.read", which contains a
single news file per line. Perhaps have support for something like
"<=2006-01-01" in order to be able to manually mark date ranges as
read.

HTH,
Mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen <kyphros@gmail.com> wrote:
| What about something like "/etc/portage/news.read", which contains a
| single news file per line. Perhaps have support for something like
| "<=2006-01-01" in order to be able to manually mark date ranges as
| read.

Eh, yet another file. No real need for it really, it just adds
complexity.

Besides, /etc isn't for program-generated data.

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen <kyphros@gmail.com> wrote:
> | What about something like "/etc/portage/news.read", which contains a
> | single news file per line. Perhaps have support for something like
> | "<=2006-01-01" in order to be able to manually mark date ranges as
> | read.
> 
> Eh, yet another file. No real need for it really, it just adds
> complexity.
> 
> Besides, /etc isn't for program-generated data.
> 

Modify anything within PORTDIR is wrong.

I'd put a /var/db/news and a /etc/portage/news to handle that.

Which should be a reasonable timeframe for the news to stay?

Till the next gentoo release?

lu

-- 

Luca Barbato

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Dan Meltzer]

Forever.

Gentoo releases mean absolutely nothing, they do absolutely nothing.

The news should stay until the upgrade occurs

On 11/10/05, Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen <kyphros@gmail.com> wrote:
> > | What about something like "/etc/portage/news.read", which contains a
> > | single news file per line. Perhaps have support for something like
> > | "<=2006-01-01" in order to be able to manually mark date ranges as
> > | read.
> >
> > Eh, yet another file. No real need for it really, it just adds
> > complexity.
> >
> > Besides, /etc isn't for program-generated data.
> >
>
> Modify anything within PORTDIR is wrong.
>
> I'd put a /var/db/news and a /etc/portage/news to handle that.
>
> Which should be a reasonable timeframe for the news to stay?
>
> Till the next gentoo release?
>
> lu
>
> --
>
> Luca Barbato
>
> Gentoo/linux Developer          Gentoo/PPC Operational Leader
> http://dev.gentoo.org/~lu_zero
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Luca Barbato]

Dan Meltzer wrote:
> Forever.

Too long for the not infinite space in the server/mirror

> 
> Gentoo releases mean absolutely nothing, they do absolutely nothing.
> 
Beside adding some profiles, deprecating and removing others, provide an 
updated installation media...


> The news should stay until the upgrade occurs
> 

If they are delivered by portage they will be rsynced back to their 
original form. I guess that the news could be removed as we do for the 
ebuilds. (in this case about once the versions related to the news got 
removed more or less).

lu


-- 

Luca Barbato

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Grobian]

On 10-11-2005 20:55:37 +0000, Stuart Herbert wrote:

Ok, you want a reaction, because you are Feeling Blue[1], right.

> On Mon, 2005-11-07 at 20:11 +0100, Grobian wrote:
> > Ciaran McCreesh wrote:
> > > That's your first misconception right there. Most users don't sign up
> > > for things.
> > 
> > Doesn't matter.
> 
> I think it does.  I believe that is the root cause of our difficulty in
> getting news to our users.  We rely on our users coming to us to find
> the news.  If they don't do that, they don't get the news.
> 
> Our aim is to put the news in front of 100% of our userbase.  Not the
> small fractions who check each of the places where news is currently
> published.

You describe here (and in your diary) the aim to reach 100% of our user
base.  Wow, nice thing.  Discussions on whether you will succeed or not,
are out of the question right now, it's just your aim.  Good.  I hope
you will succeed!

> > Besides that, I see no arguments why users don't.  No proof either.
> 
> No proof?!?  
> 
> Did you read the original blog posting which kicked this off?  Or the
> thread in the forums where our users claim the Apache upgrade was a
> surprise - even though this was a well-trailed change?  That's just one
> change.

I scoured the forums a bit and looked what users were telling.  I wasn't
surprised.  What do you expect from a user telling it all doesn't work
any more, who doesn't run etc-update just because "after every emerge
--upgrade --world it has over 100 files to update"?  Such user just
ignores the importance of the tool, and will most certainly ignore
anything else that we try to help this user.  This was just one example.

It is a very humble attempt to try and help these users, but they simply
chose the wrong Linux distro, because Gentoo expects you to be an system
administrator, not a user.  At least that's my vision on it.  I think we
can agree that Gentoo requires a user to know/realise more than a
Fedora/SuSe/Ubuntu user.

> I don't understand the problem from your point of view.  No, scratch
> that.  I don't understand your point of view.  You're coming across to
> me as someone who doesn't believe there's a problem that needs solving.

I am just in the opinion that we lack a system where users can find the
information they need.  That would help a certain type of users,
absolutely not all of them.  So yes, after that, this problem needs
solving, perhaps.  Personalisation using portage is a sweet thing!
Here comes the point where I can express my doubt about the 100%.  There
are unfortunately users who are too hard to help, if you get what I
mean.

> I'm tempted to forcibly co-opt you into the PHP team before we put
> dev-lang/php live.  This would allow you to experience the situation for
> yourself.  Maybe that would give you another perspective? ;-)

Might be a very good excercise for me (and you?).  As you might guess
from my comment above, I simply think _communication_ is the big
problem, as I see being a problem in many places around here.  Not that
perfect communication solves the problem entirely, but it allows to
reply in the sense of 'rtfw'.
If you're serious here, feel free to contact me (off-list) to see what
we can arrange.


[1] http://stu.gnqs.org/diary/gentoo.php/2005/11/10/feeling_blue

-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

On 10-11-2005 21:33:48 +0000, Stuart Herbert wrote:
> We need to establish *one* authoritative source of news.  We can't do
> that if we simultaneously launch several sources of news all at once.
> We have to launch *one* service first, give the userbase time to adjust
> to that, and then start making the news available via additional
> sources.

Yep, so create that central source on the web, and fork off mailing list
posts, RSS-feeds and stuff based on this central repository.  Also let
portage warn users based on the information in this repository.
We can start creating and populating the central web resource _right
now_, as all the infrastructure is there.  The mailing lists shouldn't
be a problem as well.  It all makes sense...

... as long as you include the right handles for users to adjust their
preferences.  You missed my point here, when I was just trying to
indicate that in our user base, there will be many different users.
Different users as in different preferences.  Forcing the portage
solution, the mailing list solution, or which other solution upon a user
is evil.  People should be *free* to choose.  That you define a default
setting of enabling the portage feature is fine with me, but include
clear directions to disable such feature and allow it to send mails if
the possible infrastructure is there and the user wants it.  Take all
preferences into account.

I don't see why you would want to achieve your 100% user coverage aim
through only *one* channel.  I am strongly in favour of using multiple
channels to do that.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Marius Mauch]

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

On Fri, 11 Nov 2005 10:19:15 +0100
Grobian <grobian@gentoo.org> wrote:

> On 10-11-2005 21:33:48 +0000, Stuart Herbert wrote:
> > We need to establish *one* authoritative source of news.  We can't
> > do that if we simultaneously launch several sources of news all at
> > once. We have to launch *one* service first, give the userbase time
> > to adjust to that, and then start making the news available via
> > additional sources.
> 
> Yep, so create that central source on the web, and fork off mailing
> list posts, RSS-feeds and stuff based on this central repository.
> Also let portage warn users based on the information in this
> repository. We can start creating and populating the central web
> resource _right now_, as all the infrastructure is there.  The
> mailing lists shouldn't be a problem as well.  It all makes sense...

No, the central repository certainly shouldn't be on the web (whatever
that means in the first place), it has to be somewhere in CVS
(easily accessible by all devs, though not necessarily in a direct way)
and should be replicated to as many channels as possible (the website
being one of them).

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: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

On 11-11-2005 10:38:43 +0100, Marius Mauch wrote:
> No, the central repository certainly shouldn't be on the web (whatever
> that means in the first place), it has to be somewhere in CVS
> (easily accessible by all devs, though not necessarily in a direct way)
> and should be replicated to as many channels as possible (the website
> being one of them).

Agreed.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Benno Schulenberg]

Ciaran McCreesh wrote:
> Next draft will propose being able to append .read to a filename
> to mark it read without deleting it.

But don't use ".read", as it can be understood as both present tense 
(imperative) and past tense.  Better use something like ".seen".

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

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Tres Melton]

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

On Fri, 2005-11-11 at 10:03 +0100, Grobian wrote:
> On 10-11-2005 20:55:37 +0000, Stuart Herbert wrote:
> 

> I am just in the opinion that we lack a system where users can find the
> information they need.  That would help a certain type of users,
> absolutely not all of them.  So yes, after that, this problem needs
> solving, perhaps.  Personalisation using portage is a sweet thing!
> Here comes the point where I can express my doubt about the 100%.  There
> are unfortunately users who are too hard to help, if you get what I
> mean.
> 
I think putting the information in front of the users eyes is all that
can be asked.  If they choose to ignore it there is nothing that we can
do.  This proposal will accomplish that and at that point we can tell
Ciaran "Goob Job".  Same for the config updates that you mentioned
above.

> -- 
> Fabian Groffen
> Gentoo for Mac OS X Project -- Interim Lead
-- 
Tres Melton
IRC & Gentoo: RiverRat

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

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Benno Schulenberg posted <200511111228.17440.benno@nietvergeten.nl>,
excerpted below,  on Fri, 11 Nov 2005 12:28:17 +0100:

> Ciaran McCreesh wrote:
>> Next draft will propose being able to append .read to a filename
>> to mark it read without deleting it.
> 
> But don't use ".read", as it can be understood as both present tense 
> (imperative) and past tense.  Better use something like ".seen".

What about using two local dirs, with symlinks from them to the files
in the main news repository in the tree?

Perhaps $PORTDIR/news, with seen and unseen subdirs (and appropriate
no-sync settings on the subdirs)  The post sync process can scan for
applicable news items, then check in the seen subdir to see if there's a
symlink there already.  If not, it can place a symlink in the unseen
subdir.

The unseen subdir need not be checked as the create-symlink function can
simply ignore create errors, or overwrite, if one or the other is more
efficient than actually checking before attempting the create.

If a user wishes to mark everything seen, they simply move the symlinks to
the other subdir.

A third mode for eclean can be created, that cleans out all the stale
symlinks in seen and unseen, thereby eliminating the need for portage to
worry about cleaning them out at sync, so it must only manage adding new
ones.

As with distdir and packagedir, make.conf should have a variable
controlling the location of newsdir.

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Paul de Vrieze]

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

On Friday 11 November 2005 00:35, Ciaran McCreesh wrote:
> On Thu, 10 Nov 2005 23:12:28 +0000 Stuart Herbert <stuart@gentoo.org>
>
> wrote:
> | Should the GLEP explain how Portage will know how many unread news
> | items there are in /var/lib/gentoo/news?  I couldn't spot where this
> | is covered in the text, or in the example code.
>
> Well, I was going to go with the plain but simple "once you've read it,
> delete it" approach, but some people didn't like that. Next draft will
> propose being able to append .read to a filename to mark it read
> without deleting it. Either way, it's just a case of looking
> for ????-??-??-*.??.txt, chopping off the .??.txt, removing duplicates
> and counting.

If you don't delete it, we might still have a supersedes header that 
indicates that one news item overrides another one. This would also be 
useful for a web version that contains a full archive of all news items.

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 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Thu, 2005-11-10 at 21:33 +0000, Stuart Herbert wrote:
> My personal conclusion was that there is only one place where we can
> have any degree of certainty that we have the attention of 100% of the
> userbase - or as near as damn it.  I believe that place is right beneath
> the message that tells the user they have CONFIG_PROTECTED files that
> need updating.

I agree that portage should have some way of showing the number of news
items.

> Hence emerge --news.

Why?

There's no "emerge --etc" or "emerge --etc-update" functionality.  Why
must it be "emerge --news" at all?

I think this would completely remove the "portage as a news reader"
problem entirely.  Portage would check a directory for news items.  The
news reader would take care of them after this.  Portage would do
nothing more than look at the directory for unread news items and
display that number.

> If you have found *one* place where we are even more likely to have the
> attention of 100% of the userbase, please share it with us.  If there's
> a better place, we should use that instead, and I will very happily
> support it.

I agree that we should have news delivered by emerge --sync.  I also
think that we should increase the placement of important information on
our site, gentoo-announce, and the forums.  It is my personal opinion
that we should put the news out on as many mediums as possible.

> If we can put something together that takes the news available through
> emerge --news, and pushes it out via other places (web, mailing lists,
> whatever), I have no real problem with that.

I think this should be a requirement.

> But I think that there is a very good reason why it needs to come later,
> why now is *not* the time.

Ehh...

> We need to establish *one* authoritative source of news.  We can't do
> that if we simultaneously launch several sources of news all at once.
> We have to launch *one* service first, give the userbase time to adjust
> to that, and then start making the news available via additional
> sources.

No, we really don't.  Our users aren't idiots.  They just aren't reading
the information presented to them.  While I agree that we need to have a
single location for news, I also think that we must *require* this
information be present in other locations.  The main reason for this is
that "emerge --news" is filtered based on the packages installed on the
system.  What about administrators that have lots of different systems?
To them, it might be easier to receive all of the news, via
gentoo-announce, and filter them via their own methods to determine what
is important to them.  Perhaps I want to search for an old news item.
Why shouldn't I be able to go to a web site and enter my query in a
search box and get all of the major news updates to dev-lang/php?

If you want to reach 100% of the user base, then we should make this
useful for as many situations as possible.  I know that with the number
of machines that I administer, it would be much easier for me to get
*all* of the news in one place and determine what is valid for my
machines, rather than having to read them on each individual machine
based on the packages installed.

> > Don't worry I'll shut up now as there is clearly no interest for a bit 
> > broader thinking.
> 
> I find your thinking anything but broad on this topic.

*cough*

Pot.  This is kettle.

*grin*

-- 
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 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Fri, 2005-11-11 at 04:52 +0100, Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen <kyphros@gmail.com> wrote:
> > | What about something like "/etc/portage/news.read", which contains a
> > | single news file per line. Perhaps have support for something like
> > | "<=2006-01-01" in order to be able to manually mark date ranges as
> > | read.
> > 
> > Eh, yet another file. No real need for it really, it just adds
> > complexity.
> > 
> > Besides, /etc isn't for program-generated data.
> > 
> 
> Modify anything within PORTDIR is wrong.
> 
> I'd put a /var/db/news and a /etc/portage/news to handle that.
> 
> Which should be a reasonable timeframe for the news to stay?

Until deleted.

> Till the next gentoo release?

I'd prefer the news reader have both read and delete options.  I also
think we would need a searchable archive of all news items.  I'd really
prefer it was a web page, rather than trying to search a mailing list
archive.

-- 
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 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Fri, 2005-11-11 at 10:38 +0100, Marius Mauch wrote:
> On Fri, 11 Nov 2005 10:19:15 +0100
> Grobian <grobian@gentoo.org> wrote:
> 
> > On 10-11-2005 21:33:48 +0000, Stuart Herbert wrote:
> > > We need to establish *one* authoritative source of news.  We can't
> > > do that if we simultaneously launch several sources of news all at
> > > once. We have to launch *one* service first, give the userbase time
> > > to adjust to that, and then start making the news available via
> > > additional sources.
> > 
> > Yep, so create that central source on the web, and fork off mailing
> > list posts, RSS-feeds and stuff based on this central repository.
> > Also let portage warn users based on the information in this
> > repository. We can start creating and populating the central web
> > resource _right now_, as all the infrastructure is there.  The
> > mailing lists shouldn't be a problem as well.  It all makes sense...
> 
> No, the central repository certainly shouldn't be on the web (whatever
> that means in the first place), it has to be somewhere in CVS
> (easily accessible by all devs, though not necessarily in a direct way)
> and should be replicated to as many channels as possible (the website
> being one of them).

How about gentoo/news in CVS?

-- 
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 42 "Critical News Reporting" Round Two

[Marius Mauch]

On Sat, 5 Nov 2005 00:58:14 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> Feedback from people who have something useful to say would be very
> much welcomed, assuming of course that they've read the GLEP.

Things that I think are generally ok as is:
- news item format
- news item distribution (server side)

Things that I'd like to be changed/I'm not completely sure about:
- filtering of news items:
  I've already asked a similar question in another mail (in other
context) without an answer, but how many news items do people believe
will exist at any given time? Depending on the actual implementation it
might be required to scan all existing news items which could take some
time if there is a large number of them (say, more than a few hundred)
It's clear that noone can present accurate numbers, just after some
rough estimates here.
Also it might be useful for this filtering to be an external tool using
portage functions and called by portage (see also below). Although this
could be considered an implementation detail as it's mostly transparent
for ebuild devs/users.

- local storage of news items / "read" attribute:
  I don't really the like the copy-if-new feature and handling at the fs
level, I'd use a file that lists the ids of news items (potentially
with a timestamp and/or status field). I don't see any benefits of
having redundancy here, and accessing the news in $PORTDIR is simple
enough. Granted race conditions might be an issue (where the solution
complicates tools), but that's so minor I wouldn't really care about
it. 
Another thing that's unclear: "Whenever relevant unread news items are
found, emerge will copy or symlink the news file into
/var/lib/gentoo/news/." 
This "Whenever ... are found" is too vague, should this apply to emerge
--sync, any emerge operation, any "import portage" call or what? This
isn't just an implementation detail. 
PS: I'd avoid symlinks here at all costs, too easy to break them. 
Also as Brian and Jason have said already, the system should be able to
handle multiple repositories. So to use the current GLEP as example, at
least the path should be changed to /var/lib/gentoo/news/porttree

- quality control:
"Any complaints regarding wording or clarity must be addressed before
the news item goes live." Playing devils advocate here, but complaints
regarding correctness are not mandatory to be adressed?
As for using -core, please add a small explanation or at least a
reference to the appropriate policy docs (and please save the comments
about GuideXML uris ;)

Things that should definitely be changed:
- Integration with existing systems:
This definitely should be a requirement for the GLEP to be considered
final. It doesn't prevent some thing being implemented sooner than
others, but multi-channel distribution (to use a buzzword) is a
requirement from where I come from.

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.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Fri, 11 Nov 2005 18:40:53 +0100 Marius Mauch <genone@gentoo.org>
wrote:
|   I've already asked a similar question in another mail (in other
| context) without an answer, but how many news items do people believe
| will exist at any given time? Depending on the actual implementation
| it might be required to scan all existing news items which could take
| some time if there is a large number of them (say, more than a few
| hundred) It's clear that noone can present accurate numbers, just
| after some rough estimates here.

I don't expect it to be of the order of a few hundred. AFAIK there
aren't huge numbers of nasty upgrades...

| Also it might be useful for this filtering to be an external tool
| using portage functions and called by portage (see also below).
| Although this could be considered an implementation detail as it's
| mostly transparent for ebuild devs/users.

Yeah, I have a script which does it already. It's just rather slow
because of portageq. It'll be in the next draft.

| - local storage of news items / "read" attribute:
|   I don't really the like the copy-if-new feature and handling at the
| fs level, I'd use a file that lists the ids of news items (potentially
| with a timestamp and/or status field). I don't see any benefits of
| having redundancy here, and accessing the news in $PORTDIR is simple
| enough. Granted race conditions might be an issue (where the solution
| complicates tools), but that's so minor I wouldn't really care about
| it.

I'll have to think about that one... ID lists should be easy from an
implementation perspective...

| Another thing that's unclear: "Whenever relevant unread news items are
| found, emerge will copy or symlink the news file into
| /var/lib/gentoo/news/." 
| This "Whenever ... are found" is too vague, should this apply to
| emerge --sync, any emerge operation, any "import portage" call or
| what? This isn't just an implementation detail. 

I'd say after emerge --sync, plus after an emerge --pretend and before
an emerge blah. Will there be hooks for these?

| PS: I'd avoid symlinks here at all costs, too easy to break them. 

Probably true, especially if portdir changes...

| Also as Brian and Jason have said already, the system should be able
| to handle multiple repositories. So to use the current GLEP as
| example, at least the path should be changed
| to /var/lib/gentoo/news/porttree

Pfff, if that ever happens it's just a case of adding in another
directory level. As it stands though, there's no multiple repo support
in portage and no way to uniquely identify a repo, so I see no point in
going out of the way to handle something which may or may not ever
happen.


| - quality control:
| "Any complaints regarding wording or clarity must be addressed before
| the news item goes live." Playing devils advocate here, but complaints
| regarding correctness are not mandatory to be adressed?

Mmm, guess I should change that to "Any complaints (including, without
prejudice to the aforesaid generality, those of wording, clarity or
correctness) must ...".

| As for using -core, please add a small explanation or at least a
| reference to the appropriate policy docs

I've moved the -core stuff to a .. Note:: for the next draft.

| Things that should definitely be changed:
| - Integration with existing systems:
| This definitely should be a requirement for the GLEP to be considered
| final. It doesn't prevent some thing being implemented sooner than
| others, but multi-channel distribution (to use a buzzword) is a
| requirement from where I come from.

I'd really rather that news.gentoo.org / news2announceemail / whatever
were handled via separate GLEPs. 42 is fairly long as it is...

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grant Goodyear]

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

Marius Mauch wrote: [Fri Nov 11 2005, 11:40:53AM CST]
> Things that I'd like to be changed/I'm not completely sure about:
> - filtering of news items:
>   I've already asked a similar question in another mail (in other
> context) without an answer, but how many news items do people believe
> will exist at any given time? Depending on the actual implementation it
> might be required to scan all existing news items which could take some
> time if there is a large number of them (say, more than a few hundred)
> It's clear that noone can present accurate numbers, just after some
> rough estimates here.

The GLEP sets the bar pretty high for what should be a significant news
item, so my extremely rough guess is that 30/year would be on the quite
high side.  Ideally this system should extend, not supplant, the normal
einfo/ewarn notices.  (Um, what is the status of the einfo/ewarn message
system that went into CVS.  Any ETA on when it's going to be back-ported
to current portage?  I could see where there might be a tendency to
abuse the news system if the messaging stuff is still unavailable.)

> Also it might be useful for this filtering to be an external tool using
> portage functions and called by portage (see also below). Although this
> could be considered an implementation detail as it's mostly transparent
> for ebuild devs/users.

I'm not quite sure what you're saying here.

> - local storage of news items / "read" attribute:
>   I don't really the like the copy-if-new feature and handling at the fs
> level, I'd use a file that lists the ids of news items (potentially
> with a timestamp and/or status field). I don't see any benefits of
> having redundancy here, and accessing the news in $PORTDIR is simple
> enough. Granted race conditions might be an issue (where the solution
> complicates tools), but that's so minor I wouldn't really care about
> it. 

My impression was that ciaranm was thinking of using something akin to a
Maildir mailbox to hold and handle news items, because then one can
leverage an insane amount of existing stuff.  *Shrug*  I also wouldn't
object to a flat list of pointers to relevant files.

> Another thing that's unclear: "Whenever relevant unread news items are
> found, emerge will copy or symlink the news file into
> /var/lib/gentoo/news/." 
> This "Whenever ... are found" is too vague, should this apply to emerge
> --sync, any emerge operation, any "import portage" call or what? This
> isn't just an implementation detail. 

I was going to say that the only way new news items could appear is
during an emerge --sync, but of course that's not true for people who
either add an overlay or use CVS.  I'd be comfortable with making it run
only at --sync time, or if it were triggered explicitly (--check-news,
or some such).  

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

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

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Fri, 2005-11-11 at 10:03 +0100, Grobian wrote:
> Ok, you want a reaction, because you are Feeling Blue[1], right.

The only reaction I want is for us to meet the goals that I have set
out, instead of trying to move those goals.

> You describe here (and in your diary) the aim to reach 100% of our user
> base.  Wow, nice thing.  Discussions on whether you will succeed or not,
> are out of the question right now, it's just your aim.  Good.  I hope
> you will succeed!

Thanks.

> I scoured the forums a bit and looked what users were telling.  I wasn't
> surprised.  What do you expect from a user telling it all doesn't work
> any more, who doesn't run etc-update just because "after every emerge
> --upgrade --world it has over 100 files to update"?  Such user just
> ignores the importance of the tool, and will most certainly ignore
> anything else that we try to help this user.  This was just one example.

When we have emerge --news done, and users come along and complain that
they didn't know about something, then *maybe* we have some moral high
ground to stand on.

Personally, I don't care for the whole approach of moral high ground on
this one.

Gentoo's not just a cool toy.  We're also responsible to delivering the
best we can for our users.  I'd like to think that includes the best
news.

> It is a very humble attempt to try and help these users, but they simply
> chose the wrong Linux distro, because Gentoo expects you to be an system
> administrator, not a user.  At least that's my vision on it.  I think we
> can agree that Gentoo requires a user to know/realise more than a
> Fedora/SuSe/Ubuntu user.

I agree that the required knowledge level is higher than certain other
distros.  But I don't think experience or ability is the issue.  I don't
believe that experience or ability has anything to do with whether or
not that person keeps up to date with important Gentoo news.

Even if a user keeps up with the news, there will be lapses due to
sickness, holiday, pressure of other tasks, and so on.  One of the nice
benefits of emerge --news is that the news will be there for them when
they need it.

> I am just in the opinion that we lack a system where users can find the
> information they need.  

Agreed, but there's no way that every user (or even a majority of users)
will take the trouble to go looking for that information.  I'm making
that assertion partly on common-sense, and partly on my experience of
running a F/OSS project back in the mid-nineties.

I think this is where it'd help if Gentoo had some way of working out
the install base, and comparing that to some meaningful stats from
www.g.o et al, so that we could have a discussion based on facts that
could stand up to scrutiny from both sides.

However, we don't really have a way atm that I know about to get either
of these stats.  Maybe infra could do some rsyncd log analysis to put
together a rough guestimate, and maybe the GDP could post some useful
stats from www.g.o as I've twice asked for now.

There again, maybe we don't really want those stats.  Who knows - they
might show that our userbase is nowhere near the size we think it is :)

> Here comes the point where I can express my doubt about the 100%.  There
> are unfortunately users who are too hard to help, if you get what I
> mean.

I agree.  But at least we will have done our best, which I'd like to
think is what having that nice @gentoo.org email address is all about.

> As you might guess
> from my comment above, I simply think _communication_ is the big
> problem, as I see being a problem in many places around here.  

I think that covers a multitude of sins though.  I'm not trying to fix
them all.  I just want to fix this one problem at a time.

The one I'm concerned with is ensuring that the news we already generate
reaches all of our users.  That's all I care about right now.  I don't
actually care whether it's done by emerge --news; I will happily support
a more effective solution.

> Not that perfect communication solves the problem entirely, but it allows to
> reply in the sense of 'rtfw'.

rtfn, surely? :)

> If you're serious here, feel free to contact me (off-list) to see what
> we can arrange.

Drop into #gentoo-apache and let's talk :)

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Fri, 2005-11-11 at 18:40 +0100, Marius Mauch wrote:
>   I've already asked a similar question in another mail (in other
> context) without an answer, but how many news items do people believe
> will exist at any given time?

We won't know for certain until people start using it.  I expect that
it'll eventually be used for more than just the
package-upgrade-will-break-your-box type news that we plan on using it
for at first.

For example, there's no real reason why GLSA's couldn't been delivered
via this at some point (although I'd prefer a "You have X amount of
security fixes to apply" type message adding to emerge, and treating
GLSAs as a special case).

> Things that should definitely be changed:
> - Integration with existing systems:
> This definitely should be a requirement for the GLEP to be considered
> final. It doesn't prevent some thing being implemented sooner than
> others, but multi-channel distribution (to use a buzzword) is a
> requirement from where I come from.

One of the key things with successfully delivering a change programme is
to not dilute the change by introducing too many at once.  

If we simultaneously launch emerge --news w/ (f.ex) gatewaying to
gentoo-announce, I believe that it weakens the impact of introducing
emerge --news.  

One of the objectives is to remove confusion from the minds of users
about where to find the news.  If we can start by pointing at one place,
and saying "go there", we can clear up the confusion, and then
afterwards introduce multi-channel distribution when our users "get it",
so to speak.

I'm all for making the news available via www.g.o etc etc as well - I
just think doing it all at the same time will not be the most effective
strategy.

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Fri, 11 Nov 2005 22:37:15 +0000 Stuart Herbert <stuart@gentoo.org>
wrote:
| For example, there's no real reason why GLSA's couldn't been delivered
| via this at some point (although I'd prefer a "You have X amount of
| security fixes to apply" type message adding to emerge, and treating
| GLSAs as a special case).

sssshh! We're not supposed to be mentioning that until the thing's up
and running.

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Fri, 2005-11-11 at 22:37 +0000, Stuart Herbert wrote:
> > Things that should definitely be changed:
> > - Integration with existing systems:
> > This definitely should be a requirement for the GLEP to be considered
> > final. It doesn't prevent some thing being implemented sooner than
> > others, but multi-channel distribution (to use a buzzword) is a
> > requirement from where I come from.
> 
> One of the key things with successfully delivering a change programme is
> to not dilute the change by introducing too many at once.

Umm... what?

> If we simultaneously launch emerge --news w/ (f.ex) gatewaying to
> gentoo-announce, I believe that it weakens the impact of introducing
> emerge --news.

As I stated in my last email, emerge --news is not comprehensive enough
of a system to be usable by everyone.  The only solution to this is to
introduce a system that delivers the same information across multiple
mediums.

How would I know about a new update to apache if I don't have it
installed on my workstation, use a remote portage tree delivered via NFS
to my servers, and don't use --pretend?  I notice you didn't say
anything about emerge --news being fatal in any way, so if I just type
in "emerge -u world" on said server and then hit "control+a d" to detach
from the screen, when exactly am I going to see that the recent apache
update broke the config file format we had been using?

Where can I search for news on a package that might not exist on my
system?

Where can I find archived news to find out why I made a change
previously to my configurations?

> One of the objectives is to remove confusion from the minds of users
> about where to find the news.  If we can start by pointing at one place,
> and saying "go there", we can clear up the confusion, and then
> afterwards introduce multi-channel distribution when our users "get it",
> so to speak.

Wouldn't it be easy to say "emerge --news, news.gentoo.org, the News
forum, or gentoo-announce... take your pick" than to say to the user
that they must run an emerge --sync to get news delivered to their
machine, and only news that is relevant to the packages installed on
that exact system, making it useless for people that administer multiple
machines?

> I'm all for making the news available via www.g.o etc etc as well - I
> just think doing it all at the same time will not be the most effective
> strategy.

No offense intended by this, but I haven't seen anyone agreeing with you
on this point.  It seems to be your own quest to have the news *only*
delivered by portage.  By your own admission, you want to reach 100% of
the users.  The only effective way to do this is to essentially carpet
bomb the information into several mediums, all containing the *same*
information.  Think about how advertising works.  The idea is to put
your "product", the news, in our case, in front of as many eyes as
possible.  This is best done by utilizing all of the media available to
us.

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

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Grant Goodyear posted <20051111210958.GI12958@dst.grantgoodyear.org>,
excerpted below,  on Fri, 11 Nov 2005 15:09:58 -0600:

> I was going to say that the only way new news items could appear is
> during an emerge --sync, but of course that's not true for people who
> either add an overlay or use CVS.  I'd be comfortable with making it run
> only at --sync time, or if it were triggered explicitly (--check-news,
> or some such).

I don't believe that meets the emerging <g> consensus on the requirements:
get news to as many as possible that don't get it now, and that won't go
out and look for it.  Others have pointed out that emerge sync is often
unattended, as a cron job, so that won't get it in front of the 100% we're
looking for.  An explicit --check-news, while it might be nice, doesn't
accomplish the task either, because that requires people to do something
explicit to get it.

Rather, Ciaran's take, from a post to a different subthread:

> I'd say after emerge --sync, plus after an emerge --pretend and before
> an emerge blah. Will there be hooks for these?

We might put some sort of enews command in a new version of gentools
covering current portage, before a new portage version with all the
plumbing for news notifications at the times above built-in is released,
but it should only be a stopgap measure.

IMO it would also be wise to make the functionality feature controlled. 
Make a FEATURES=news, then turn it on by default, or go the negative route
that is so distasteful to some on USE flags, and make it a
FEATURES=nonews, emphasizing that "Gentoo" thinks it should /really/ be on
by default.  OTOH, the same thing could be accomplished by not making it a
direct choice but simply allowing the existing rsync-exclude mechanism to
do its thing, if folks set it to exclude the news subtree. 

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Fri, 2005-11-11 at 18:22 -0500, Chris Gianelloni wrote:
> It seems to be your own quest to have the news *only*
> delivered by portage.  

I thought I'd been very clear in the email that you've replied to that I
support making the news available via other ways.  It's the timing that
I'm a bit worried about.

I've managed a few change programmes over the years, and I've had the
most success when a change happened in stages.  The issues centre on the
ability of a large body of people to understand the change that has been
introduced.  People find change itself confusing.  If something isn't
given time to bed in, people never quite understand the original change,
and this undermines the benefits of introducing the change.

We live and breathe Gentoo daily, and we understand this news thing
because we've invested time and effort to kick it back and forward here
on -dev.  The vast majority of our users haven't had that luxury, and
it'll take a while for them to "get it".

If the majority don't agree with me, not a problem; I'm not going to
stop you (like I could anyway!) from putting out multi-channel from day
one.  

But if it was my decision, I'd roll out one channel first, and the
others later.

> By your own admission, you want to reach 100% of
> the users.  The only effective way to do this is to essentially carpet
> bomb the information into several mediums, all containing the *same*
> information.  Think about how advertising works.  The idea is to put
> your "product", the news, in our case, in front of as many eyes as
> possible.  This is best done by utilizing all of the media available to
> us.

That's not my experience of how advertising works.  

My experience with advertising is that you place your product, service,
or message where your target audience is most likely to see it and be
affected by it.  Most bang for your buck, if you like.  The placement
creates the context for the advert.

Most advertising carries what the marketdroids term a "call to action" -
something that tells the reader how to buy the product, or whatever.
Some advertising is about raising general brand awareness (something
Orange was exceptional at), so that the reader will think of the firm
and its products at a point in the future.

Carpet-bombing, by comparison, goes against commonly observed human
psychology.  If you tell people the same thing too many times, they stop
listening to you.  Blitzing people just leaves them too shocked to
absorb the message.

But if you introduce something gradually, you can then turn up the
volume, so to speak, without people being unsettled by it.  There's two
great stories in R. V. Jones "Most Secret War" where Dr. Jones used this
principle to play practical jokes on people he knew during his Oxford
days, for example.

I hope that the technical solution will allow users to choose to see
news about packages that are not installed - so that we can deliver news
that isn't strictly package related, such as new Gentoo LiveCDs, or a
Gentoo event, or so that we can deliver news where the package isn't yet
in the tree (f.ex. announcing a new overlay, or Gentoo-hosted project).

I'm not hoping for a 100% perfect technical solution straight away.
Release early, release often is the F/OSS way.  Once we've agreed on
something that's fit for purpose, let's implement it, deploy it, get to
the tipping point, see how users react, and then improve it.

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

Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Georgi Georgiev]

maillog: 11/11/2005-05:48:50(-0700): Duncan types
> Perhaps $PORTDIR/news, with seen and unseen subdirs (and appropriate
> no-sync settings on the subdirs)

Remember that $PORTDIR can be shared between machines. That's why
"world" is kept in /var/lib/portage.

-- 
\    Georgi Georgiev   \  Ignorance is bliss. -- Thomas Gray Fortune \
/     chutz@gg3.net    /  updates the great quotes, #42: BLISS is    /
\  http://www.gg3.net/ \  ignorance.                                 \
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Jason Stubbs]

On Saturday 12 November 2005 07:19, Stuart Herbert wrote:
> When we have emerge --news done,

I keep seeing references to "emerge --news" but at the same time am seeing 
that news readers are external. What exactly is `emerge --news` meant to do? 
Print out "You've got news!"? Manage some external database?

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

[gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Georgi Georgiev posted
<20051112022746.GA19297@ols-dell.iic.hokudai.ac.jp>, excerpted below,  on
Sat, 12 Nov 2005 11:27:47 +0900:

> maillog: 11/11/2005-05:48:50(-0700): Duncan types
>> Perhaps $PORTDIR/news, with seen and unseen subdirs (and appropriate
>> no-sync settings on the subdirs)
> 
> Remember that $PORTDIR can be shared between machines. That's why "world"
> is kept in /var/lib/portage.

Good point!

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Stuart Herbert wrote:
> On Fri, 2005-11-11 at 18:22 -0500, Chris Gianelloni wrote:
>> It seems to be your own quest to have the news *only*
>> delivered by portage.  
> 
> I thought I'd been very clear in the email that you've replied to that I
> support making the news available via other ways.  It's the timing that
> I'm a bit worried about.

And that worries me.  Because you more or less suggest to postpone 
implementing (just activating) traditional solutions, being used by many 
equivalent others in our field (works for them, more or less) in favour 
of an experimental new thing.
I would just do it the other way around: do your experiment after the 
traditional channels are set up, and let your experiment rely on the 
solid base those traditional solutions give.

> I've managed a few change programmes over the years, and I've had the
> most success when a change happened in stages.  The issues centre on the
> ability of a large body of people to understand the change that has been
> introduced.  People find change itself confusing.  If something isn't
> given time to bed in, people never quite understand the original change,
> and this undermines the benefits of introducing the change.

You are probably right here.  So why not doing the obvious steps?  Just 
activate now the traditional ways of getting news to the users.  In the 
mean-time you work on getting GLEP42 implemented and accepted, and by 
the time it more or less works, you have a wonderful base to announce 
this new feature on, and sell it as "personalised sophisticated news 
delivery".

> We live and breathe Gentoo daily, and we understand this news thing
> because we've invested time and effort to kick it back and forward here
> on -dev.  The vast majority of our users haven't had that luxury, and
> it'll take a while for them to "get it".

Another good reason to start with the 'common' things.  The traditional 
ways some of your 100% of our users will be common with.  Nothing new 
there for them.  The portage way *is* new, and has never been done, 
hence they might have difficulties to "get it".

> If the majority don't agree with me, not a problem; I'm not going to
> stop you (like I could anyway!) from putting out multi-channel from day
> one.  
> 
> But if it was my decision, I'd roll out one channel first, and the
> others later.

See above why I think that is just the wrong order, though I support 
your 'phased' roll out.

> I'm not hoping for a 100% perfect technical solution straight away.
> Release early, release often is the F/OSS way.  Once we've agreed on
> something that's fit for purpose, let's implement it, deploy it, get to
> the tipping point, see how users react, and then improve it.

Please remember that many of your 100% of our users hates software that 
doesn't work.  It wouldn't be the first time a user decides never to use 
a piece of software again, because his/her first experience with it was 
very bad.  You'd lose a few bits of your 100% making it impossible to 
reach your own goal.
I would seriously test this (hence not release early), if you happen to 
make an error and deliver all news messages at once to the user, you 
might end up in having the same as that very user that ignored 
etc-update because it had so much items to update.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Grobian posted <4375AC87.4020009@gentoo.org>, excerpted below,  on Sat, 12
Nov 2005 09:49:11 +0100:

> Stuart Herbert wrote:
>> I thought I'd been very clear in the email that you've replied to that I
>> support making the news available via other ways.  It's the timing that
>> I'm a bit worried about.
> 
> And that worries me.  Because you more or less suggest to postpone
> implementing (just activating) traditional solutions, being used by many
> equivalent others in our field (works for them, more or less) in favour of
> an experimental new thing.

I agree to some extent with both viewpoints, here.  I think the viewpoint
of the "portage first" side is that we already have the "traditional"
stuff, the announce and dev list, the GWN, the forums, and "system
changing" announcements generally make it to most if not all those
already, but it's not working for some folks, and we want to see if
there's anything more that can be done, thus, the news-thru-portage
proposal.  This viewpoint holds that since the portage angle is going to
form the core of things, since that's the main /new/ feature, implementing
it should be first, with the system designed around that, /then/ the
additional automated notifiers can be put into effect after the main
infrastructure is complete.

Valid viewpoint with some strong points supporting it.

The traditional side first viewpoint recognizes that getting portage set
up and a new version rolled out to stable, after the usual level of
testing, with all these new features, is going to take awhile.  This
viewpoint says nail down the reference format, create the dir in the
portage tree, set up the vetting process, and get started putting the
notices in the tree ASAP.  This won't require rolling out a new version of
portage, since current portage will just sync the new dir, and ignore it. 
At this point, we won't even have local portage doing the filtering, the
stuff will just be delivered in the portage tree sync and stay there, but
that's fine.

Once the "supply side" of the infrastructure is set up, that will allow
user submitted tools, outside of portage, a chance to go to it.  Since
these separate tools don't have the Gentoo-vital duties that
emerge/portage does, these tools could be deployed relatively quickly,
with rather less testing.  Likely, there'd fairly quickly be a couple of
unofficial ebuilds available on the user list and forums, much like the
several implementations of eclean, the one of which has now been chosen to
put into portage and is now in ~arch.

At the same time and also rather more rapidly than portage could evolve
and be tested, various devs could be working on the automated scripts that
would post the notices to the forums, announce and probably user lists,
and a web page, perhaps hanging off of packages.gentoo.org.  Portage's
functionality, meanwhile, would come along in due time, likely rather
after several other delivery implementations are active, because of the
time required to implement it in an already functional and vital program,
without breaking anything, AND to properly test to be SURE nothing broke.

This too is a valid viewpoint, with its strong points, the biggest weak
point being that because other delivery implementations will be using the
standard before portage gets nicely tested with it, it's possible
something unforeseen will come up with the reference format that makes it
more difficult to implement in what was after all the whole reason it was
put together in the first place -- portage.  With other stuff already
using the format, it'd be far more difficult to tweak it if needed by the
portage implementation, without breaking the other stuff.

Noting of course that I'm here, and I'm reading announce, and GWN,
therefore the proposal, while useful for me, isn't directly targeted at
me, and further noting that I'm not the one that's gotta do the
implementation, I can never-the-less post my "druthers" on the subject.
If I were implementing it, I'd probably go this second way.  It'll get
stuff out there and working faster than the first way, and provided
appropriate care is taken in drafting the reference format and
implementing the initial delivery into the tree infrastructure, the risk
of disturbing portage's development in the area is relatively low.  We get
the release early, release often going right away, and the other stuff
will naturally follow.

> Another good reason to start with the 'common' things.  The traditional
> ways some of your 100% of our users will be common with.  Nothing new
> there for them.  The portage way *is* new, and has never been done, hence
> they might have difficulties to "get it".

I don't see that happening.  Folks using Gentoo are already programmed to
use emerge for all their updates and to get new packages.  There's little
else to "get".

> Please remember that many of your 100% of our users hates software that
> doesn't work.  It wouldn't be the first time a user decides never to use a
> piece of software again, because his/her first experience with it was very
> bad.

Well, as it's shaping up, user's won't have a lot of choice -- the notice
of unread news will be output by portage any time they do much of anything
with it.  Sure, they can set rsync-exclude on the news dir, but those that
are likely to know how to do that aren't normally going to be the ones the
proposal is targeting anyway.  If they know how to do that, it's pretty
much a given that they know enough to sysadmin their own system, including
how to check for potential breaking updates, as things are.

Of course, they could ignore the news alerts, but they'll be right in
their face, so they'll have to actively work at it to do so.

That leaves rejecting emerge entirely, which pretty much means dumping
Gentoo.  While I'm sure we all hate to see such a thing happen, the
reality is it's going to happen, with some, and there's not a lot we can
do about it.  Meanwhile, we will have done what we could.

All that said, I more or less agree with where you end up, that is, that
we (Gentoo) should get the approval infrastructure and delivery into the
tree set up as soon as possible, so that folks can begin implementing
other user-view delivery methods relatively quickly.  Should that be done,
portage will probably end up being last to implement it's part, but by the
time it does, the other outlet methods will likely be decently on the way,
and chances are, the regulars in the forums and on the user list will have
already taken and run with the idea, so a not insignificant portion of the
userbase will already be familiar with the idea of news, before portage
ever delivers it.  As they say in the performance arts, there's nothing
like playing to a warm house!

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Sat, 2005-11-12 at 00:57 +0000, Stuart Herbert wrote:
> On Fri, 2005-11-11 at 18:22 -0500, Chris Gianelloni wrote:
> > It seems to be your own quest to have the news *only*
> > delivered by portage.  
> 
> I thought I'd been very clear in the email that you've replied to that I
> support making the news available via other ways.  It's the timing that
> I'm a bit worried about.
> 
> I've managed a few change programmes over the years, and I've had the
> most success when a change happened in stages.  The issues centre on the
> ability of a large body of people to understand the change that has been
> introduced.  People find change itself confusing.  If something isn't
> given time to bed in, people never quite understand the original change,
> and this undermines the benefits of introducing the change.

We aren't talking about something that is completely foreign to people.
They already have a notice about files in /etc and already know to do
what portage tells them.  How exactly would having a web page that the
user doesn't even know exists yet confuse them when they see the "You
have 5 unread news messages.  Please use: "enews read all" to view
them."?

Remember that we're talking about the same users that currently have no
idea where to go to get news.  They aren't going to suddenly subscribe
to gentoo-announce or check out news.gentoo.org on a whim and get
confused.

> We live and breathe Gentoo daily, and we understand this news thing
> because we've invested time and effort to kick it back and forward here
> on -dev.  The vast majority of our users haven't had that luxury, and
> it'll take a while for them to "get it".

Ehh... I also take that most of our users are not idiots.  If they see a
message from emerge *in a place that isn't hidden in compiler text* then
they will pay attention to it.

I know that if I were to suddenly run "up2date -u" on a system and it
told me that I should run "rpm --rebuildb" due to a change in RPM's
database format at the end of it, I would do so, whether I was aware
that Red Hat had posted this information on errata.redhat.com or not.

> If the majority don't agree with me, not a problem; I'm not going to
> stop you (like I could anyway!) from putting out multi-channel from day
> one.  
> 
> But if it was my decision, I'd roll out one channel first, and the
> others later.
> 
> > By your own admission, you want to reach 100% of
> > the users.  The only effective way to do this is to essentially carpet
> > bomb the information into several mediums, all containing the *same*
> > information.  Think about how advertising works.  The idea is to put
> > your "product", the news, in our case, in front of as many eyes as
> > possible.  This is best done by utilizing all of the media available to
> > us.
> 
> That's not my experience of how advertising works.  
> 
> My experience with advertising is that you place your product, service,
> or message where your target audience is most likely to see it and be
> affected by it.  Most bang for your buck, if you like.  The placement
> creates the context for the advert.

This only happens in cases of limited financial backing.  If you control
the mediums on which you are advertising, you would do it differently.
Especially if you are not selling any ads to anyone else.

> Most advertising carries what the marketdroids term a "call to action" -
> something that tells the reader how to buy the product, or whatever.
> Some advertising is about raising general brand awareness (something
> Orange was exceptional at), so that the reader will think of the firm
> and its products at a point in the future.
> 
> Carpet-bombing, by comparison, goes against commonly observed human
> psychology.  If you tell people the same thing too many times, they stop
> listening to you.  Blitzing people just leaves them too shocked to
> absorb the message.
> 
> But if you introduce something gradually, you can then turn up the
> volume, so to speak, without people being unsettled by it.  There's two
> great stories in R. V. Jones "Most Secret War" where Dr. Jones used this
> principle to play practical jokes on people he knew during his Oxford
> days, for example.
> 
> I hope that the technical solution will allow users to choose to see
> news about packages that are not installed - so that we can deliver news
> that isn't strictly package related, such as new Gentoo LiveCDs, or a
> Gentoo event, or so that we can deliver news where the package isn't yet
> in the tree (f.ex. announcing a new overlay, or Gentoo-hosted project).

This is where I disagree with you completely.  As a Gentoo user, I could
give a damn about a few developers getting together in the UK, and would
be pretty pissed off if Gentoo had this sort of garbage mixed in with
the critical information.  This entire thing came about due to the need
to get *critical* information to our users.

If users are interested in non-critical information, there's already a
mechanism in place for them to get such things.  They can join the
mailing lists.  Do we not already have a gentoo-events list?  We also
have a gentoo-releng list, or gentoo-announce.

> I'm not hoping for a 100% perfect technical solution straight away.

I am.  Anything less at this point is a half-assed design.  The *design*
should be 100% from the start.  While implementation can occur in
stages, you should not design as you go.

> Release early, release often is the F/OSS way.  Once we've agreed on
> something that's fit for purpose, let's implement it, deploy it, get to
> the tipping point, see how users react, and then improve it.
> 
> Best regards,
> Stu
-- 
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] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Sat, 2005-11-12 at 13:39 +0900, Jason Stubbs wrote:
> On Saturday 12 November 2005 07:19, Stuart Herbert wrote:
> > When we have emerge --news done,
> 
> I keep seeing references to "emerge --news" but at the same time am seeing 
> that news readers are external. What exactly is `emerge --news` meant to do? 
> Print out "You've got news!"? Manage some external database?

It is my opinion that the news reading application need not be
integrated into portage.  As far as I have understood it, the only real
thing that anyone has required portage itself to do is to
*automatically* spit out "You have $n unread news messages.  Please use
$bleh to read them" at certain times (after sync, after --pretend,
before/after a merge).  I don't see this as being something very
complex.  I would assume that some extra code would need to be written
into the sync code somewhere to sort the messages.

I wouldn't mind seeing something along the lines of /var/db/news
directory (or something repo specific, whatever) that has a pretty
simple format...

yyyy-mm-dd-$blah-$lang.txt.unread
yyyy-mm-dd-$blah-$lang.txt.read

When you delete a message, it is gone.  This means an external news
reader (enews anyone?) that basically has the capability to read, skip,
or delete these news items.

I think this would be pretty simple to get done and covers the problem
of messages being read or unread.  Of course, this is all just an idea,
so feel free to blow holes all in it.  ;]

-- 
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] Re: GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Sat, 2005-11-12 at 04:32 -0700, Duncan wrote:
> I agree to some extent with both viewpoints, here.  I think the viewpoint
> of the "portage first" side is that we already have the "traditional"
> stuff, the announce and dev list, the GWN, the forums, and "system
> changing" announcements generally make it to most if not all those
> already, but it's not working for some folks, and we want to see if
> there's anything more that can be done, thus, the news-thru-portage
> proposal.  This viewpoint holds that since the portage angle is going to
> form the core of things, since that's the main /new/ feature, implementing
> it should be first, with the system designed around that, /then/ the
> additional automated notifiers can be put into effect after the main
> infrastructure is complete.

I think I'd prefer a more simultaneous rollout.  The reason is fairly
simple, and I have stated it before and nobody has refuted it, only
ignored it.  What about packages not installed?

Also, it's going to take a while to go stable.  During this time, users
could also be using the other resources that would become available.
Sure, we won't hit everyone, but it'll still be an increase from what we
have now.  Once the newer portage version with this feature goes stable,
the number would go up again.

I also agree that the "meat" of this proposal is portage-delivered news.

> Valid viewpoint with some strong points supporting it.
> 
> The traditional side first viewpoint recognizes that getting portage set
> up and a new version rolled out to stable, after the usual level of
> testing, with all these new features, is going to take awhile.  This
> viewpoint says nail down the reference format, create the dir in the
> portage tree, set up the vetting process, and get started putting the
> notices in the tree ASAP.  This won't require rolling out a new version of
> portage, since current portage will just sync the new dir, and ignore it. 
> At this point, we won't even have local portage doing the filtering, the
> stuff will just be delivered in the portage tree sync and stay there, but
> that's fine.

Correct.

> Once the "supply side" of the infrastructure is set up, that will allow
> user submitted tools, outside of portage, a chance to go to it.  Since
> these separate tools don't have the Gentoo-vital duties that
> emerge/portage does, these tools could be deployed relatively quickly,
> with rather less testing.  Likely, there'd fairly quickly be a couple of
> unofficial ebuilds available on the user list and forums, much like the
> several implementations of eclean, the one of which has now been chosen to
> put into portage and is now in ~arch.

Actually, gentoolkit but correct otherwise.

> At the same time and also rather more rapidly than portage could evolve
> and be tested, various devs could be working on the automated scripts that
> would post the notices to the forums, announce and probably user lists,
> and a web page, perhaps hanging off of packages.gentoo.org.  Portage's
> functionality, meanwhile, would come along in due time, likely rather
> after several other delivery implementations are active, because of the
> time required to implement it in an already functional and vital program,
> without breaking anything, AND to properly test to be SURE nothing broke.

Again, correct.  This is why I don't think it is possible to "wait" for
it to get into portage before launching it anywhere else.

> This too is a valid viewpoint, with its strong points, the biggest weak
> point being that because other delivery implementations will be using the
> standard before portage gets nicely tested with it, it's possible
> something unforeseen will come up with the reference format that makes it
> more difficult to implement in what was after all the whole reason it was
> put together in the first place -- portage.  With other stuff already
> using the format, it'd be far more difficult to tweak it if needed by the
> portage implementation, without breaking the other stuff.
> 
> Noting of course that I'm here, and I'm reading announce, and GWN,
> therefore the proposal, while useful for me, isn't directly targeted at
> me, and further noting that I'm not the one that's gotta do the
> implementation, I can never-the-less post my "druthers" on the subject.
> If I were implementing it, I'd probably go this second way.  It'll get
> stuff out there and working faster than the first way, and provided
> appropriate care is taken in drafting the reference format and
> implementing the initial delivery into the tree infrastructure, the risk
> of disturbing portage's development in the area is relatively low.  We get
> the release early, release often going right away, and the other stuff
> will naturally follow.
> 
> > Another good reason to start with the 'common' things.  The traditional
> > ways some of your 100% of our users will be common with.  Nothing new
> > there for them.  The portage way *is* new, and has never been done, hence
> > they might have difficulties to "get it".
> 
> I don't see that happening.  Folks using Gentoo are already programmed to
> use emerge for all their updates and to get new packages.  There's little
> else to "get".
> 
> > Please remember that many of your 100% of our users hates software that
> > doesn't work.  It wouldn't be the first time a user decides never to use a
> > piece of software again, because his/her first experience with it was very
> > bad.
> 
> Well, as it's shaping up, user's won't have a lot of choice -- the notice
> of unread news will be output by portage any time they do much of anything
> with it.  Sure, they can set rsync-exclude on the news dir, but those that
> are likely to know how to do that aren't normally going to be the ones the
> proposal is targeting anyway.  If they know how to do that, it's pretty
> much a given that they know enough to sysadmin their own system, including
> how to check for potential breaking updates, as things are.
> 
> Of course, they could ignore the news alerts, but they'll be right in
> their face, so they'll have to actively work at it to do so.
> 
> That leaves rejecting emerge entirely, which pretty much means dumping
> Gentoo.  While I'm sure we all hate to see such a thing happen, the
> reality is it's going to happen, with some, and there's not a lot we can
> do about it.  Meanwhile, we will have done what we could.
> 
> All that said, I more or less agree with where you end up, that is, that
> we (Gentoo) should get the approval infrastructure and delivery into the
> tree set up as soon as possible, so that folks can begin implementing
> other user-view delivery methods relatively quickly.  Should that be done,
> portage will probably end up being last to implement it's part, but by the
> time it does, the other outlet methods will likely be decently on the way,
> and chances are, the regulars in the forums and on the user list will have
> already taken and run with the idea, so a not insignificant portion of the
> userbase will already be familiar with the idea of news, before portage
> ever delivers it.  As they say in the performance arts, there's nothing
> like playing to a warm house!
> 
> -- 
> 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
> 
> 
-- 
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] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Jason Stubbs]

On Sunday 13 November 2005 00:34, Chris Gianelloni wrote:
> On Sat, 2005-11-12 at 13:39 +0900, Jason Stubbs wrote:
> > On Saturday 12 November 2005 07:19, Stuart Herbert wrote:
> > > When we have emerge --news done,
> >
> > I keep seeing references to "emerge --news" but at the same time am
> > seeing that news readers are external. What exactly is `emerge --news`
> > meant to do? Print out "You've got news!"? Manage some external database?
>
> It is my opinion that the news reading application need not be
> integrated into portage.  As far as I have understood it, the only real
> thing that anyone has required portage itself to do is to
> *automatically* spit out "You have $n unread news messages.  Please use
> $bleh to read them" at certain times (after sync, after --pretend,
> before/after a merge).  I don't see this as being something very
> complex.  I would assume that some extra code would need to be written
> into the sync code somewhere to sort the messages.

This, I get. What I'm wondering about is the `emerge --news` that is referred 
to every so often.

> I wouldn't mind seeing something along the lines of /var/db/news
> directory (or something repo specific, whatever) that has a pretty
> simple format...
>
> yyyy-mm-dd-$blah-$lang.txt.unread
> yyyy-mm-dd-$blah-$lang.txt.read
>
> When you delete a message, it is gone.  This means an external news
> reader (enews anyone?) that basically has the capability to read, skip,
> or delete these news items.
>
> I think this would be pretty simple to get done and covers the problem
> of messages being read or unread.  Of course, this is all just an idea,
> so feel free to blow holes all in it.  ;]

To be honest, this is the part that I don't like the most. Integrating code 
into portage to copy files here and there based on some predefined rules and 
news readers reading and renaming files based on some predefined rules...
A filesystem based API just doesn't seem very robust to change.

I'd prefer that either the post-sync handling code is not integrated into 
portage and portage just triggers some external script - or - portage exposes 
an API (via python and bash) for accessing and updating news items. I'd 
prefer the latter but I get the impression that most prefer the former.

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

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[R Hill]

Chris Gianelloni wrote:
> On Thu, 2005-11-10 at 21:33 +0000, Stuart Herbert wrote:
>> Hence emerge --news.
> 
> Why?
> 
> There's no "emerge --etc" or "emerge --etc-update" functionality.  Why
> must it be "emerge --news" at all?

# emerge --help config

probably an emerge --help news that explains the basics of the news 
system and points the user to the default reader (whatever that becomes) 
or even just tells them where to find the news files to read in their 
editor of choice would be helpful.

>> We need to establish *one* authoritative source of news.  We can't do
>> that if we simultaneously launch several sources of news all at once.
>> We have to launch *one* service first, give the userbase time to adjust
>> to that, and then start making the news available via additional
>> sources.

No!  The other channels to deliver news to users are already in place. 
Make them *all* the one authoritative source of news.  If your goal is 
100% coverage, then why proceed without a fallback?

> No, we really don't.  Our users aren't idiots.  They just aren't reading
> the information presented to them.  While I agree that we need to have a
> single location for news, I also think that we must *require* this
> information be present in other locations.  The main reason for this is
> that "emerge --news" is filtered based on the packages installed on the
> system.  What about administrators that have lots of different systems?
> To them, it might be easier to receive all of the news, via
> gentoo-announce, and filter them via their own methods to determine what
> is important to them.  Perhaps I want to search for an old news item.
> Why shouldn't I be able to go to a web site and enter my query in a
> search box and get all of the major news updates to dev-lang/php?
> 
> If you want to reach 100% of the user base, then we should make this
> useful for as many situations as possible.  I know that with the number
> of machines that I administer, it would be much easier for me to get
> *all* of the news in one place and determine what is valid for my
> machines, rather than having to read them on each individual machine
> based on the packages installed.

Seconded. ;)


--de.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[R Hill]

Dan Meltzer wrote:
> Forever.

How about, "as long as relevant"? ;)



--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Grobian]

Jason Stubbs wrote:
> To be honest, this is the part that I don't like the most. Integrating code 
> into portage to copy files here and there based on some predefined rules and 
> news readers reading and renaming files based on some predefined rules...
> A filesystem based API just doesn't seem very robust to change.
> 
> I'd prefer that either the post-sync handling code is not integrated into 
> portage and portage just triggers some external script - or - portage exposes 
> an API (via python and bash) for accessing and updating news items. I'd 
> prefer the latter but I get the impression that most prefer the former.

- append message to /var/spool/mail/portage

alternative 1 (very very sober install):
- less /var/spool/mail/portage
- rm /var/spool/mail/portage

alternative 2 (sober install):
- vi /var/spool/mail/portage

alternative 3 (for those having `mail`, `mutt` or whatever that reads mbox)
- mail -u portage (program allows deletion)

alternative 4 (those that don't like mbox reading)
- either run mbox2mail or
- allow portage to write to a pipe to `mail` instead of append to 
/var/spool/mail/portage (would be the best solution IMHO)


It doesn't have to be so complicated, IMHO.  Most of the tools are 
already there, because traditional unix systems had this notification 
system built in.  Imagine how nice you could benefit from a shell that 
tells you you've got (new) mail if you log in as root.  Appending in the 
right format to /var/spool/mail/portage doesn't need an MTA either.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

Chris Gianelloni posted <1131809168.8774.10.camel@vertigo.twi-31o2.org>,
excerpted below,  on Sat, 12 Nov 2005 10:26:08 -0500:

>> I hope that the technical solution will allow users to choose to see
>> news about packages that are not installed - so that we can deliver news
>> that isn't strictly package related, such as new Gentoo LiveCDs, or a
>> Gentoo event, or so that we can deliver news where the package isn't yet
>> in the tree (f.ex. announcing a new overlay, or Gentoo-hosted project).
> 
> This is where I disagree with you completely.  As a Gentoo user, I could
> give a damn about a few developers getting together in the UK, and would
> be pretty pissed off if Gentoo had this sort of garbage mixed in with
> the critical information.  This entire thing came about due to the need
> to get *critical* information to our users.
> 
> If users are interested in non-critical information, there's already a
> mechanism in place for them to get such things.  They can join the
> mailing lists.  Do we not already have a gentoo-events list?  We also
> have a gentoo-releng list, or gentoo-announce.

Wow!  No kidding!  I too am off the (strong) opinion that those that
/want/ social news and the like can already get it from GWN and the
various lists.  We do NOT need portage spamming us with non-critical
announcements, or the channel will get so noisy folks will start ignoring
it.

BTW, I just had an experience that would have been a perfect match for 
critical news!  I just merged the new glibc-2.3.6, over the 2.3.5.2005mmdd
snapshot I was running due to the gcc4 fixes, and got clobbered over the
head with portages's symlink bug!  There's a message in red in the ebuild,
that I happened to glance at just in time to see it move offscreen, but it
said the problem was unsuccessful merges with current portage, which I
took to mean /stable/ portage.  No problem, I thought, I'm running ~arch,
so it should be fine, and if it's not, it'll just break the emerge and
I'll worry about it then.  THE MESSAGE DIDN'T SAY IT WOULD MERGE JUST
FINE, THEN ON THE OLD VERSION UNMERGE, WOULD PRETTY MUCH KILL MY SYSTEM!!
=8^P

Luckily I already had a couple mc sessions going, and having read the
caution about doing symlinks in a single step when updating glibc, in
O'Reilly's Running Linux, way back when I got serious about Linux and
decided I was going to switch from MSWormOS, /and/ having caught just
enough of the notice to get me thinking in that direction, I recognized
the issue immediately, and was able to use the already running midnight
commander instances to browse the portage database and restore enough
symlinks manually, to be able to run bunzip2 again, and open up the binpkg
(FEATURES=buildpkg) in mc's virtualfs and copy over the rest of the
symlinks.  Even if not, that's why I have snapshotted root dirs, so I
could have rebooted into one of those to fix it.

However, as I said, this would have made the /perfect/ candidate for a
critical news warning!

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Sun, 2005-11-13 at 01:05 +0900, Jason Stubbs wrote:
> > It is my opinion that the news reading application need not be
> > integrated into portage.  As far as I have understood it, the only real
> > thing that anyone has required portage itself to do is to
> > *automatically* spit out "You have $n unread news messages.  Please use
> > $bleh to read them" at certain times (after sync, after --pretend,
> > before/after a merge).  I don't see this as being something very
> > complex.  I would assume that some extra code would need to be written
> > into the sync code somewhere to sort the messages.
> 
> This, I get. What I'm wondering about is the `emerge --news` that is referred 
> to every so often.

emerge --news is just what people have been calling the news reader.  As
far as I can see, unless you *want* portage to handle the news reading,
it should *not* have a --news option.

> To be honest, this is the part that I don't like the most. Integrating code 
> into portage to copy files here and there based on some predefined rules and 
> news readers reading and renaming files based on some predefined rules...
> A filesystem based API just doesn't seem very robust to change.
> 
> I'd prefer that either the post-sync handling code is not integrated into 
> portage and portage just triggers some external script - or - portage exposes 
> an API (via python and bash) for accessing and updating news items. I'd 
> prefer the latter but I get the impression that most prefer the former.

I believe that we have been under the impression that you guys preferred
to keep this out of portage as much as possible.  I think an API built
into portage *would* be the best method for this.

-- 
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 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Sat, 2005-11-12 at 10:26 -0500, Chris Gianelloni wrote:
> If users are interested in non-critical information, there's already a
> mechanism in place for them to get such things.  They can join the
> mailing lists.  Do we not already have a gentoo-events list?  We also
> have a gentoo-releng list, or gentoo-announce.

At this point, I think you're suggesting that we different news carried
by different mediums.  If so, I think that's very different from the
proposal I'm putting forward.

> > I'm not hoping for a 100% perfect technical solution straight away.
> 
> I am.  Anything less at this point is a half-assed design.  The *design*
> should be 100% from the start.  While implementation can occur in
> stages, you should not design as you go.

I think that's a worthy goal, but looking around, it looks to me that
software design just doesn't work like that in real life.  Designs have
to adapt and change as time passes, not just implementations.

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Dan Meltzer]

One usually adapts to unforseen problems, not ones that are known
going into the project.

Your suggestion is akin to buying a car that you know has bad tires, a
bad alternator, a rusted body, and sundry other things wrong with it
for full price, and just planning on fixing when it actually breaks. 
It costs a lot more that way.

On 11/13/05, Stuart Herbert <stuart@gentoo.org> wrote:
> On Sat, 2005-11-12 at 10:26 -0500, Chris Gianelloni wrote:
> > If users are interested in non-critical information, there's already a
> > mechanism in place for them to get such things.  They can join the
> > mailing lists.  Do we not already have a gentoo-events list?  We also
> > have a gentoo-releng list, or gentoo-announce.
>
> At this point, I think you're suggesting that we different news carried
> by different mediums.  If so, I think that's very different from the
> proposal I'm putting forward.
>
> > > I'm not hoping for a 100% perfect technical solution straight away.
> >
> > I am.  Anything less at this point is a half-assed design.  The *design*
> > should be 100% from the start.  While implementation can occur in
> > stages, you should not design as you go.
>
> I think that's a worthy goal, but looking around, it looks to me that
> software design just doesn't work like that in real life.  Designs have
> to adapt and change as time passes, not just implementations.
>
> 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
> --
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBDd79pDC+AuvmvxXwRAqJRAKCiGr6Vu9rarsmfhDJrB0R5Fl0nIwCfUrfK
> lkPLVrFD0WhteHk/mcOKFtU=
> =PjJ8
> -----END PGP SIGNATURE-----
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Ciaran McCreesh]

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

On Sun, 13 Nov 2005 18:43:14 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| One usually adapts to unforseen problems, not ones that are known
| going into the project.
| 
| Your suggestion is akin to buying a car that you know has bad tires, a
| bad alternator, a rusted body, and sundry other things wrong with it
| for full price, and just planning on fixing when it actually breaks. 
| It costs a lot more that way.

Is this better or worse than refusing to buy a working car because it
doesn't come with fluffy dice?

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Thierry Carrez]

Ciaran McCreesh wrote:
> On Fri, 11 Nov 2005 22:37:15 +0000 Stuart Herbert <stuart@gentoo.org>
> wrote:
> | For example, there's no real reason why GLSA's couldn't been delivered
> | via this at some point (although I'd prefer a "You have X amount of
> | security fixes to apply" type message adding to emerge, and treating
> | GLSAs as a special case).
> 
> sssshh! We're not supposed to be mentioning that until the thing's up
> and running.

Why not, if it can speed up portage/GLSA "emerge --security" integration...

-- 
Thierry Carrez (Koon)
Operational Manager, Gentoo Linux Security
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Sun, 2005-11-13 at 22:34 +0000, Stuart Herbert wrote:
> On Sat, 2005-11-12 at 10:26 -0500, Chris Gianelloni wrote:
> > If users are interested in non-critical information, there's already a
> > mechanism in place for them to get such things.  They can join the
> > mailing lists.  Do we not already have a gentoo-events list?  We also
> > have a gentoo-releng list, or gentoo-announce.
> 
> At this point, I think you're suggesting that we different news carried
> by different mediums.  If so, I think that's very different from the
> proposal I'm putting forward.

I thought your proposal was to get critical information to our users,
not force every user to read that $dev is going to be in $country from
$date1 to $date2.  As I understood it, the portage-delivered news would
be 100% tree-related and not filled with nonsense.  If I am mistaken in
this, then I change my opinion on supporting this proposal, as I surely
don't give a damn about some dev meet in the UK that I would never be
able to attend and *definitely* don't want that *shoved* down my throat
by the tree.  I also noticed how you lost context in my quote by the way
you quoted it.  Thanks.

> > > I'm not hoping for a 100% perfect technical solution straight away.
> > 
> > I am.  Anything less at this point is a half-assed design.  The *design*
> > should be 100% from the start.  While implementation can occur in
> > stages, you should not design as you go.
> 
> I think that's a worthy goal, but looking around, it looks to me that
> software design just doesn't work like that in real life.  Designs have
> to adapt and change as time passes, not just implementations.

Really?  I work with quite a few developers where I work.  We have
meetings.  During these meetings, requirements are hashed out to cover
the scope of the project.  The code is then written to the
specifications.  If a later change is made into the requirements, then
another meeting takes place, and a change request is agreed upon and
scheduled.  They sure as hell don't let the requirements slip otherwise,
or they would end up in the ever-developing and never-completing world.

We're talking about a *very* simple set of things that need to be
developed here.  Why *would* we even consider not laying out the
requirements up front?

-- 
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 42 "Critical News Reporting" Round Two

[Marius Mauch]

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

On Mon, 14 Nov 2005 10:25:33 +0100
Thierry Carrez <koon@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > On Fri, 11 Nov 2005 22:37:15 +0000 Stuart Herbert
> > <stuart@gentoo.org> wrote:
> > | For example, there's no real reason why GLSA's couldn't been
> > delivered | via this at some point (although I'd prefer a "You have
> > X amount of | security fixes to apply" type message adding to
> > emerge, and treating | GLSAs as a special case).
> > 
> > sssshh! We're not supposed to be mentioning that until the thing's
> > up and running.
> 
> Why not, if it can speed up portage/GLSA "emerge --security"
> integration...

It can't.

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: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

Hi Chris,

Sorry for the delay in replying.  Having a few reliability problems with
my broadband atm.

On Mon, 2005-11-14 at 08:59 -0500, Chris Gianelloni wrote:
> I thought your proposal was to get critical information to our users,
> not force every user to read that $dev is going to be in $country from
> $date1 to $date2.  

This seems to be a misunderstanding somewhere along the line.  I've just
gone back and checked my original blog posting, and I definitely didn't
say anything about limiting news delivered via Portage in any way.

> this, then I change my opinion on supporting this proposal, as I surely
> don't give a damn about some dev meet in the UK that I would never be
> able to attend and *definitely* don't want that *shoved* down my throat
> by the tree.

That's twice now you've had a pop at the UK meetings in this thread.  If
there's some problem with the meetings that you'd like to get off your
chest, you could take it up with me on IRC or any of the other UK devs.

The events I've been involved in organising have been events for users,
and they've always been put together by both developers and users.  I
believe that some of our users *are* interested in exactly this type of
news - and, from the enquiries I've had in the past, not just UK-based
people.

Maybe we should add the ability to filter news based on some sort of
geographical setting too?  That'd be a reasonable thing to add to the
GLEP I think.

>   I also noticed how you lost context in my quote by the way
> you quoted it.  Thanks.

FFS, chill out, or even better come and talk to me on IRC about this
chip you seem to have on your shoulder in our recent dealings.  I've no
idea what it is that I've done to upset you atm, but I don't think that
here and bugzilla are the places for it.

> > I think that's a worthy goal, but looking around, it looks to me that
> > software design just doesn't work like that in real life.  Designs have
> > to adapt and change as time passes, not just implementations.
> 
> Really?  I work with quite a few developers where I work.  We have
> meetings.  During these meetings, requirements are hashed out to cover
> the scope of the project.  The code is then written to the
> specifications.  If a later change is made into the requirements, then
> another meeting takes place, and a change request is agreed upon and
> scheduled.  They sure as hell don't let the requirements slip otherwise,
> or they would end up in the ever-developing and never-completing world.

And, equally, the Portage tree is full of examples of software that has
not been developed this way.  I'm not saying that it's not a valid
engineering practice; but it's not the only way in the world that
software gets developed.

But anyway - we were talking about design, not requirements.  Although
obviously related, I've always seen them as being different things.

> We're talking about a *very* simple set of things that need to be
> developed here.  Why *would* we even consider not laying out the
> requirements up front?

I think we're talking at cross-purposes here.  You're talking about
requirements now, but my comment that you're responding to was about the
design, which I would normally treat as being different to requirements.

I agree that it's simple.  But I also think that, once we're using it,
we'll learn from that experience and want to make changes.  I may not be
the best practitioner of it, but I am a great believer in the F/OSS way
of release early, release often.  As a community, we don't seem to have
done too badly out of that approach.

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

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[George Prowse]

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

Having organised several Gentoo UK meetings I would like to be advised if
anyone has a problem; especially if they dont come or have no idea when,
where or what they are.

George Prowse

On 11/18/05, Stuart Herbert <stuart@gentoo.org> wrote:
>
> Hi Chris,
>
> Sorry for the delay in replying. Having a few reliability problems with
> my broadband atm.
>
> On Mon, 2005-11-14 at 08:59 -0500, Chris Gianelloni wrote:
> > I thought your proposal was to get critical information to our users,
> > not force every user to read that $dev is going to be in $country from
> > $date1 to $date2.
>
> This seems to be a misunderstanding somewhere along the line. I've just
> gone back and checked my original blog posting, and I definitely didn't
> say anything about limiting news delivered via Portage in any way.
>
> > this, then I change my opinion on supporting this proposal, as I surely
> > don't give a damn about some dev meet in the UK that I would never be
> > able to attend and *definitely* don't want that *shoved* down my throat
> > by the tree.
>
> That's twice now you've had a pop at the UK meetings in this thread. If
> there's some problem with the meetings that you'd like to get off your
> chest, you could take it up with me on IRC or any of the other UK devs.
>
> The events I've been involved in organising have been events for users,
> and they've always been put together by both developers and users. I
> believe that some of our users *are* interested in exactly this type of
> news - and, from the enquiries I've had in the past, not just UK-based
> people.
>
> Maybe we should add the ability to filter news based on some sort of
> geographical setting too? That'd be a reasonable thing to add to the
> GLEP I think.
>
> > I also noticed how you lost context in my quote by the way
> > you quoted it. Thanks.
>
> FFS, chill out, or even better come and talk to me on IRC about this
> chip you seem to have on your shoulder in our recent dealings. I've no
> idea what it is that I've done to upset you atm, but I don't think that
> here and bugzilla are the places for it.
>
> > > I think that's a worthy goal, but looking around, it looks to me that
> > > software design just doesn't work like that in real life. Designs have
> > > to adapt and change as time passes, not just implementations.
> >
> > Really? I work with quite a few developers where I work. We have
> > meetings. During these meetings, requirements are hashed out to cover
> > the scope of the project. The code is then written to the
> > specifications. If a later change is made into the requirements, then
> > another meeting takes place, and a change request is agreed upon and
> > scheduled. They sure as hell don't let the requirements slip otherwise,
> > or they would end up in the ever-developing and never-completing world.
>
> And, equally, the Portage tree is full of examples of software that has
> not been developed this way. I'm not saying that it's not a valid
> engineering practice; but it's not the only way in the world that
> software gets developed.
>
> But anyway - we were talking about design, not requirements. Although
> obviously related, I've always seen them as being different things.
>
> > We're talking about a *very* simple set of things that need to be
> > developed here. Why *would* we even consider not laying out the
> > requirements up front?
>
> I think we're talking at cross-purposes here. You're talking about
> requirements now, but my comment that you're responding to was about the
> design, which I would normally treat as being different to requirements.
>
> I agree that it's simple. But I also think that, once we're using it,
> we'll learn from that experience and want to make changes. I may not be
> the best practitioner of it, but I am a great believer in the F/OSS way
> of release early, release often. As a community, we don't seem to have
> done too badly out of that approach.
>
> 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
> --
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBDfmd0DC+AuvmvxXwRAtafAJ9OJtjtMg6iP+/uzrf3+LAuWMjOkACgu++7
> gjAOPPFf5clNdJnyqfKnZfE=
> =aSWJ
> -----END PGP SIGNATURE-----
>
>
>

[-- Attachment #2: Type: text/html, Size: 6053 bytes --]

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Duncan]

George Prowse posted
<36babadf0511181744y1b2f9e0bia4b9507d8e007244@mail.gmail.com>, excerpted
below,  on Sat, 19 Nov 2005 01:44:31 +0000:

> Having organised several Gentoo UK meetings I would like to be advised if
> anyone has a problem; especially if they dont come or have no idea when,
> where or what they are.

Top posting lost the context.  Anyway...

As I read the upline, the original point made had nothing to do about UK
meetings in particular, that was just an example.

The point made was that the purpose of this feature is to get out vital
"do this if you don't want your system broken when you upgrade" type news.
Folks that want announcements of meetings and that sort of thing can
subscribe to GWN -- that's what it's for.  If this feature starts getting
used for that, then folks will start ignoring it, because the SNR is too
low to be of any use for the intended purpose.

Nothing against UK meetings, or /any/ meetings, for that matter.  The
place to get that sort of news is GWN.  GLEP 42 is, and should remain,
different, as proposed, and in both my opinion and that of the original
poster that had the misfortune of bringing up the UK meetings as what was
supposed to be an off-hand example, and apparently hitting a sore spot.

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Chris Gianelloni]

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

On Fri, 2005-11-18 at 23:44 +0000, Stuart Herbert wrote:
> > this, then I change my opinion on supporting this proposal, as I surely
> > don't give a damn about some dev meet in the UK that I would never be
> > able to attend and *definitely* don't want that *shoved* down my throat
> > by the tree.
> 
> That's twice now you've had a pop at the UK meetings in this thread.  If
> there's some problem with the meetings that you'd like to get off your
> chest, you could take it up with me on IRC or any of the other UK devs.

Huh?

I was using it as an example of something that I would not be interested
in seeing in *my* tree since I wouldn't ever be able to attend.  What
did you think I meant by it.  Did I at any point say that the UK dev
meets are a bad thing?

> The events I've been involved in organising have been events for users,
> and they've always been put together by both developers and users.  I
> believe that some of our users *are* interested in exactly this type of
> news - and, from the enquiries I've had in the past, not just UK-based
> people.

Not in the tree.  There is already a place for this stuff.

> Maybe we should add the ability to filter news based on some sort of
> geographical setting too?  That'd be a reasonable thing to add to the
> GLEP I think.

It really sounds like you are wanting to make this proposal way too
complex, but I'll wait for the actual GLEP text before making any more
comments.

-- 
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 42 "Critical News Reporting" Round Two

[Stuart Herbert]

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

On Sun, 2005-11-20 at 13:06 -0500, Chris Gianelloni wrote:
> Huh?
> 
> I was using it as an example of something that I would not be interested
> in seeing in *my* tree since I wouldn't ever be able to attend.  What
> did you think I meant by it.  Did I at any point say that the UK dev
> meets are a bad thing?

I felt that you laboured the point beyond what was reasonable.  It's a
mis-understanding on my part, and I apologise.

> > The events I've been involved in organising have been events for users,
> > and they've always been put together by both developers and users.  I
> > believe that some of our users *are* interested in exactly this type of
> > news - and, from the enquiries I've had in the past, not just UK-based
> > people.
> 
> Not in the tree.  There is already a place for this stuff.

Delivering news via this mechanism allows us to reach far more people
than we can via the other places.  If we could already reach everyone,
we wouldn't need this mechanism in the first place.

> It really sounds like you are wanting to make this proposal way too
> complex, but I'll wait for the actual GLEP text before making any more
> comments.

I don't see the complexity here.  We're proposing a capability to
deliver news direct to our users, in a way that can be completely
disabled or personalised.  How many large corporations would kill to
have something that could do that? ;-)

If I can't convince you of the merits, I guess there's nothing else for
it but to continue work on delivering the proposal without your
support :(

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                        

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

[gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Dan Meltzer]

Personally, I do not think the tree is the place for anything besides
that which relates to the tree.  I really do not think users would
appreciate there sync being burdoned by "Developer x broke his toe
this week" ; "developer y is going to italy" ; "We recently recieved 3
new mirrors" and have all this shown on their screen.

This feature should only be used for things that are directly related
to the tree, and will cause mass breakage if ignored.

On 11/20/05, Stuart Herbert <stuart@gentoo.org> wrote:
> On Sun, 2005-11-20 at 13:06 -0500, Chris Gianelloni wrote:
> > Huh?
> >
> > I was using it as an example of something that I would not be interested
> > in seeing in *my* tree since I wouldn't ever be able to attend.  What
> > did you think I meant by it.  Did I at any point say that the UK dev
> > meets are a bad thing?
>
> I felt that you laboured the point beyond what was reasonable.  It's a
> mis-understanding on my part, and I apologise.
>
> > > The events I've been involved in organising have been events for users,
> > > and they've always been put together by both developers and users.  I
> > > believe that some of our users *are* interested in exactly this type of
> > > news - and, from the enquiries I've had in the past, not just UK-based
> > > people.
> >
> > Not in the tree.  There is already a place for this stuff.
>
> Delivering news via this mechanism allows us to reach far more people
> than we can via the other places.  If we could already reach everyone,
> we wouldn't need this mechanism in the first place.
>
> > It really sounds like you are wanting to make this proposal way too
> > complex, but I'll wait for the actual GLEP text before making any more
> > comments.
>
> I don't see the complexity here.  We're proposing a capability to
> deliver news direct to our users, in a way that can be completely
> disabled or personalised.  How many large corporations would kill to
> have something that could do that? ;-)
>
> If I can't convince you of the merits, I guess there's nothing else for
> it but to continue work on delivering the proposal without your
> support :(
>
> Best regards,
> Stu
> --
> Stuart Herbert                                         stuart@gentoo.org
> Gentoo Developer
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Mint Shows]

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

This feature should only be used for things that are directly related
> to the tree, and will cause mass breakage if ignored.
>

I fully agree with this statement. I am behind the adoption of the GLEP only
if it does what (I originally believed) was its purpose...to get CRITICAL
news regarding package upgrades..etc. If a user wants to know what's going
on with the developers..they can subscribe to this -dev list. If a user
wants to know how to NOT break his system by performing an 'emerge -u world'
portage should tell them.

--
Mint Shows
Office of Information Technology
University of Mississippi
mint@olemiss.edu
(662) 915-5222

[-- Attachment #2: Type: text/html, Size: 936 bytes --]

Re: [gentoo-dev] Re: GLEP 42 "Critical News Reporting" Round Two

[Andrew Muraco]

Mint Shows wrote:

>
>
>     This feature should only be used for things that are directly related
>     to the tree, and will cause mass breakage if ignored.
>
>
> I fully agree with this statement.  I am behind the adoption of the 
> GLEP only if it does what (I originally believed) was its purpose...to 
> get CRITICAL news regarding package upgrades..etc.  If a user wants to 
> know what's going on with the developers..they can subscribe to this 
> -dev list.  If a user wants to know how to NOT break his system by 
> performing an 'emerge -u world' portage should tell them.
>
> -- 
> Mint Shows
>
I fully agree here, or in the case of Apache, which my its self is not a 
critical system component, but its is a very important part of many 
user's systems, that is also worthy of a NEWS Item.

On another note, i'm not exactly sure how this would be implemented, but 
perferably wouldn't the new NEWS Items be best if provided before a 
package upgrade?
for example
emerge -avu apache

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild    U  ] net-www/apache-2.0.54-r31 *(1 News Item)  [2.0.54-r30]  
+apache2 -debug -doc -ldap -mpm-leader -mpm-peruser -mpm-prefork 
-mpm-threadpool -mpm-worker -no-suexec (-selinux) +ssl -static-modules 
-threads 5,488 kB

Total size of downloads: 5,488 kB

Would you like to read the unread News Item? [Yes/No]

Do you want me to merge these packages? [Yes/No]
                                                  
Of course, running emerge -vu apache shouldn't be stopped, it should 
continue with its own risk.

Thats just one thing i would like to see.

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