1 |
Mike Gilbert wrote: |
2 |
|
3 |
> On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote: |
4 |
>> And again, I ask: if it were *not* about running udev without an |
5 |
>> initramfs, then why would anyone even be discussing the possibility of |
6 |
>> patching or forking? |
7 |
>> |
8 |
> |
9 |
> Here is my interpretation: the council voted on the following question: |
10 |
> |
11 |
> <ulm> The question is: "Decide on whether a separate /usr is still a |
12 |
> supported |
13 |
> configuration." |
14 |
> |
15 |
> It did not decide the method that would be used to accomplish this. A |
16 |
> few council members (Chainsaw mainly) expressed a desire to do it |
17 |
> without an initramfs, but an official stance on this was not put |
18 |
> forward. |
19 |
> |
20 |
While I agree it would be better if the vote had specified "without an |
21 |
initramfs" it seems clear to me that that was what was under discussion, |
22 |
since a) Chainsaw was asked to describe the issue and specifically turned |
23 |
down an initramfs, and b) udev with an initramfs already supports a separate |
24 |
/usr partition, so why would the Council need to vote on it? |
25 |
|
26 |
It's already supported if you use an initramfs, so there isn't anything to |
27 |
discuss, nor vote on as technical policy. |
28 |
|
29 |
> You are reading into it more that you should. |
30 |
|
31 |
Well two of the votes specifically mention initramfs: |
32 |
<Betelgeuse> As long as there is no automated help for people to |
33 |
automatically get initramfs I vote yes |
34 |
<hwoarang> i vote no, because diverting from upstream is not an ideal option |
35 |
for me |
36 |
|
37 |
If it were not about supporting users without an initramfs, why would a yes |
38 |
vote mean diverging from upstream? |
39 |
|
40 |
At this point, I'd like the Council to clarify. I really don't see what else |
41 |
could have required a vote, and the whole discussion was about not using an |
42 |
initramfs, who would maintain any patches needed, and what the potential |
43 |
consequences might be. |
44 |
|
45 |
-- |
46 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |