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 1EYMCk-0005y2-UR for garchives@archives.gentoo.org; Sat, 05 Nov 2005 11:27:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA5BQkH9012393; Sat, 5 Nov 2005 11:26:46 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 jA5BP25f013275 for ; Sat, 5 Nov 2005 11:25:02 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EYMAP-0002Kf-U8 for gentoo-dev@lists.gentoo.org; Sat, 05 Nov 2005 11:25:02 +0000 Date: Sat, 5 Nov 2005 05:24:51 -0600 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two Message-ID: <20051105112451.GA24767@nightcrawler> References: <20051105005814.0de0d8ff@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20051105005814.0de0d8ff@snowdrop.home> User-Agent: Mutt/1.5.8i X-Archives-Salt: 74c8b0f3-e603-42ea-9479-7c94084e5fe1 X-Archives-Hash: ac9b26586bcf67f2ec2281c5b8adb1c8 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 05, 2005 at 12:58:14AM +0000, Ciaran McCreesh wrote: > Lightweight > It is not reasonable to expect all users to have an MTA, web browser,= email > client, cron daemon or text processing suite available on their syste= m. >=20 > Multiple delivery method support > Some users may wish to view news items via email, some via a terminal= and > some via a web browser. A solution should either support all of these > methods or (better still) make it trivial to write clients for displa= ying > news items in different ways. Drop the lightweight bit and merge it into multiple delivery. You're=20 after lightweight _default_, which is fine, but the phrasing is a bit=20 screwed. > Quality control > There should be some way to ensure that badly written or irrelevant m= essages > are not sent out, for example by inexperienced developers, those whose > English language skills are below par or morons. While it may be fun getting a reaction out of people, nuke the nitro=20 laced words please. Same for the forums_whining ref (there's enough=20 contention over the glep already ;) > News items are published and delivered to users as follows: > 6. Portage filters the news item and, if it is relevant, installs it in a > special location to be read by a news item reader. Messages are also > displayed to inform the user that news is available. Out of curiousity, how are you planning on having 101 general notices=20 reigned down on a users head during an initial install? Yes, you have=20 the atom filter, but what about general notices? Further, how are notices going to apply to users who don't have the=20 package installed, then go and merge it? Your statement above implies=20 the irrevalent (at the time of sync) notices are ignored, which breaks=20 down under the scenario where a news item is pushed out that apache=20 configuration is going to change, I merge old style apache after=20 sync'ing the news, portage (due to your news id cache) considers it=20 deleted, and doesn't display it. > News Item File Format > --------------------- > News items may be signed using GPG. If this is done, a detached signature= should > be used. I'd argue for must be, personally. A bogus news item claiming to be=20 =66rom portage devs, telling users to change their SYNC setting could=20 cause massive mayhem. > The following headers are used for filtering. If none of these headers are > specified, the news item is displayed for all users. Otherwise, the news = item is > displayed if *at least one* header matches. >=20 > ``Display-If-Installed:`` > A dependency atom or simple package name (for example, > `` package specified installed, the news item should be displayed. Still haven't address my point about A) package moves combined with news entries B) N packages Assume you mean that the bit above is a full DepSet, not a single atom=20 (if that's the case, clarify that N atoms are allowed). Should clarify USE conditionals are a no go- might be worth=20 considering the full atom syntax (despite the fact portage doesn't=20 currently support it for depends), use flags, slot, etc. Yes it's more work, but it should be spelled out from where I'm=20 sitting. > ``Display-If-Keyword:`` > A keyword [#glep-22]_ name, for example ``mips``. If the user is on t= he arch > in question, the news item should be displayed. N keywords =3D=3D N Header entries? > There have been complaints regarding the comprehensibility of some upgrade > notices and news items in the past. This is understandable -- not every G= entoo > developer speaks English as a first language. However, for the sake of cl= arity > and professionalism it is important that any language problems be correct= ed > before inflicting a news item upon end users. >=20 > Thus, all proposed news items must be posted to the ``gentoo-dev`` or > ``gentoo-core`` mailing list No go on -core imo; it's a community/dev issue, should be visible to=20 the general public rather then hidden away in the ml we do our flaming=20 in. > Client Side > ''''''''''' >=20 > Whenever relevant unread news items are found, ``emerge`` will copy or sy= mlink > the news file into ``/var/lib/gentoo/news/``. Already pointed out that this won't fly looking forward, it implicitly=20 assumes a single repository. Need to allow for each repo to have their own news, preferably=20 seperated directory wise; either that or you're going to have to track=20 where a news item came from and mangle the new entry. > Notification that new relevant news items will be displayed via the > ``emerge`` tool in a similar way to the existing "configuration files need > updating" messages: >=20 > :: >=20 > * Important: 3 config files in /etc need updating. > * Type emerge --help config to learn how to update config files. >=20 > * Important: there are 5 unread news items. > * Type emerge --help news to learn how to read news files. >=20 > The unread news message will also be displayed immediately after an > ``emerge sync``. >=20 > Portage may also warn of unread news items using, for example, a red flas= hy > before actions such as merging a package. Nuke flashy (any phrasing that allows for blinking crap sliding into portag= e I=20 instinctively dislike). > Portage must keep track of news items which have already been installed t= o avoid > repeatedly reinstalling a deleted news item. Track it how, via the directory, or a secondary list? Wording implies portage is going to have to maintain it's own newsid=20 list; if that's the case, explicitly state so, and keep it limited to=20 per repo (not global as the proposal seems to indicate). > News Item Removal > ----------------- >=20 > News items can be removed (by removing the news file from the main tree) = when > they are no longer relevant, if they are made obsolete by a future news i= tem or > after a long period of time. This is the same as the method used for ``up= dates`` > entries. Might want to consider a maximum period of time for news entries to=20 linger by default; perhaps a header for controlling deletion (this is=20 would require commit access for whatever does the scans obviously). > Integration with Existing Systems > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > It would be trivial to convert these news items into the format used for = news > items on the Gentoo website or posts for the ``gentoo-announce`` mailing = list. Stop using trivial (no it's not in reference to above, just hit the=20 right word count where I'm whinging about it). > Reference Implementation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Portage Code > ------------ >=20 > TODO Points above regarding working sanely for N repos need be addressed,=20 plus any implementation needs to be integrated, not handing off to an=20 external tool (don't want 2 different implementations of atom=20 parsing). Personally... I still think package level news should not be treated=20 as repository level information. It makes any attempt at glep19 a bit=20 trickier and stores package data in two different locations. So... reiterating jasons question, example where news items transcend=20 package specific? ~harring --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDbJaCvdBxRoA3VU0RApYBAKDpBP9HALkrr79PMpgJmZ8IWiS2HgCg6HGu J2bdsOt8kDM5oEiy1RYw8PY= =J4kB -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- -- gentoo-dev@gentoo.org mailing list