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@g.o>
> 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
|
