[gentoo-project] rfc: separate /usr preparation vote

[gentoo-project] rfc: separate /usr preparation vote

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Council members,

After looking over the documentation I know about [1] [2] [3], I think
it is safe to Say we are prepared to move forward with stating that the
	preparations for early boot mechanisms are complete. So, I am asking
	the council to bring the following statement to a vote in the next
	meeting:

	The Council agrees that all preparations for dropping support for
	separate /usr without an initramfs or similar boot mechanism are
	complete.

If anyone reading this disagrees about the preparations being complete,
please file bugs and make them block the tracker [4] before the next
meeting.

Thanks,

William

[1] http://www.gentoo.org/doc/en/initramfs-guide.xml
[2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
[3] https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
[4] https://bugs.gentoo.org/show_bug.cgi?id=481202

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] rfc: separate /usr preparation vote

[Ulrich Mueller]

>>>>> On Sat, 17 Aug 2013, William Hubbs wrote:

> 	The Council agrees that all preparations for dropping support
> for separate /usr without an initramfs or similar boot mechanism are
> complete.

Why such a hurry? We have voted that we would "eventually" drop
support, and in the log you can find that we were talking about a
timeframe of six months.

I suggest that we revisit the topic no earlier than in six months from
now.

Ulrich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Sun, Aug 18, 2013 at 2:32 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sat, 17 Aug 2013, William Hubbs wrote:
>
>>       The Council agrees that all preparations for dropping support
>> for separate /usr without an initramfs or similar boot mechanism are
>> complete.
>
> Why such a hurry? We have voted that we would "eventually" drop
> support, and in the log you can find that we were talking about a
> timeframe of six months.
>
> I suggest that we revisit the topic no earlier than in six months from
> now.

Personally I was thinking WITHIN the next six months, not taking no
action for six months and then restarting the debate.

I think williamh is perfectly within his rights to suggest that we're
ready to go.  Anybody who has a problem with his suggestion is also
within their rights to state a specific objection (something
actionable).

I just don't see any reason for waiting, at least not right now.  If
the argument is that we should give users some period of time to
prepare, then we should be sending out some kind of specific news item
telling them what preparations to make and THEN waiting.

That said, it wouldn't hurt to maybe discuss on-list some of the
potential actions the council might take.

1.  Obviously if we don't think documentation/etc is ready then no
action gets taken at all (we leave the current decision in-place).

If we think docs/etc are in place there are a few different positions
we could take:

2.  We could ask that news be sent out before the first significant
change to / and there be some time period before taking action on it.
(ie, we trust maintainer discretion)

3.  We could ask that maintainers of packages in / get council
approval for each move to /usr with at least brief justification and a
proposed communication plan.  (ie, we don't trust maintainer
discretion)

4.  We could tell maintainers not to make deliberate changes without
individual approval, but they could WONTFIX bugs that point out small
regressions/etc without approval.  (ie let's not open the floodgates
yet, but we can relieve some pressure on maintainers and let entropy
take its course)

5.  With #3-4 at some point the council would decide that they've
approved enough changes that further approvals are moot, and the
requirement for pre-approval would be rescinded.

Here is my personal take:  The stated reason for dropping separate
/usr support without an initramfs/etc is that this is a config that
upstreams are steadily moving away from.  I get that, and I don't want
maintainers to have to bend over backwards to keep it working.  That
said, I also don't see a need to make huge overnight changes (if a
maintainer thinks this is the only way to reduce their workload,
please speak up).  I think that this should probably be handled like
the kde4 transition, or the gnome-systemd transition.  That is, we
provide a reasonable amount of support for the status quo until that
state of affairs just isn't tenable.

If anybody feels we're already at the point where supporting the
status quo is untenable by all means speak up.  I don't want to make
maintainers work harder, but I also don't want to force changes
earlier than necessary without some reason for it.

That said, those who feel that we're not ready need to state a
specific actionable objection.  "The docs aren't ready" isn't specific
or actionable.  "The handbook should say xyz in this section" or "the
dracut guide should specify that the usrmount module should be enabled
if you have a separate /usr and how" are.

Finally, I could see the /usr merge as a POSSIBLE reason to move
things sooner.  If somebody wants to propose some plan to make that
happen they should do so, and we can debate it on this list and so on.
 However, I don't see any value in moving a bunch of stuff around
purely for the sake of a /usr merge when there isn't any plan to
finish the work.  If anybody is thinking about that being the driver
they need to have a plan that actually gets us to the end goal, and of
course we need to agree that this is even a goal we want to have.

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 6181 bytes --]

On Sun, Aug 18, 2013 at 07:37:53AM -0400, Rich Freeman wrote:
> On Sun, Aug 18, 2013 at 2:32 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>>> On Sat, 17 Aug 2013, William Hubbs wrote:
> >
> >>       The Council agrees that all preparations for dropping support
> >> for separate /usr without an initramfs or similar boot mechanism are
> >> complete.
> >
> > Why such a hurry? We have voted that we would "eventually" drop
> > support, and in the log you can find that we were talking about a
> > timeframe of six months.
> >
> > I suggest that we revisit the topic no earlier than in six months from
> > now.
> 
> Personally I was thinking WITHIN the next six months, not taking no
> action for six months and then restarting the debate.
> 
> I think williamh is perfectly within his rights to suggest that we're
> ready to go.  Anybody who has a problem with his suggestion is also
> within their rights to state a specific objection (something
> actionable).

Correct, there is no reason to wait six months just for the sake of
waiting six months. One bug was filed against the tracker and fixed
within hours.
 
> I just don't see any reason for waiting, at least not right now.  If
> the argument is that we should give users some period of time to
> prepare, then we should be sending out some kind of specific news item
> telling them what preparations to make and THEN waiting.

The vote is to make sure all of the necessary documentation is in place,
so this isn't really part of it. But, yes, once this vote passes,
communication to users as the changes happen will be important.

> If we think docs/etc are in place there are a few different positions
> we could take:
> 
> 2.  We could ask that news be sent out before the first significant
> change to / and there be some time period before taking action on it.
> (ie, we trust maintainer discretion)

There aren't going to be that many maintainers involved in this (mostly
it is base-system and toolchain), so I think this is the best route to
take. We are not here to micromanage maintainers.

> 3.  We could ask that maintainers of packages in / get council
> approval for each move to /usr with at least brief justification and a
> proposed communication plan.  (ie, we don't trust maintainer
> discretion)

I think this would be a waste of time for maintainers and for us. Do we
really want to micro-manage this and have maintainers bring individual
packages to the council to get this type of approval?

> 4.  We could tell maintainers not to make deliberate changes without
> individual approval, but they could WONTFIX bugs that point out small
> regressions/etc without approval.  (ie let's not open the floodgates
> yet, but we can relieve some pressure on maintainers and let entropy
> take its course)

This is saying the same thing you said in #3. Don't do anything without
approval. and I'm against this because I don't think we should
micromanage.

> Here is my personal take:  The stated reason for dropping separate
> /usr support without an initramfs/etc is that this is a config that
> upstreams are steadily moving away from.  I get that, and I don't want
> maintainers to have to bend over backwards to keep it working.  That
> said, I also don't see a need to make huge overnight changes (if a
> maintainer thinks this is the only way to reduce their workload,
> please speak up).  I think that this should probably be handled like
> the kde4 transition, or the gnome-systemd transition.  That is, we
> provide a reasonable amount of support for the status quo until that
> state of affairs just isn't tenable.

The problem is, there already is subtile breakage in the status quo. for
example, anything that tries to read from /usr/share/* in early boot,
before /usr is mounted, is broken by definition, and any binary in /
that tries to link to a library in /usr/lib* too early will fail.

> If anybody feels we're already at the point where supporting the
> status quo is untenable by all means speak up.  I don't want to make
> maintainers work harder, but I also don't want to force changes
> earlier than necessary without some reason for it.

It is true that a lot of it is boiler plate (copy/paste), but we are
doing a lot of things with ebuilds to make /usr sort of work. There have
also been specific bugs in the past, requesting that we move packages to
/ to accomodate this separate /usr configuration that sort of works like
https://bugs.gentoo.org/show_bug.cgi?id=443710. Samuli was right on this
bug initially, but there was no decision from council to stand on, so
the folks who wanted it in / were able to push it through. Things like
this should be undone, and the way to do it is with initramfs.

Basically the status quo includes specific changes that were made in
our packaging to allow this sort of working separate /usr without
initramfs configuration to continue limping along, but we need to undo
them.

> That said, those who feel that we're not ready need to state a
> specific actionable objection.  "The docs aren't ready" isn't specific
> or actionable.  "The handbook should say xyz in this section" or "the
> dracut guide should specify that the usrmount module should be enabled
> if you have a separate /usr and how" are.
> 
> Finally, I could see the /usr merge as a POSSIBLE reason to move
> things sooner.  If somebody wants to propose some plan to make that
> happen they should do so, and we can debate it on this list and so on.
>  However, I don't see any value in moving a bunch of stuff around
> purely for the sake of a /usr merge when there isn't any plan to
> finish the work.  If anybody is thinking about that being the driver
> they need to have a plan that actually gets us to the end goal, and of
> course we need to agree that this is even a goal we want to have.

The /usr merge is a totally separate issue that I really don't want to
bring into this discussion. There are people who are fine with us
cleaning up the separate /usr issue, but opposed to the /usr merge, so
that needs to be a separate item imo.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Sun, Aug 18, 2013 at 10:48 PM, William Hubbs <williamh@gentoo.org> wrote:
> Basically the status quo includes specific changes that were made in
> our packaging to allow this sort of working separate /usr without
> initramfs configuration to continue limping along, but we need to undo
> them.

Why do we have to undo them?

I can understand that implementing them was a waste of time, but that
time is already wasted.  Does it take much effort to maintain the
fixes?  For all I know they do - but could you articulate this?

I fully support that we should stop doing any more work to keep a
separate /usr working without an initramfs.  My question is why do we
need to start undoing the work that has already been done?

If you can point to some package where everytime upstream does a bump
you have to redo 47 patches to keep it working in / but it would just
work effortlessly if it were in /usr, that would be a great argument
to move it back to /usr on the next bump.  Maybe there is something
else which is causing you to waste time.

I'd just like to hear a driver for reverting the work that was already
done.  I fully get the argument that the work shouldn't have been
required in the first place.  What I don't get is now that the effort
is sunk why it needs to be ditched.  I think many would like to
understand the drivers here.

Otherwise it seems to me like the best path forward is to stop making
new fixes, but just hang onto the ones we have until they no longer
work.  At some point upstream will make a change that forces our hand,
but why not wait until then?  What does it cost us to wait?

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2013 11:10 PM, Rich Freeman wrote:
> On Sun, Aug 18, 2013 at 10:48 PM, William Hubbs <williamh@gentoo.org> wrote:
>> Basically the status quo includes specific changes that were made in
>> our packaging to allow this sort of working separate /usr without
>> initramfs configuration to continue limping along, but we need to undo
>> them.
> 
> Why do we have to undo them?
> 
> I can understand that implementing them was a waste of time, but that
> time is already wasted.  Does it take much effort to maintain the
> fixes?  For all I know they do - but could you articulate this?
> 
> I fully support that we should stop doing any more work to keep a
> separate /usr working without an initramfs.  My question is why do we
> need to start undoing the work that has already been done?

Because, the work that has already been done makes no bloody sense.
bzip2 is in / but not xz or lbzip2.

The cruelest prank of all of this bullspit, systemd is installed in /
despite many upstreams hardcoding THE CORRECT LOCATION of /usr.  Yeah,
that's right, we are moving things to / and breaking systems and then
upstream just laughs at us when we report bugs.

It is not possible to keep systems running like this, and it is HARMING
us to even try.  Please, stop moving things from /usr to /, and please
move things back where upstream expects them.  Honestly I'm considering
a /usr merge on my system just to stop all this stupidity from breaking
my system.

v/r
Zero
> 
> If you can point to some package where everytime upstream does a bump
> you have to redo 47 patches to keep it working in / but it would just
> work effortlessly if it were in /usr, that would be a great argument
> to move it back to /usr on the next bump.  Maybe there is something
> else which is causing you to waste time.
> 
> I'd just like to hear a driver for reverting the work that was already
> done.  I fully get the argument that the work shouldn't have been
> required in the first place.  What I don't get is now that the effort
> is sunk why it needs to be ditched.  I think many would like to
> understand the drivers here.
> 
> Otherwise it seems to me like the best path forward is to stop making
> new fixes, but just hang onto the ones we have until they no longer
> work.  At some point upstream will make a change that forces our hand,
> but why not wait until then?  What does it cost us to wait?
> 
> Rich
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEZWCAAoJEKXdFCfdEflKc9sP/Armqjz2WhZ6hl69dHoY1+Fg
ccsXjGYPr6JzR/ILmxq+WXOTJWOO+n/99c6Hmsg0nWxSrMyRLptMF3R3BxPeU6Me
2NsbqVmaer1P45hVbYpGga2M3sCzLaSEtNfMpH40dzPsoeheIBq9T/lajNqsTvIK
0gp+o7A4Hf7JGS9QRI6Je6VWTZ0TDhmlhenDPgFVcgujP3QJIHUFQOMdomXh05Wh
NZ0ib+7+NeNoi1RUWx9TgizmFeWXx3uTMz3RMfI9C3Ca5/9F0Vwdpz2dI4PetlgX
iwAhRYGi67QseIy+2Uod4Cfzhs0NfsIHEWvgigweO+cx0NFCKHNqShgAYjs6D6t5
0e3+jTlgT408N3gSOGFDs2mUFDzDkhY5KQa8wDqzPWPQrxQOjXWFCXo8EzTDOsKt
mIrbduZLp5PWj9E+5aiL6YTB8ZeDDeCfZLRmqqUNTq8GCnPFWTe7uGo1l23iq8OS
YLlHeYR3o6X8KnssxqdXKI613O/PWybhFIdJgyRG+HNj0MwRToGMYmCV5s5QGMSH
J4YaueOldKNsEbQg4HEHezNUy14wH28YAb9MQF4oEwc2UvGvINbNUl90Y+xEMUO4
ArFLZZLneAw1h7v7BWm135OjQwMxlgTRhZf/mhwYijxtCiy/CqyOzpBcId9RMGGo
ea4cy1EbQPI9MlLqafzs
=mOuO
-----END PGP SIGNATURE-----

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Sun, Aug 18, 2013 at 11:48 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> On 08/18/2013 11:10 PM, Rich Freeman wrote:
>> On Sun, Aug 18, 2013 at 10:48 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> Basically the status quo includes specific changes that were made in
>>> our packaging to allow this sort of working separate /usr without
>>> initramfs configuration to continue limping along, but we need to undo
>>> them.
>>
>> Why do we have to undo them?
>>
>> I can understand that implementing them was a waste of time, but that
>> time is already wasted.  Does it take much effort to maintain the
>> fixes?  For all I know they do - but could you articulate this?
>>
>> I fully support that we should stop doing any more work to keep a
>> separate /usr working without an initramfs.  My question is why do we
>> need to start undoing the work that has already been done?
>
> Because, the work that has already been done makes no bloody sense.
> bzip2 is in / but not xz or lbzip2.

As I said, I fully agree that the work that was already done makes no
sense.  The question is whether undoing that work makes any sense.  If
a city takes tax dollars to build a huge stadium I think that makes no
sense.  On the other hand once a stadium is built tearing it down
makes no sense either - what is done is done.

>
> The cruelest prank of all of this bullspit, systemd is installed in /
> despite many upstreams hardcoding THE CORRECT LOCATION of /usr.  Yeah,
> that's right, we are moving things to / and breaking systems and then
> upstream just laughs at us when we report bugs.

I said that I think anything not stable a year ago should be free to
do whatever, which would include systemd.  I don't think anybody who
has been vocal on the issue really objects to moving systemd to /usr
(and if you're going to move it you might as well do it before all the
gnome users switch).

>
> It is not possible to keep systems running like this, and it is HARMING
> us to even try.  Please, stop moving things from /usr to /, and please
> move things back where upstream expects them.  Honestly I'm considering
> a /usr merge on my system just to stop all this stupidity from breaking
> my system.

Can you give specific examples of how the current state of affairs is
causing problems (especially for something other than systemd)?  That
is really what I'm getting at.  I am fully capable of believing that
moving stuff to / could be causing issues - I just haven't seen a
single example on the lists in these discussions pointing one out.

If you could point out some specific examples I think that this would
really help your case.  I'm pretty sympathetic to your arguments but
even I'm on the fence about moving things back (as opposed to merely
stopping the continued flow of stuff to /), and I suspect many on the
Council will be far more skeptical.  Some concrete examples of
problems would probably go a long way to convincing everybody.

If this is only about systemd feel free to point out some examples
anyway so that we can at least get a vote to clarify whether systemd
can move apart from the rest.

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Sven Vermeulen]

On Sun, Aug 18, 2013 at 09:48:09PM -0500, William Hubbs wrote:
> > I just don't see any reason for waiting, at least not right now.  If
> > the argument is that we should give users some period of time to
> > prepare, then we should be sending out some kind of specific news item
> > telling them what preparations to make and THEN waiting.
> 
> The vote is to make sure all of the necessary documentation is in place,
> so this isn't really part of it. But, yes, once this vote passes,
> communication to users as the changes happen will be important.

Documentation can always be improved, but I do feel it is up to the task
already. We document how to create an initramfs using genkernel (which is
dead easy) and mention several times that a separate /usr (or root on LVM)
requires an initramfs.

All our examples use the initramfs as well.

> > Finally, I could see the /usr merge as a POSSIBLE reason to move
> > things sooner.  If somebody wants to propose some plan to make that
> > happen they should do so, and we can debate it on this list and so on.
> >  However, I don't see any value in moving a bunch of stuff around
> > purely for the sake of a /usr merge when there isn't any plan to
> > finish the work.  If anybody is thinking about that being the driver
> > they need to have a plan that actually gets us to the end goal, and of
> > course we need to agree that this is even a goal we want to have.
> 
> The /usr merge is a totally separate issue that I really don't want to
> bring into this discussion. There are people who are fine with us
> cleaning up the separate /usr issue, but opposed to the /usr merge, so
> that needs to be a separate item imo.

Yes please; merging / <-> /usr has impact beyond just documentation and
initramfs. For SELinux for instance, that means our policies will need to be
adjusted so all /bin/* contexts also get assigned to /usr/bin (and /sbin to
/usr/sbin) and symlinks are "accepted" where they are currently not.

I think for such a merger, we'll need to know what will be the goal, and set
steps in that direction that make it so a transition is not full-park,
big-bang, but rather gradually with little to no end user involvement
(step-wise).

Wkr,
	Sven Vermeulen

Re: [gentoo-project] rfc: separate /usr preparation vote

[Ulrich Mueller]

>>>>> On Sun, 18 Aug 2013, William Hubbs wrote:

> Basically the status quo includes specific changes that were made in
> our packaging to allow this sort of working separate /usr without
> initramfs configuration to continue limping along, but we need to
> undo them.

Let's have a vote in the next meeting if such action is to be allowed.

Ulrich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 19/08/13 02:30 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 18 Aug 2013, William Hubbs wrote:
> 
>> Basically the status quo includes specific changes that were made
>> in our packaging to allow this sort of working separate /usr
>> without initramfs configuration to continue limping along, but we
>> need to undo them.
> 
> Let's have a vote in the next meeting if such action is to be
> allowed.
> 
> Ulrich
> 

I think it might be pertinent to note that the original vote on
separate-/usr last year was as much (if not more) about ensuring the
current workarounds are not undone as they were about getting new
changes approved/accepted.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlISHxcACgkQ2ugaI38ACPAuaQD+LUVR02HglTsa7d04Vgyp1L6R
6PlCQI/CKJrfcE2NuVoA/jFOdwOpuvNe+2EpJ/lp6ddV3mDGY1aLa29rspmyYga1
=y8iw
-----END PGP SIGNATURE-----

Re: [gentoo-project] rfc: separate /usr preparation vote

[Anthony G. Basile]

On 08/18/2013 02:32 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Aug 2013, William Hubbs wrote:
>
>> 	The Council agrees that all preparations for dropping support
>> for separate /usr without an initramfs or similar boot mechanism are
>> complete.
>
> Why such a hurry? We have voted that we would "eventually" drop
> support, and in the log you can find that we were talking about a
> timeframe of six months.
>
> I suggest that we revisit the topic no earlier than in six months from
> now.
>
> Ulrich
>

ditto.  I want this debated in the community, ie, I want to hear the 
community say "all the preperation for dropping support ... are complete".

--Tony

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Sun, Aug 18, 2013 at 9:08 AM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
>
> ditto.  I want this debated in the community, ie, I want to hear the
> community say "all the preperation for dropping support ... are complete".

The community will never say that, just like no community ever said
"hey, we need a source-based linux distro!"

Progress and change gets initiated by individuals or small teams, and
the community always has to play catch up.  That's just how change and
innovation works.

The role of the community is to say why preparations AREN'T complete.
The default needs to be action, not inaction.  If we only change
things when a majority are clamoring for change, then I suggest that
anybody cares about running an interesting distro fork Gentoo now.
This isn't CentOS, and we're not going to backport patches to linux
2.4 until 95% of our customers agree that whatever proprietary blob
they're using is ready for 2.6.

Don't get me wrong - I'd love to see debate.  However, williamh made a
proposal, and if somebody wants to argue that we aren't ready yet then
they need to step up and do it.  That is how every court in the world
works, as far as I know (if you don't show up, you don't get a say).
I'm not really chomping at the bit to see stuff move to /usr, but if
people have a reason to ask for inaction, they need to voice it, and
not just ask everybody else to pass time.  If there is a reason to
hold things up I'll be the first to agree to hold things up, but there
has to be a reason, otherwise I'll probably support WONTFIXing any
separate-/usr regressions on existing packages, not putting any
restrictions on packages that weren't stable more than a year ago, and
allowing large changes to packages older than that if they can be
justified.

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Denis Dupeyron]

On Sun, Aug 18, 2013 at 7:46 AM, Rich Freeman <rich0@gentoo.org> wrote:
> That is how every court in the world works, as far as I know

Objection, Your Honor! We're not a court.

Denis.

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2013 08:18 PM, Denis Dupeyron wrote:
> On Sun, Aug 18, 2013 at 7:46 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> That is how every court in the world works, as far as I know
> 
> Objection, Your Honor! We're not a court.

Overruled. The original point is valid even if we aren't a court.  If
Williamh makes a proposal and no one presents any valid arguement then
the motion passes.

- -ZC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEWb2AAoJEKXdFCfdEflKxPUQALr0RNxslSPUXSwYu/Zj4bP4
BcKscqHGHf9jLDW3qO/XfMQAcEss9iRCn6OP70QW7sc/GfesftU7e290uQq3jTMh
G6W3aIbJB08Ba1x0Vcl0l/1WjNyF0sh9ytqVBIfOxrMyMzLDrIdXbqAkFXSAGQog
OzzDggB4I9oV+Zmzp69t3HWG+l7cqXG6aINJ/K1XFraJvgrrEo2Tivn9XTGe74uy
OqOu7xSsuckJ1YISuLMD4zNrdbLp3dbaTb4HbAXG2BuCSGExmE58/ptIbVdIDbw3
jrOi8OjRvZL2CKytNgsRaI1D49PWOBMwvjNc+1/cPD/lDpcnI/1n51wsfo+USeLW
6qT3A//i1a+eY89i9TeDtd30oY/JAWOArm/ojaaw49AOfIHKG3p97mxnma3kWLBg
P4v3VrUCTYAGEt1SfxyNWpt4jz9RZKUrTXWJUPtl1v3hWIJRbaEEg/zpLlEnlhoo
zDq4A9PF1bnaAtZeI7o2hAMxt/0UMkqxEEhksF1cI5RHs4LpIzjM96rhjL34Bilv
oHdWAzEj/eUVT974utGoQvW9NYTkwKUb5zMxiYsyJyoKENfeggZBgeGO7xJ828DF
NoBxXgXt/5QBg3my6m24L1GBJRiK0i8VfDX5PGfzHkBO/6zrrQLb/PGgpkldCfhw
B5p25jkOb5Tec17Fuwwc
=6GDU
-----END PGP SIGNATURE-----

Re: [gentoo-project] rfc: separate /usr preparation vote

[Anthony G. Basile]

On 08/18/2013 09:46 AM, Rich Freeman wrote:
> On Sun, Aug 18, 2013 at 9:08 AM, Anthony G. Basile
> <basile@opensource.dyc.edu> wrote:
>> ditto.  I want this debated in the community, ie, I want to hear the
>> community say "all the preperation for dropping support ... are complete".
> The community will never say that, just like no community ever said
> "hey, we need a source-based linux distro!"

There may be valid objects which will be silenced by the rush.  I'd like 
to hear from people whom this will directly affect, like Chainsaw.

>
> Progress and change gets initiated by individuals or small teams, and
> the community always has to play catch up.  That's just how change and
> innovation works.

This is not innovation.

>
> The role of the community is to say why preparations AREN'T complete.
> The default needs to be action, not inaction.  If we only change
> things when a majority are clamoring for change, then I suggest that
> anybody cares about running an interesting distro fork Gentoo now.
> This isn't CentOS, and we're not going to backport patches to linux
> 2.4 until 95% of our customers agree that whatever proprietary blob
> they're using is ready for 2.6.
>
> Don't get me wrong - I'd love to see debate.  However, williamh made a
> proposal, and if somebody wants to argue that we aren't ready yet then
> they need to step up and do it.

In other words, let's give the community a chance to bring forward concerns.

> That is how every court in the world
> works, as far as I know (if you don't show up, you don't get a say).
> I'm not really chomping at the bit to see stuff move to /usr, but if
> people have a reason to ask for inaction, they need to voice it, and
> not just ask everybody else to pass time.  If there is a reason to
> hold things up I'll be the first to agree to hold things up,

We are rushing this.  People need time to think of the consequences.  So 
a valid reason for waiting is that I (and probably others) haven't had 
the time to think through the consequences.  We have a 6 month window, 
why is it so important that this be done now?

> but there
> has to be a reason, otherwise I'll probably support WONTFIXing any
> separate-/usr regressions on existing packages, not putting any
> restrictions on packages that weren't stable more than a year ago, and
> allowing large changes to packages older than that if they can be
> justified.
>
> Rich
>
If this had been done in 2008, my entire teaching lab would have been 
broken.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Sun, Aug 18, 2013 at 9:40 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 08/18/2013 09:46 AM, Rich Freeman wrote:
>>
>> On Sun, Aug 18, 2013 at 9:08 AM, Anthony G. Basile
>> <basile@opensource.dyc.edu> wrote:
>>>
>>> ditto.  I want this debated in the community, ie, I want to hear the
>>> community say "all the preperation for dropping support ... are
>>> complete".
>>
>> The community will never say that, just like no community ever said
>> "hey, we need a source-based linux distro!"
>
> There may be valid objects which will be silenced by the rush.  I'd like to
> hear from people whom this will directly affect, like Chainsaw.

Then ping him.

I'd love to hear objections as well - but objections to the proposal
itself, not objections to considering it.

> In other words, let's give the community a chance to bring forward concerns.

The only way to get people to bring forward concerns is to ask them.
Nobody is going to take action unless a decision is on the agenda.
Otherwise, why bother?

> We are rushing this.  People need time to think of the consequences.  So a
> valid reason for waiting is that I (and probably others) haven't had the
> time to think through the consequences.  We have a 6 month window, why is it
> so important that this be done now?

This has been on the agenda for over a year, and the subject of three
council meetings and three votes in that timespan.

Just what time do we think we'll have in the next six months that we
didn't have in the last year?

By all means identify reasons that we're not ready to go, and get them
out on the table so that they can be resolved in the next six months.
My concern is that we'll spend the next six months doing nothing, and
THEN we'll start raising objections.

> If this had been done in 2008, my entire teaching lab would have been
> broken.

I've got news for you - there are hundreds of others systems that will
also be broken if the admins don't take action.  That will apply in
2008, 2013, or 2038.  We just agreed that the change is happening in
the next six months.  We agreed that lots of systems are going to
break if somebody doesn't do something to prevent it.  So, now the
goal is to take action to help people to prepare.

If your objection is a lack of docs, then point out what is missing in
a bug.  If your objection is a lack of news, then log a bug asking for
a news item.

If your only objection is that you need time to think about it, well,
we have 3.5 weeks before the next Council meeting, so think about
it...  I'm sure somebody will log an objection on the eve of the
meeting, so we might as well have it on the agenda so that we're not
delaying action to the eve of the meeting after that.

I already stated my perspective.  If somebody doesn't log an actual
reason to hold things up, my inclination is to give an immediate
all-clear to WONTFIX anything that is a bug today or which pertains to
a package that wasn't stable in August 2012 (at the maintainer's
discretion).  If somebody can give me a good reason for moving a
package from / to /usr then I'll be fine with allowing them to do so
as long as the first such major change includes a news item and 30
days notice.

It won't surprise me if we still end up on a six month schedule, but
I'd like it to be because we spend the next six months preparing for a
good transition, and not because we've spent six months avoiding the
issue.

I plan to also contribute by looking for other potential blockers
(I've already logged one, which I have to congratulate the docs team
for addressing in a matter of hours).

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On 2013.08.17 23:20, William Hubbs wrote:
> Council members,
> 
> After looking over the documentation I know about [1] [2] [3], I 
> think
> it is safe to Say we are prepared to move forward with stating that
> the
> 	preparations for early boot mechanisms are complete.

[snip]

> Thanks,
> 
> William
> 
> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml
> [2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-
> quickinstall.xml
> [3] https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
> [4] https://bugs.gentoo.org/show_bug.cgi?id=481202
> 

William,

If such a vote were to go in your favour, what are the next steps and 
the timescale(s) for these steps?

You clearly perceive the vote you seek as endorsing a plan of action 
relating to the /usr merge.

My apologies in advance if I have missed these details.
 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-project] rfc: separate /usr preparation vote

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/08/13 03:11 PM, Roy Bamford wrote:
> On 2013.08.17 23:20, William Hubbs wrote:
>> Council members,
>> 
>> After looking over the documentation I know about [1] [2] [3], I
>>  think it is safe to Say we are prepared to move forward with
>> stating that the preparations for early boot mechanisms are
>> complete.
> 
> [snip]
> 
>> Thanks,
>> 
>> William
>> 
>> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml [2]
>> http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2- 
>> quickinstall.xml [3]
>> https://wiki.gentoo.org/wiki/Early_Userspace_Mounting [4]
>> https://bugs.gentoo.org/show_bug.cgi?id=481202
>> 
> 
> William,
> 
> If such a vote were to go in your favour, what are the next steps
> and the timescale(s) for these steps?
> 
> You clearly perceive the vote you seek as endorsing a plan of
> action relating to the /usr merge.
> 
> My apologies in advance if I have missed these details.
> 
> 

Also #4 is still blocked, that to me would seem that we are not ready.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlIc/lQACgkQ2ugaI38ACPBDfgD/WCiLFNWFyS8aWZ963/FtKlxL
SmsyE7YcorfDTIL7C0sA+wURmTE1LV337zrEl50crDixe5rWbguwKMqLtxpKnHY4
=oAx3
-----END PGP SIGNATURE-----

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rich Freeman]

On Tue, Aug 27, 2013 at 3:30 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> Also #4 is still blocked, that to me would seem that we are not ready.

I don't think that the council necessarily HAS to delay if there are
blockers, but obviously they should be taken into consideration.

Does a genkernel initramfs support nfs-mounting /usr?  It appears that
Dracut at least does not at present unless root is also
network-mounted.  The rd.neednet option doesn't seem to be working,
but I'm not sure if the issue is with that option or if networking is
just broken in general in the configuration I'm testing...

Rich

Re: [gentoo-project] rfc: separate /usr preparation vote

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/27/2013 03:11 PM, Roy Bamford wrote:
> On 2013.08.17 23:20, William Hubbs wrote:
>> Council members,
>>
>> After looking over the documentation I know about [1] [2] [3], I 
>> think
>> it is safe to Say we are prepared to move forward with stating that
>> the
>> 	preparations for early boot mechanisms are complete.
> 
> [snip]
> 
>> Thanks,
>>
>> William
>>
>> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml
>> [2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-
>> quickinstall.xml
>> [3] https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
>> [4] https://bugs.gentoo.org/show_bug.cgi?id=481202
>>
> 
> William,
> 
> If such a vote were to go in your favour, what are the next steps and 
> the timescale(s) for these steps?
> 
> You clearly perceive the vote you seek as endorsing a plan of action 
> relating to the /usr merge.

While the /usr merge does require people to use initramfs, using
initramfs does not require a /usr merge.

Please, keep two completely separate topics separate like they are.  I
am 1000% behind requiring initramfs, I couldn't possibly care less about
/usr merge, in my eyes it's a hack to handle stupidity.

Upstream systemd/udev/whatever is slowly making our lives miserable
because they expect an initramfs to have /usr mounted.  Personally, it
isn't so hard to either use initramfs or just not have /usr on it's own
partition.  I believe the docs are already mostly updated if not
completely updated already, all we are waiting on is for people to
realize just how impossible it is to keep randomly moving things out of
/usr because people with broken setups can't boot.

Thanks,
Zero
> 
> My apologies in advance if I have missed these details.
>  
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSHP5lAAoJEKXdFCfdEflKcjIQAIWn3/+pjZAYVxaj4VSKQqis
ZZT8oXhq8JXpMXtsJ26YsgaESbNr5FeZKShUSgj/xUaqMC4IRoF3toRxhryeKnXn
uw36LnvGYOQQC4x8C20FPZJlfEpwW8A6vHUR3xsUejgfouNHRMnSZejTuwWTF5Of
KdfijP2CMAtnHDaRNhLuqJp71jSeCC+M2oahLgyHSGuPpAtdEH6R5ijRTKfua3TJ
7JiInmTZNl+rjmSkPy+aHXWeXHR/MrQg0yILZ3q2YVFdePo3CWe1r8pLuGZ18Fnw
esC5E06xVZ4q4d7lQxGKUPGLWe/eBnbPDZXpPFUazPjgB7io8JSlMCqw9WgE/Bhj
BlDHQepsLGcdxcGsuJ45eMAUbJ9feKJmdacj7L0xPok4QVoRTn1EPqMIHa9KNfv3
8RwnQcNRCJ220gmMVUCujuO7Z91Z5WATU+QBrhS6/b59V1loucnE97k7ocHBE7+l
bgTSfoBpWaUrIwHyaP5RZJ7CG580F+x79AYdQC8+Wb0SayrhMgZLLtLvzvsC3O9V
nkOcWUbD33rwTODDcDZmk4gvtZPEb+bFUMjBUV38nd3cZSzmOJEz4u3BqrftYrae
IclCTOswOx4hWwwHt8EMzQbNrAwwCMMxSn0UStVDe17rTbJXwl/usXuQiX5XCVLL
kR9W3BcILFMeUfubXT7F
=OU1k
-----END PGP SIGNATURE-----

Re: [gentoo-project] rfc: separate /usr preparation vote

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

On Tue, Aug 27, 2013 at 03:30:45PM -0400, Rick "Zero_Chaos" Farina wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 08/27/2013 03:11 PM, Roy Bamford wrote:
> > On 2013.08.17 23:20, William Hubbs wrote:
> >> Council members,
> >>
> >> After looking over the documentation I know about [1] [2] [3], I 
> >> think
> >> it is safe to Say we are prepared to move forward with stating that
> >> the
> >> 	preparations for early boot mechanisms are complete.
> > 
> > [snip]
> > 
> >> Thanks,
> >>
> >> William
> >>
> >> [1] http://www.gentoo.org/doc/en/initramfs-guide.xml
> >> [2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-
> >> quickinstall.xml
> >> [3] https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
> >> [4] https://bugs.gentoo.org/show_bug.cgi?id=481202
> >>
> > 
> > William,
> > 
> > If such a vote were to go in your favour, what are the next steps and 
> > the timescale(s) for these steps?
> > 
> > You clearly perceive the vote you seek as endorsing a plan of action 
> > relating to the /usr merge.
> 
> While the /usr merge does require people to use initramfs, using
> initramfs does not require a /usr merge.
> 
> Please, keep two completely separate topics separate like they are.  I
> am 1000% behind requiring initramfs, I couldn't possibly care less about
> /usr merge, in my eyes it's a hack to handle stupidity.

Rick is correct. I am not trying to force the /usr merge. That is a
totally separate topic.

All I'm asking the council to do in this vote is make sure that our
documentation for building initramfs is ready. Once that is done, bugs
like https://bugs.gentoo.org/show_bugs.cgi?id=443710 would be invalid
because we can just tell people to setup initramfs and point them to the
documentation.

The /usr merge is a separate topic, for another time.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] rfc: separate /usr preparation vote

[Sven Vermeulen]

On Tue, Aug 27, 2013 at 08:25:01PM -0500, William Hubbs wrote:
> All I'm asking the council to do in this vote is make sure that our
> documentation for building initramfs is ready. Once that is done, bugs
> like https://bugs.gentoo.org/show_bugs.cgi?id=443710 would be invalid
> because we can just tell people to setup initramfs and point them to the
> documentation.

Either http://www.gentoo.org/doc/en/initramfs-guide.xml and
http://wiki.gentoo.org/wiki/Initramfs should suffice. The first one will be
moved to the wiki in the near future as well.

I'm running with a separate /usr and boot with a genkernel generated
initramfs with no issues.

Wkr,
	Sven Vermeulen