public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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