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
