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 <willi...@gentoo.org> > wrote: >> here is the udev 181 unmasking news item. >> >> If all goes well, this will be committed to the tree on 3/14 UTC. > > 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 nice step-by-step upgrade guide. In general, ~arch users are expected to be able to take care of themselves to a large degree, while stable users, pretty much simply need to know how to follow the step-by-step instructions in the handbook well enough to get a running system. Thus, for critical upgrades that are likely to leave the system unbootable if they're not handled correctly, they need and gentoo has in the past normally provided, a nice step-by-step upgrade guide. It's a tall order in some ways, and I /think/ the baselayout-2/openrc upgrade broke that tradition to some extent as it was unmasked to stable before the docs were done properly, but that's in the past now and should remain the exception. That is, unless we're prepared to change the definition of stable (or even simply get rid of it entirely, referring people that need it to arch or some other distro), and if we're doing that, there really should be a discussion about it and a proper decision, council or even full active dev vote, story on the gentoo.org front page, etc. As I run ~arch anyway, I personally would certainly not oppose such an idea, but we shouldn't just let gentoo slip into it; if it's going to happen, it 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 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 for exactly that reason, even for ~arch, perhaps /especially/ for ~arch, since the nice upgrade guide isn't there yet. Yes, that means delaying the unmasking at this point, but it can be done well, or it can be done haphazardly. Actually, ideally, there'd be a good start on the upgrade guide for ~arch as well, tho it wouldn't need to be perfect. Then ~arch users could be more effectively encouraged to do what they're /supposed/ to do, report bugs when things don't go well, so they can be fixed before unmasking to stable, for the upgrade guide that goes along with it, too! =:^) But that's simply the ideal. ~arch users should be able to take care of themselves, given a few days notice, anyway. Using them to help debug the upgrade doc at the same time is indeed the ideal, but regardless of that, arch users should still get by, the chance to use them to debug 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 weeks early, with the "strong recommendation" for those with a separate /usr to get the initramfs up and working BEFORE udev-181 is unmasked, and 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 the stabilizing, nor the one that will have to deal with the bugs, etc. So just IMO. -- 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
