| 1 |
On Sun, Aug 18, 2013 at 2:32 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
>>>>>> On Sat, 17 Aug 2013, William Hubbs wrote: |
| 3 |
> |
| 4 |
>> The Council agrees that all preparations for dropping support |
| 5 |
>> for separate /usr without an initramfs or similar boot mechanism are |
| 6 |
>> complete. |
| 7 |
> |
| 8 |
> Why such a hurry? We have voted that we would "eventually" drop |
| 9 |
> support, and in the log you can find that we were talking about a |
| 10 |
> timeframe of six months. |
| 11 |
> |
| 12 |
> I suggest that we revisit the topic no earlier than in six months from |
| 13 |
> now. |
| 14 |
|
| 15 |
Personally I was thinking WITHIN the next six months, not taking no |
| 16 |
action for six months and then restarting the debate. |
| 17 |
|
| 18 |
I think williamh is perfectly within his rights to suggest that we're |
| 19 |
ready to go. Anybody who has a problem with his suggestion is also |
| 20 |
within their rights to state a specific objection (something |
| 21 |
actionable). |
| 22 |
|
| 23 |
I just don't see any reason for waiting, at least not right now. If |
| 24 |
the argument is that we should give users some period of time to |
| 25 |
prepare, then we should be sending out some kind of specific news item |
| 26 |
telling them what preparations to make and THEN waiting. |
| 27 |
|
| 28 |
That said, it wouldn't hurt to maybe discuss on-list some of the |
| 29 |
potential actions the council might take. |
| 30 |
|
| 31 |
1. Obviously if we don't think documentation/etc is ready then no |
| 32 |
action gets taken at all (we leave the current decision in-place). |
| 33 |
|
| 34 |
If we think docs/etc are in place there are a few different positions |
| 35 |
we could take: |
| 36 |
|
| 37 |
2. We could ask that news be sent out before the first significant |
| 38 |
change to / and there be some time period before taking action on it. |
| 39 |
(ie, we trust maintainer discretion) |
| 40 |
|
| 41 |
3. We could ask that maintainers of packages in / get council |
| 42 |
approval for each move to /usr with at least brief justification and a |
| 43 |
proposed communication plan. (ie, we don't trust maintainer |
| 44 |
discretion) |
| 45 |
|
| 46 |
4. We could tell maintainers not to make deliberate changes without |
| 47 |
individual approval, but they could WONTFIX bugs that point out small |
| 48 |
regressions/etc without approval. (ie let's not open the floodgates |
| 49 |
yet, but we can relieve some pressure on maintainers and let entropy |
| 50 |
take its course) |
| 51 |
|
| 52 |
5. With #3-4 at some point the council would decide that they've |
| 53 |
approved enough changes that further approvals are moot, and the |
| 54 |
requirement for pre-approval would be rescinded. |
| 55 |
|
| 56 |
Here is my personal take: The stated reason for dropping separate |
| 57 |
/usr support without an initramfs/etc is that this is a config that |
| 58 |
upstreams are steadily moving away from. I get that, and I don't want |
| 59 |
maintainers to have to bend over backwards to keep it working. That |
| 60 |
said, I also don't see a need to make huge overnight changes (if a |
| 61 |
maintainer thinks this is the only way to reduce their workload, |
| 62 |
please speak up). I think that this should probably be handled like |
| 63 |
the kde4 transition, or the gnome-systemd transition. That is, we |
| 64 |
provide a reasonable amount of support for the status quo until that |
| 65 |
state of affairs just isn't tenable. |
| 66 |
|
| 67 |
If anybody feels we're already at the point where supporting the |
| 68 |
status quo is untenable by all means speak up. I don't want to make |
| 69 |
maintainers work harder, but I also don't want to force changes |
| 70 |
earlier than necessary without some reason for it. |
| 71 |
|
| 72 |
That said, those who feel that we're not ready need to state a |
| 73 |
specific actionable objection. "The docs aren't ready" isn't specific |
| 74 |
or actionable. "The handbook should say xyz in this section" or "the |
| 75 |
dracut guide should specify that the usrmount module should be enabled |
| 76 |
if you have a separate /usr and how" are. |
| 77 |
|
| 78 |
Finally, I could see the /usr merge as a POSSIBLE reason to move |
| 79 |
things sooner. If somebody wants to propose some plan to make that |
| 80 |
happen they should do so, and we can debate it on this list and so on. |
| 81 |
However, I don't see any value in moving a bunch of stuff around |
| 82 |
purely for the sake of a /usr merge when there isn't any plan to |
| 83 |
finish the work. If anybody is thinking about that being the driver |
| 84 |
they need to have a plan that actually gets us to the end goal, and of |
| 85 |
course we need to agree that this is even a goal we want to have. |
| 86 |
|
| 87 |
Rich |
Archives