Re: [gentoo-dev] glep 42 (news) round six

[Ciaran McCreesh]

On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <ferringb@g.o>
wrote:
| To head off the "don't make features that are easily screwed up",
| this isn't one of them- this is expecting code to behave correctly
| from the path standpoint.

Hrm, so will we be allowing spaces in package and category names too?

| > I don't want to introduce any signing requirements that we don't
| > have already. When signing for everything else becomes mandatory,
| > signing for news would be too. If I make this a 'must', someone
| > will ask me to specify how we're handling the Gentoo keyring...
| 
| Pawn the keyring off on others.  The issues isn't an established
| trust ring, it's required signing- yes, a trust ring makes things a
| helluva lot easier on the user front, but it's useless without a
| required signing policy.
| 
| We've already had this conversation also btw, in the 
| beginning of glep42 iirc.  Obviously I don't agree 
| with your reasoning "I'll do it when it's required I do it".  It's 
| useful now, it becomes massively more useful when a trust ring is 
| available.

Ok, how about I change it to "must", and add a note under Backwards
Compatibility along the lines of:

At the time of writing, there is no standardised mechanism for handling
GPG signatures in Gentoo. Until such a mechanism exists, GPG signing
cannot be considered mandatory.

| > | > ``Revision:``
| > | >     Initially 1. Incremented every time a non-trivial change is
| > | > made.  Changes which require a re-read of the news item should
| > | > instead use a new news item file. Mandatory.
| > |
| > | non-trivial changes that don't require a re-read sounds like a 
| > | contradiction.  Clarify, especially since portage will mark this
| > | as read _once_ and only once.
| > 
| > Hrm, word it as "Changes other than minor formatting tweaks", or
| > remove "non-trivial"?
| 
| It's not a wording thing, I'm pointing out sans spelling corrections 
| and trivial word mangling, any new info jammed in requires a new item 
| bump so readers can display the changes.
| 
| In light of that, wording above needs correction.

Ok, how's this?

``Revision:``
    Initially 1. Should be incremented every time a change is made to
the news item. Changes that require a re-read of the news item (for
example, most changes that are not spelling or formatting related)
should instead use a new news item. Mandatory.

| > | This isn't incredibly useful if ranged versions are ever
| > | introduced. Ammending the glep for that seems stupid, looser
| > | language might be wise.
| > 
| > What's the syntax for ranged versions? And how do they differ from
| > SLOT versions?
| 
| >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 
|
| It's not syntax as much as a boolean and of atoms.

Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and
kde-libs-5.0 installed (assuming SLOTted kde-libs)?

| > Once an hour would work fine. On the other hand, the merge is just
| > copying a few small files -- time-wise, it's less than generating
| > the cache for a couple of ebuilds.
| 
| More then a couple; this beast will bloat up to hundred or so files 
| I'd expect (remember translation serves as a multiplier).

Yup, but it's just a case of copying a few small text files.

| Any signed item would need to be verified also, although fortunately 
| this chunk can be done in parallel to regen run.

Hrm, is signing verification done for tree items?

| > | You haven't stated how the 'package manager' will trigger the
| > | user's reader of choice for these targets.  Should also extend
| > | this to allow a way to disable any news notices, lest someone's
| > | cronjob get hung displaying news (feature or not, it's needed).
| > 
| > The same way the package manager handles updating config files: it
| > won't. It'll just tell the user that some news items need reading.
| 
| And you'll personally handle all of the bug spam from feature
| requests that --ask trigger $news_reader?
| 
| It's a logical extension, thus people will ask for it.

What does emerge --ask do currently for config files?

| We expire updates?  If so, someone might want to look at the updates 
| from 3 years back...

Yes. Once a year, Seemant shows up and says "hey, does anyone ever
expire really really old updates entries?".

| > | > There is an existing automated tool [#forums-glsa]_ for posting
| > | > GLSAs to the forums. A similar tool can be used for these news
| > | > items.
| > | 
| > | Pawned it off on someone, or something you'll be doing?
| > 
| > Hopefully the former. I have it on reasonably good authority that it
| > won't take more than half an hour if I end up having to do it
| > though...
| 
| Get cracking then (regardless if it's pawning or coding).

Eh, that one can be left until the last minute.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm