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

[Ciaran McCreesh]

On Sat, 5 Nov 2005 05:24:51 -0600 Brian Harring <ferringb@g.o>
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