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.62) (envelope-from ) id 1HkLr6-0006pL-8t for garchives@archives.gentoo.org; Sat, 05 May 2007 15:07:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l45F6VuV018085; Sat, 5 May 2007 15:06:31 GMT Received: from smtp.ferdyx.org (170.Red-213-96-222.staticIP.rima-tde.net [213.96.222.170]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l45F4XeR015803 for ; Sat, 5 May 2007 15:04:34 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.ferdyx.org (Postfix) with ESMTP id 258938D316 for ; Sat, 5 May 2007 16:30:17 +0200 (CEST) Received: from smtp.ferdyx.org ([127.0.0.1]) by localhost (tungsteno [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21915-03 for ; Sat, 5 May 2007 16:30:08 +0200 (CEST) Received: from snowflake (unknown [62.6.163.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ferdyx.org (Postfix) with ESMTP id 7071A8D305 for ; Sat, 5 May 2007 16:30:07 +0200 (CEST) Date: Sat, 5 May 2007 16:03:30 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [news-item] Paludis 0.24 Message-ID: <20070505160330.0a1c2b4f@snowflake> In-Reply-To: <200705051640.13406.philantrop@gentoo.org> References: <200705042249.48267.peper@gentoo.org> <200705051605.12269.philantrop@gentoo.org> <20070505151425.546a9437@snowflake> <200705051640.13406.philantrop@gentoo.org> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.9; i686-pc-linux-gnu) 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; boundary=Sig_NXvp0QrV21V2AK.ovHrEZFH; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ferdyx.org X-Archives-Salt: 9bf2f0b6-8d4d-4fc7-a9c7-0e59e2d5902b X-Archives-Hash: 5b63642623fe95aa3c26eaf169f58d4c --Sig_NXvp0QrV21V2AK.ovHrEZFH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 5 May 2007 16:40:12 +0200 "Wulf C. Krueger" wrote: > On Saturday, May 5, 2007 04:14:25 PM Ciaran McCreesh wrote: > > > Currently, there are two news item in the Paludis overlay. Unless > > > earlier ones were removed, those two seem to be a fairly small > > > sample to deduce anything from. > > They were. >=20 > How many news items did you issue? (It's probably easier for you to > say instead of me searching the entire history of the overlay. :-) ) Er, four iirc. > Which are those "serious upgrade or compatibility problems" you're > trying to avoid? Paludis warned about the change at runtime only. For > "serious problems" I'm sure you'd make it error out, wouldn't you? The serious problem is a lot of deprecation warning notices. We know from the last couple of times that we made changes to the configuration format (once with a news item, once without) that users are much happier when they do get a news item. > > > The real problem with issuing news items for trivial changes is > > > that people will just start marking such news items read without > > > really reading them or even stop synching news items completely. > > This is not a trivial change. >=20 > (Could you please try to argument instead of just making statements?) It's a simple fact, not an argument. > The old configuration format still works. Thus, from a user's point > of view, it is a trivial change. Using the old configuration format leads to noisy warnings. Users don't like noisy warnings. They like explanations for this kind of change. > > > Then, elog and friends would be fully sufficient for informing > > > users about such configuration changes - under the circumstances > > > of this case at least. > > We already know from similar cases that this isn't true. >=20 > Yes, you've been repeating that over and over. At least one example > would probably help to understand the point you're trying to make. We've done two changes of this nature previously. The first change was for eclassdir -> eclassdirs and profile -> profiles (with a similar backwards compatible deprecation warning, not a breakage). We issued a news item for it. It was well received by end users, many of whom commented that they appreciated the notice and hoped that the delivery mechanism would be used more in the future. There were no complaints about the news item being a waste of their time. The second change was in how we handled wildcarding in keywords.conf. There was no news item, only release notes and postinst notices. Users were upset that they weren't notified about the change, even though they were, and it lead to a bunch of spurious support requests and bug reports. Hence my point: every single user who has commented upon the news items we've delivered has done so positively, and the nature of Paludis means we receive more accurate user feedback than maintainers of most other packages. All evidence currently available suggests that this approach is the best option. Once it's been tried to a wider audience there will be more evidence available and we can and will reassess the decision to see if there are ways of improving the process before it gets used for something of much wider importance and scope. The only real problem here is that GLEP 42 doesn't include a Display-If-Upgrading-From-To: header. This was a deliberate design decision, to avoid imposing substantially higher complexity requirements upon the package manager -- the workaround is to use Display-If-Installed: >=3Dwhatever and remove the news item once it is reasonably expected to be no longer relevant. This isn't ideal, but given the delays in Portage implementing even simple support it was probably the right decision for a 1.0 news item specification. --=20 Ciaran McCreesh --Sig_NXvp0QrV21V2AK.ovHrEZFH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGPJzE96zL6DUtXhERAnKJAJ970dvZdt8qU3uctdugn9bXAs6+EACgqsM7 NBON/Ocr9PENT1AF3G27HlI= =+aiC -----END PGP SIGNATURE----- --Sig_NXvp0QrV21V2AK.ovHrEZFH-- -- gentoo-dev@gentoo.org mailing list