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@g.o mailing list