From: Alec Joseph Warner <warnera6@egr.msu.edu>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Date: Fri, 04 Nov 2005 13:53:23 -0500 [thread overview]
Message-ID: <436BAE23.40104@egr.msu.edu> (raw)
In-Reply-To: <200511050144.24388.jstubbs@gentoo.org>
Jason Stubbs wrote:
> On Friday 04 November 2005 23:26, Xavier Neys wrote:
>
>>Nathan L. Adams wrote:
>>
>>>One source: http://errata.gentoo.org/
>>>
>>>Push that out to as many alternate sources as you like (RSS feeds,
>>>summaries in emerge --news, forums post, etc.), but make it known that
>>>the website is *the* source (your alternate sources should point back to
>>>it).
>>
>>I beg to differ. The tree should be the central point because it's the only
>>known place where all users can receive relevant information on and for
>>each and every system they maintain right before they upgrade.
>>The warning and the logic that triggers its display should be part of
>>Portage. Sometimes, all that would need to be displayed is "run foo to fix
>>bar" or "Please do read http://bleh _before_ you upgrade foo".
>>
>>If an "Upgrade guide to foo/bar for Gentoo" is required, you need an author
>>to write it, not extra code or an extra web site.
>
>
> I probably shouldn't have included the sarcastic comment in my only other
> reply to this thread, but the rest of it was completely serious. People are
> under the mistaken impression that the ebuild tree is required to use
> portage. This is wrong and will become more and more wrong as time goes by.
>
> If there is not a specific need for this news stuff to go into the tree then
> it shouldn't be there. If there is a specific need (ie. it is tied to
> packages) what difference is there to the existing ChangeLog?
>
> --
> Jason Stubbs
I am going to summarize a bit, and address your point.
Summary: people want small news tidbits to be distributed to all users.
Currently the suggestion is tree-based. Portage should have code to
detect news elements after a sync and copy relevant elements to a uesr
specified news directory. The news should be in a human readable format
(XML, RST, pig latin, don't care at this point see below). Portage
should post-sync, print a message noting the number of unread but
relevant news messages. Users can use whatever means of reading them
that they like. IMHO, emerge --news can go to hell in a handbasket, I'd
rather just friggin use less, but hey, if you write the code...
News messages should contain minimal information necessary to carry
relevant information including affected packages, and a link to some
sort of documentation, be it gentoo-wiki, or official package docs, or
whatever.
For those without internet access 24/7, there may be an option required
to fetch these links. In the case of say, dial-up where someone only
has network say, 4 hours a day, they may wish to sync their tree, and
spider the docs links so they may view them locally. Machines with no
outside network ( internal production servers ) may also wish to make
use of this. In the case of online guides, we cannot necessarily define
their content, it may be XML, it may be plain text. I do not see how
conceeding that a user may need a web browser SOMEWHERE, is that big of
a tradeoff, especially if the content is already locally available.
As far as including news in the tree goes, news is repository bound
information. Each repository may in fact have relevant news, and in
preparation for multiple repositories this is how the news should be
handled. It goes with the rest of the repo-specific information. That
is why it should be in the tree.
However, in the case of a remote tree, some extra API calls may be
required. However, it is up to the class implementor to implement those
calls, not the original portage team ( unless you want to support remote
trees yourself, in which case that duty falls to you ). The only other
thing was no tree but a binpkg repo, in which case in savior, binpkg
repo should have news elements build in ( a repo, just all built
packages ). In stable, news should probably be added to the binpackage
if it's listed in the packages-affected.
For the XML vs RST. I personally don't want to read XML files in a
console, or install anything that makes it look all pretty for me, RST
is plenty good enough. Since Ciaran has graciously written all the code
for it already, I don't see any reason not to use it. RST is pretty
simple to migrate to a new format anyhow, and a converter could be
easily whipped up to transform it to guideXMl for errate.g.o if that is
what is desired ( not a bad idea IMHO ).
I forgot one other thing, that being perhaps a red NEWS that shows up
next to affected packages during an emerge -pv <package>, informing you
that important news is available for a package you are about to install.
So yeah, this is a long thread :0
Alec Warner (Antarus)
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2005-11-04 18:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 23:36 [gentoo-dev] GLEP 42 (Was: Getting Important Updates To Users) Chris White
2005-10-31 23:41 ` [gentoo-dev] " Dan Meltzer
2005-10-31 23:52 ` Dan Meltzer
2005-11-01 7:56 ` Wernfried Haas
2005-11-01 14:32 ` Chris Gianelloni
2005-11-01 19:32 ` Stuart Herbert
2005-11-01 19:51 ` Chris Gianelloni
2005-11-03 19:40 ` Stuart Herbert
2005-11-04 1:10 ` Nathan L. Adams
2005-11-04 8:22 ` Sami Näätänen
2005-11-04 14:26 ` Xavier Neys
2005-11-04 16:44 ` Jason Stubbs
2005-11-04 18:53 ` Alec Joseph Warner [this message]
2005-11-05 5:08 ` Jason Stubbs
2005-11-05 5:34 ` Alec Warner
2005-11-07 10:11 ` Paul de Vrieze
2005-11-07 12:37 ` Jason Stubbs
2005-11-07 16:06 ` Grant Goodyear
2005-11-07 16:44 ` Jason Stubbs
2005-11-07 16:43 ` Stuart Herbert
2005-11-05 9:58 ` [gentoo-dev] " Duncan
2005-11-05 12:54 ` [gentoo-dev] " Michiel de Bruijne
2005-11-06 19:32 ` R Hill
2005-11-01 19:53 ` Mike Williams
2005-10-31 23:46 ` [gentoo-dev] " Brian Harring
2005-11-01 10:51 ` Jason Stubbs
2005-11-01 0:42 ` Ciaran McCreesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=436BAE23.40104@egr.msu.edu \
--to=warnera6@egr.msu.edu \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox