On Fri, 11 Nov 2005 18:40:53 +0100 Marius Mauch <[EMAIL PROTECTED]> wrote: | I've already asked a similar question in another mail (in other | context) without an answer, but how many news items do people believe | will exist at any given time? Depending on the actual implementation | it might be required to scan all existing news items which could take | some time if there is a large number of them (say, more than a few | hundred) It's clear that noone can present accurate numbers, just | after some rough estimates here.
I don't expect it to be of the order of a few hundred. AFAIK there aren't huge numbers of nasty upgrades... | Also it might be useful for this filtering to be an external tool | using portage functions and called by portage (see also below). | Although this could be considered an implementation detail as it's | mostly transparent for ebuild devs/users. Yeah, I have a script which does it already. It's just rather slow because of portageq. It'll be in the next draft. | - local storage of news items / "read" attribute: | I don't really the like the copy-if-new feature and handling at the | fs level, I'd use a file that lists the ids of news items (potentially | with a timestamp and/or status field). I don't see any benefits of | having redundancy here, and accessing the news in $PORTDIR is simple | enough. Granted race conditions might be an issue (where the solution | complicates tools), but that's so minor I wouldn't really care about | it. I'll have to think about that one... ID lists should be easy from an implementation perspective... | Another thing that's unclear: "Whenever relevant unread news items are | found, emerge will copy or symlink the news file into | /var/lib/gentoo/news/." | This "Whenever ... are found" is too vague, should this apply to | emerge --sync, any emerge operation, any "import portage" call or | what? This isn't just an implementation detail. I'd say after emerge --sync, plus after an emerge --pretend and before an emerge blah. Will there be hooks for these? | PS: I'd avoid symlinks here at all costs, too easy to break them. Probably true, especially if portdir changes... | Also as Brian and Jason have said already, the system should be able | to handle multiple repositories. So to use the current GLEP as | example, at least the path should be changed | to /var/lib/gentoo/news/porttree Pfff, if that ever happens it's just a case of adding in another directory level. As it stands though, there's no multiple repo support in portage and no way to uniquely identify a repo, so I see no point in going out of the way to handle something which may or may not ever happen. | - quality control: | "Any complaints regarding wording or clarity must be addressed before | the news item goes live." Playing devils advocate here, but complaints | regarding correctness are not mandatory to be adressed? Mmm, guess I should change that to "Any complaints (including, without prejudice to the aforesaid generality, those of wording, clarity or correctness) must ...". | As for using -core, please add a small explanation or at least a | reference to the appropriate policy docs I've moved the -core stuff to a .. Note:: for the next draft. | Things that should definitely be changed: | - Integration with existing systems: | This definitely should be a requirement for the GLEP to be considered | final. It doesn't prevent some thing being implemented sooner than | others, but multi-channel distribution (to use a buzzword) is a | requirement from where I come from. I'd really rather that news.gentoo.org / news2announceemail / whatever were handled via separate GLEPs. 42 is fairly long as it is... -- Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
