From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S6bee-0004am-7E for garchives@archives.gentoo.org; Sun, 11 Mar 2012 05:49:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05474E07BB; Sun, 11 Mar 2012 05:49:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5E5BBE07B1 for ; Sun, 11 Mar 2012 05:48:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D4BEA1B402C for ; Sun, 11 Mar 2012 05:48:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5.5 tests=[AWL=-0.617, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tqpxht9HjGH for ; Sun, 11 Mar 2012 05:48:33 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D1A4F1B4029 for ; Sun, 11 Mar 2012 05:48:32 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S6bdo-0004K0-Fo for gentoo-dev@gentoo.org; Sun, 11 Mar 2012 06:48:24 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Mar 2012 06:48:24 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Mar 2012 06:48:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: newsitem: unmasking udev-181 Date: Sun, 11 Mar 2012 05:48:13 +0000 (UTC) Message-ID: References: <20120311022706.GA26296@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 0efefbf /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 36ec89cd-043d-4343-937d-94e78a5ca60b X-Archives-Hash: ba025f0cd672d9cb6b0b9aad4a321a63 Rich Freeman posted on Sat, 10 Mar 2012 21:53:25 -0500 as excerpted: > On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs > wrote: >> here is the udev 181 unmasking news item. >> >> If all goes well, this will be committed to the tree =C2=A0on 3/14 UTC= . >=20 > I guess this might be OK for unstable, but before this goes stable we > really need to improve the docs around this. Definitely agreed. Before it's unmasked to stable, there should be a=20 nice step-by-step upgrade guide. In general, ~arch users are expected to= =20 be able to take care of themselves to a large degree, while stable users,= =20 pretty much simply need to know how to follow the step-by-step=20 instructions in the handbook well enough to get a running system. Thus,=20 for critical upgrades that are likely to leave the system unbootable if=20 they're not handled correctly, they need and gentoo has in the past=20 normally provided, a nice step-by-step upgrade guide. It's a tall order in some ways, and I /think/ the baselayout-2/openrc=20 upgrade broke that tradition to some extent as it was unmasked to stable=20 before the docs were done properly, but that's in the past now and should= =20 remain the exception. That is, unless we're prepared to change the definition of stable (or=20 even simply get rid of it entirely, referring people that need it to arch= =20 or some other distro), and if we're doing that, there really should be a=20 discussion about it and a proper decision, council or even full active=20 dev vote, story on the gentoo.org front page, etc. As I run ~arch=20 anyway, I personally would certainly not oppose such an idea, but we=20 shouldn't just let gentoo slip into it; if it's going to happen, it=20 should be a deliberate decision taken after a discussion on the merits. > I'm not really asking for automation here - just documentation and > reasonable stability in how things work. Exactly. > Again, this is likely more of a concern before this is stabilized. Right, but as it's headed for ~arch now, this is the time to get planning= =20 for stabilization. > However, knowing what I went through to get my bind-mounted /usr on > LVM+mdraid working with dracut, I can imagine that any unstable users > with tricky setups could face a fun weekend. Yes, indeed. I'd actually suggest a 1-2 week advance notice news item=20 for exactly that reason, even for ~arch, perhaps /especially/ for ~arch,=20 since the nice upgrade guide isn't there yet. Yes, that means delaying=20 the unmasking at this point, but it can be done well, or it can be done=20 haphazardly. Actually, ideally, there'd be a good start on the upgrade guide for ~arch= =20 as well, tho it wouldn't need to be perfect. Then ~arch users could be=20 more effectively encouraged to do what they're /supposed/ to do, report=20 bugs when things don't go well, so they can be fixed before unmasking to=20 stable, for the upgrade guide that goes along with it, too! =3D:^) But that's simply the ideal. ~arch users should be able to take care of=20 themselves, given a few days notice, anyway. Using them to help debug=20 the upgrade doc at the same time is indeed the ideal, but regardless of=20 that, arch users should still get by, the chance to use them to debug=20 corner-cases in the docs before unmasking to stable, is just lost. > Perhaps a suggestion for the news item. I'd recommend that anybody who > needs an initramfs to mount /usr get that working BEFORE they upgrade > udev. This situation is a heck of a lot easier to figure out if the > system still can be booted when the initramfs doesn't work. Yes. This is another reason to put the news item out there a couple=20 weeks early, with the "strong recommendation" for those with a separate=20 /usr to get the initramfs up and working BEFORE udev-181 is unmasked, and= =20 a couple weeks lead time on the news item, in ordered to let them do it. IMO, I'm not the package maintainer or the arch folks that will be doing=20 the stabilizing, nor the one that will have to deal with the bugs, etc. =20 So just IMO. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman