From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1Eag0K-00057Y-Rl for garchives@archives.gentoo.org; Fri, 11 Nov 2005 21:00:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jABKwOOc031732; Fri, 11 Nov 2005 20:58:24 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jABKsPdJ006819 for <gentoo-dev@lists.gentoo.org>; Fri, 11 Nov 2005 20:54:26 GMT Received: from 82-41-57-20.cable.ubr08.edin.blueyonder.co.uk ([82.41.57.20] helo=snowdrop.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1Eafuj-0004Ia-FJ for gentoo-dev@lists.gentoo.org; Fri, 11 Nov 2005 20:54:25 +0000 Received: from localhost.home ([127.0.0.1] helo=snowdrop.home) by snowdrop.home with esmtp (Exim 4.54) id 1Eafuh-0007DZ-Ew for gentoo-dev@lists.gentoo.org; Fri, 11 Nov 2005 20:54:23 +0000 Date: Fri, 11 Nov 2005 20:54:20 +0000 From: Ciaran McCreesh <ciaranm@gentoo.org> To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two Message-ID: <20051111205420.66b05e67@snowdrop.home> In-Reply-To: <20051111184053.780ed8c9@sven.genone.homeip.net> References: <20051105005814.0de0d8ff@snowdrop.home> <20051111184053.780ed8c9@sven.genone.homeip.net> X-Mailer: Sylpheed-Claws 1.9.99 (GTK+ 2.6.10; i686-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_ebmMatxVVevgC_YWFcH95b8; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 9ed6f289-f15a-4d43-9186-2aee605517af X-Archives-Hash: e0bea08afdf02a16331c83f2f792cb86 --Sig_ebmMatxVVevgC_YWFcH95b8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 11 Nov 2005 18:40:53 +0100 Marius Mauch <genone@gentoo.org> 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/."=20 | 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.=20 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.=20 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... --=20 Ciaran McCreesh : Gentoo Developer (Look! Shiny things!) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm --Sig_ebmMatxVVevgC_YWFcH95b8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDdQT+96zL6DUtXhERAoy/AJ94ecIdO1F1Z/Qn18BEpAy4Ha4IQwCdHFqn 52E6ziMesdgkEctz4wz1+4g= =oqch -----END PGP SIGNATURE----- --Sig_ebmMatxVVevgC_YWFcH95b8-- -- gentoo-dev@gentoo.org mailing list