[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan <1i5t5.duncan@cox.net>]

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 <williamh@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