| 1 |
Rich Freeman posted on Sat, 10 Mar 2012 21:53:25 -0500 as excerpted: |
| 2 |
|
| 3 |
> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@g.o> |
| 4 |
> wrote: |
| 5 |
>> here is the udev 181 unmasking news item. |
| 6 |
>> |
| 7 |
>> If all goes well, this will be committed to the tree on 3/14 UTC. |
| 8 |
> |
| 9 |
> I guess this might be OK for unstable, but before this goes stable we |
| 10 |
> really need to improve the docs around this. |
| 11 |
|
| 12 |
Definitely agreed. Before it's unmasked to stable, there should be a |
| 13 |
nice step-by-step upgrade guide. In general, ~arch users are expected to |
| 14 |
be able to take care of themselves to a large degree, while stable users, |
| 15 |
pretty much simply need to know how to follow the step-by-step |
| 16 |
instructions in the handbook well enough to get a running system. Thus, |
| 17 |
for critical upgrades that are likely to leave the system unbootable if |
| 18 |
they're not handled correctly, they need and gentoo has in the past |
| 19 |
normally provided, a nice step-by-step upgrade guide. |
| 20 |
|
| 21 |
It's a tall order in some ways, and I /think/ the baselayout-2/openrc |
| 22 |
upgrade broke that tradition to some extent as it was unmasked to stable |
| 23 |
before the docs were done properly, but that's in the past now and should |
| 24 |
remain the exception. |
| 25 |
|
| 26 |
That is, unless we're prepared to change the definition of stable (or |
| 27 |
even simply get rid of it entirely, referring people that need it to arch |
| 28 |
or some other distro), and if we're doing that, there really should be a |
| 29 |
discussion about it and a proper decision, council or even full active |
| 30 |
dev vote, story on the gentoo.org front page, etc. As I run ~arch |
| 31 |
anyway, I personally would certainly not oppose such an idea, but we |
| 32 |
shouldn't just let gentoo slip into it; if it's going to happen, it |
| 33 |
should be a deliberate decision taken after a discussion on the merits. |
| 34 |
|
| 35 |
> I'm not really asking for automation here - just documentation and |
| 36 |
> reasonable stability in how things work. |
| 37 |
|
| 38 |
Exactly. |
| 39 |
|
| 40 |
> Again, this is likely more of a concern before this is stabilized. |
| 41 |
|
| 42 |
Right, but as it's headed for ~arch now, this is the time to get planning |
| 43 |
for stabilization. |
| 44 |
|
| 45 |
> However, knowing what I went through to get my bind-mounted /usr on |
| 46 |
> LVM+mdraid working with dracut, I can imagine that any unstable users |
| 47 |
> with tricky setups could face a fun weekend. |
| 48 |
|
| 49 |
Yes, indeed. I'd actually suggest a 1-2 week advance notice news item |
| 50 |
for exactly that reason, even for ~arch, perhaps /especially/ for ~arch, |
| 51 |
since the nice upgrade guide isn't there yet. Yes, that means delaying |
| 52 |
the unmasking at this point, but it can be done well, or it can be done |
| 53 |
haphazardly. |
| 54 |
|
| 55 |
Actually, ideally, there'd be a good start on the upgrade guide for ~arch |
| 56 |
as well, tho it wouldn't need to be perfect. Then ~arch users could be |
| 57 |
more effectively encouraged to do what they're /supposed/ to do, report |
| 58 |
bugs when things don't go well, so they can be fixed before unmasking to |
| 59 |
stable, for the upgrade guide that goes along with it, too! =:^) |
| 60 |
|
| 61 |
But that's simply the ideal. ~arch users should be able to take care of |
| 62 |
themselves, given a few days notice, anyway. Using them to help debug |
| 63 |
the upgrade doc at the same time is indeed the ideal, but regardless of |
| 64 |
that, arch users should still get by, the chance to use them to debug |
| 65 |
corner-cases in the docs before unmasking to stable, is just lost. |
| 66 |
|
| 67 |
> Perhaps a suggestion for the news item. I'd recommend that anybody who |
| 68 |
> needs an initramfs to mount /usr get that working BEFORE they upgrade |
| 69 |
> udev. This situation is a heck of a lot easier to figure out if the |
| 70 |
> system still can be booted when the initramfs doesn't work. |
| 71 |
|
| 72 |
Yes. This is another reason to put the news item out there a couple |
| 73 |
weeks early, with the "strong recommendation" for those with a separate |
| 74 |
/usr to get the initramfs up and working BEFORE udev-181 is unmasked, and |
| 75 |
a couple weeks lead time on the news item, in ordered to let them do it. |
| 76 |
|
| 77 |
IMO, I'm not the package maintainer or the arch folks that will be doing |
| 78 |
the stabilizing, nor the one that will have to deal with the bugs, etc. |
| 79 |
So just IMO. |
| 80 |
|
| 81 |
-- |
| 82 |
Duncan - List replies preferred. No HTML msgs. |
| 83 |
"Every nonfree program has a lord, a master -- |
| 84 |
and if you use the program, he is your master." Richard Stallman |
Archives