path: root/meeting-logs/20121113.txt

20:26 <@  grobian> Betelgeuse, Chainsaw, grobian, scarabeus, WilliamH, graaff, rich0: ready now?
20:26 <+   graaff> yes
20:26 <+    rich0> aye
20:26 <@  grobian> dberkholz: thanks! (by the way)
20:27 <@ Chainsaw> I'm here.
20:27 <@Betelgeus> yes
20:27 <@ WilliamH> here
20:27 <@  grobian> scarabeus?
20:27 *** NeddySeagoon manages to be here too
20:28 <@scarabeus> herw
20:28 <@  grobian> complete!
20:28 <@  grobian> let's start the meeting
20:28 <@  grobian> agenda is : http://dev.gentoo.org/~grobian/agenda-20121113.txt
20:28 -!- grobian changed the topic of #gentoo-council to: Council meeting now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | agenda: http://dev.gentoo.org/~grobian/agenda-20121113.txt
20:28 <@  grobian> ok, topic one
20:29 <@  grobian> WilliamH: do you want to say anything on the matter
20:30 <@ WilliamH> Yes, I do actually, thanks. :-)
20:30 <@  grobian> please go ahead
20:30 <@ WilliamH> Our  tracker for udev stabilization also includes tasks for separate usr support bug 411627
20:30 < willikins> WilliamH: https://bugs.gentoo.org/411627 "[TRACKER] tasks to complete before >=sys-fs/udev-188 can be stabilized"; Gentoo Linux, Core system; CONF; williamh:udev-bugs
20:31 <@ WilliamH> For separate usr support, we need bug 435756
20:31 < willikins> WilliamH: https://bugs.gentoo.org/435756 "sys-apps/openrc-0.11.5 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:openrc
20:31 <@ WilliamH> and bug 441004
20:31 < willikins> WilliamH: https://bugs.gentoo.org/441004 "sys-kernel/genkernel: we need a stable version that mounts /usr"; Gentoo Hosted Projects, genkernel; CONF; williamh:genkernel
20:31 <@ WilliamH> The non-initramfs method for separate usr support is already stable, that is busybox with the sep-usr use flag.
20:32 <@ WilliamH> Basically you emerge it with that flag then use the init= kcl parameter to run ginit which hands over to your real init after mounting /usr.
20:33 <@ WilliamH> What I'm asking the council to do is, vote that after we get the other bugs stable we need, we can start migrating everyone to one of those methods.
20:33 <@ WilliamH> I propose a newsitem, then after a time window, we
20:33 <@ Chainsaw> What I would ask is that we postpone this decision by one month, as I expect an alternate udev to be available by that time.
20:34 <@ WilliamH> can assume that everyone who is using split /usr is on one of these methods. Also, our qa lead has a blog article from a few years ago
20:34 <@ Chainsaw> At which point we may well have three options to consider.
20:34 <@ WilliamH> Chainsaw: udev is irrelivent
20:34 <@ Chainsaw> WilliamH: It really isn't.
20:34 <@ WilliamH> Sure it is.
20:34 <+    rich0> When do we think all the blockers will be closed anyway?
20:34 <@ Chainsaw> WilliamH: As much as I would pray that udev would become irrelevant, it is the wedge that is being driven between my working systems and linux.
20:34 <+    rich0> Will delaying a month make any practical difference?
20:35 <@ WilliamH> Well, I'm going to move for stabilization of the new openrc in the next week.
20:35 <@ Chainsaw> WilliamH: I don't propose that you stop the preparation work.
20:35 <@ WilliamH> Chainsaw: hang on a sec, I'm pulling up something
20:35 <@ Chainsaw> WilliamH: I just ask that we do not make the decision on the main udev stabilisation until next month's meeting, when we'll in all likelihood have more choice.
20:35 <+   graaff> rich0: a fork was created in the last few days, so a month would make a difference with that
20:36 <@ WilliamH> We aren't talking about udev stabilization.
20:36 <@ Chainsaw> WilliamH: If it is that tired "oh but separate /usr was always a little bit broken" page again, I shall scream.
20:36 <+    rich0> Chainsaw, my thinking is that if waiting a month won't actually delay anything, then it only makes sense to make the decision with more info.
20:36 <     _AxS_> stabilization of packages and such won't be affected by this, though, will it?  the only thing that is affected is the ability to declare "/ and /usr are essentially always available now, no need to work around it" , ?
20:36 <@ WilliamH> http://blog.flameeyes.eu/2010/04/useless-legacies
20:37 <@ Chainsaw> _AxS_: Things like openrc can be stabilised, sure. Just not udev itself.
20:37 <@ WilliamH> No, I'm not proposing stabilizing udev.
20:37 <@ Chainsaw> _AxS_: I don't want the breakage to be unleashed mere weeks before a more effortless solution is ready.
20:38 <+    rich0> Well, I think that there would be a 30-90 day window anyway after everything is stable.
20:38 <     _AxS_> Chainsaw: *nod*, i'm more getting at, that these fixes can get into stable regardless of the decision made here, so that the release media can get fixed
20:38 <+    rich0> So, breakage will not immediately follow all those blockers being closed.
20:38 <@ WilliamH> _AxS_ is correct about what I'm proposing. I'm just saying that / and /usr will always be available.
20:38 <@  grobian> WilliamH: may I summarise your request as only focussing on getting people out of the split /usr setup during boot?
20:38 <@ WilliamH> grobian: yes.
20:39 <@ WilliamH> grobian: Stablizing udev has nothing to do with that.
20:39 <@  grobian> right
20:39 <@  grobian> we've had this discussion on the ML already
20:39 <@  grobian> and I think we shouldn't penalise people who can't easily effectuate this
20:39 <@scarabeus> i agree here with will :)
20:40 <@ WilliamH> grobian: I don't think there is a major penalty involved.
20:40 <@  grobian> so I'm not in favour of "assuming that everyone who is using split /usr is 
20:40 <@  grobian> using a method to mount /usr before boot"
20:40 <@  grobian> WilliamH: I once maintained 3000 Gentoo systems, and I think there is
20:40 <+    rich0> question - I had assumed this was about being able to eventually stabilize the next udev.  If not, then what exactly is the motivation behind this?  What happens if people don't migrate?
20:41 <@ Chainsaw> rich0: It does feel like we get to have the breakage now anyway, with or without udev.
20:41 <@  grobian> rich0: udev is not in the picture now, see my previous question to WilliamH and his answer
20:41 <@ WilliamH> rich0: The issue is anything that crosses the /->/usr barrier.
20:41 <@ WilliamH> rich0: Basically if you have binaries in / that link to things in /usr/lib, or,
20:42 <@ WilliamH> read things from /usr/share,
20:42 <+   graaff> The relation is that having /usr available at boot time is a precondition for stabilizing newer udev, right?
20:42 <+    rich0> My thinking is that if somebody doesn't have plans that are being blocked, then waiting a month to let the new udev effort have a shot makes the most sense.
20:42 <@ WilliamH> they are broken if /usr is not available when / is.
20:42 <     _AxS_> graaff: more specifically would be 'kmod'
20:43 <@  grobian> my thinking is that we can easily create a profile where we unmask some udev version, and hence allow the eager users to opt-in
20:43 <@ WilliamH> graaff: Not just udev. Udev is related, but that's not the issue with / and /usr.
20:43 <     _AxS_> graaff: which sits in /usr/[s]bin but has symlinks like /sbin/modprobe -> /usr/whatever/kmod
20:43 <@ WilliamH> kmod is part of it too.
20:43 <@ Chainsaw> WilliamH: Udev is at the centre of the /usr merge plans. The upstream authors put it there.
20:43 <+   graaff> WilliamH: I understand, I was trying to clarify how udev fits in this dicussion.
20:44 <@ Chainsaw> WilliamH: It is as related to the /usr merge as a boat to water.
20:44 <@ WilliamH> Chainsaw: /usr merge isn''t what I'm discussing right now.
20:44 <@ Chainsaw> _AxS_: Sounds like kmod needs a few fixes.
20:44 <+   graaff> grobian: how do you see the plan forward in that case?
20:44 <@  grobian> stick to the original agenda ;)
20:44 <+    rich0> It seems like the smoothest path is to just keep moving forward with the tracker, and then when having support for a separate /usr becomes a barrier then we take the step of deprecating things.
20:45 <@  grobian> I disapprove the plan, I think it's not ok for all types of consumers of our userbase
20:45 <+    rich0> That gives alternative solutions the most opportunity to move foward, and it gives our users the most options.
20:47 <+    rich0> So, I tend to agree with Chainsaw - if there isn't anything pressing that we're blocking, why not wait a month and make the decision "just in time?"
20:47 <@ WilliamH> rich0: I'm just seeing your last msg right now, what  was the previous one again?
20:48 <@  grobian> Betelgeuse, graaff, scarabeus: do you have inputs (that I should record)
20:48 <@scarabeus> i said i agreed with wills idea
20:48 <@Betelgeus> No matter what we do users should not be caught off guard
20:48 <@ WilliamH> Betelgeuse: I agree, that's why I want to publicize everything as we go with newsitems etc.
20:49 <@ WilliamH> When things start to happen my plan is to announce everything with newsitems as we go.
20:49 <@Betelgeus> Otherwise I agnostic :)
20:49 <@Betelgeus> +am
20:49 <+    rich0> WilliamH, in theory the communications don't have to wait for all the blockers to be done, though we might have to be vauge about the udev fork since that is immature.
20:49 <@ Chainsaw> rich0: So that's why we could wait a month and do this right.
20:50 <+   graaff> I don't think a forked udev will make a lot of difference to the split /usr situation, so I don't see how waiting a month will help.
20:50 <@ WilliamH> rich0: The problem with the udev fork is, we don't know when it will be ready.
20:50 <@ Chainsaw> WilliamH: Within a month, so in time for the next meeting.
20:50 <@ WilliamH> rich0: it could be next month or they could keep coming back saying we need more time etc...
20:50 <     _AxS_> ..what's the summary of the decision so far?  2 for "wait" , 1 for "dont do it", 2 for "do it", and one for "users come first no matter what" ..?
20:50 <@ Chainsaw> WilliamH: You can quote me on this. If it isn't ready, we move on and I have failed.
20:50 <+    rich0> WilliamH, Agree, and if waiting for the fork actually delayed things by much I'd be more concerned.  However, we're not at the point where this is on the critical path, so I think we can afford to wait.
20:50 <+    rich0> I'm for wait.
20:51 <+    rich0> Unless somebody can show me something that waiting is actually holding up.
20:51 <@ Chainsaw> WilliamH: I have blueness working on this. I am very confident that we will hit that date.
20:51 <@ WilliamH> rich0: this isn't really the topic for this meeting, but
20:51 <     _AxS_> rich0: kmod stabilization will be held by this, unless that one is patched.
20:51 <@ WilliamH> give me a second to get a bug number
20:52 <@Betelgeus> _AxS_: If someone can formulate a clear item to vote on then I have no problem casting one
20:52 <@ Chainsaw> _AxS_: Then let's patch it to do the right thing and *then* stabilise it.
20:52 <     _AxS_> (i dont know if that's a big deal or not tho)
20:52 <@ WilliamH> bug 417451 can happen on linux once we make the switch.
20:52 < willikins> WilliamH: https://bugs.gentoo.org/417451 "toolchain-funcs.eclass:gen_usr_ldscript - make no-op on non-bootable systems"; Gentoo Linux, Library; CONF; yrusinov:toolchain
20:52 <     _AxS_> Betelgeuse: my count seems to still be missing someone ..
20:53 <     _AxS_> ..except that bug is something we're specifically leaving out of this debate.
20:53 <@ WilliamH> Right, I'm just siting something since rich0  wanted to know something that we are holding back.
20:53 <+   graaff> I would prefer to move on but make sure that people need to opt-in their systems, so we can be sure they've made preparations and won't end up with unbootable boxes.
20:53 <+    rich0> WilliamH, does it really amount to much delay - it seems like it will take a week or two at least to get the other blockers resolved anyway.
20:54 <     _AxS_> graaff: i think i missed you.  So that makes three for wait.
20:54 <@ Chainsaw> You counted my "wait" answer, right?
20:54 <     _AxS_> Chainsaw: yes.
20:54 <@ WilliamH> Ok, I'm lost, and it is hard  for me to scroll.
20:54 <+   graaff> _AxS_: uhm, "I prefer to move on"...
20:55 <@  grobian> gen_usr_ldscript is NOT a topic of concern now
20:55 <     _AxS_> 'k sorry
20:55 <@ WilliamH> I prefer to move on as soon as the blockers are cleared.
20:55 <@ WilliamH> let me clarify what move on means.
20:56 <@ WilliamH> publish a news item, then give users maybe 14-30 days to migrate then assume everyone has after that window.
20:56 <@ Chainsaw> Yes, introduce the breakage quickly, before the fix is ready.
20:56 <@ WilliamH> Chainsaw: no once the blockers are closed the fix is there.
20:57 <+   graaff> WilliamH: if that is the plan then I am against it, because I don't want to make that assumption. I want to ensure that a user has actually migrated.
20:57 <@  grobian> _AxS_: do your findings match my agenda?
20:57 <+    rich0> If the window were longer - say 60-90 days that might be a compromise for waiting - it would give the udev efforts more opportunity to catch up.
20:57 <@ WilliamH> graaff: you can't guarantee anything.
20:58 <+   graaff> Find a way.
20:58 <      ryao> As far as I can tell, there is nothing that any of our users actually want that will be harmed even if we were to keep using udev-171 until next year.
20:58 <     _AxS_> grobian: yep. except graaff i think just switched
20:58 <@  grobian> WilliamH: use a profile, it requires an explicit step by the user
20:58 <@ WilliamH> graaff: That's impossible. You are asking something like finding a way to make sure that everyone has migrated to OpenRC.
20:58 <@  grobian> _AxS_: indeed
20:58 <+   graaff> _AxS_: I'm still for 'moving on', but I have a nasty precondition for it.
20:58 <@ Chainsaw> WilliamH: I have already given you ironclad guarantee. Ready by the next meeting.
20:59 <@ Chainsaw> WilliamH: In a public channel, in a public meeting, which is logged and observed. I can't back out of that.
20:59 <     _AxS_> graaff: I concurr, but since that precondition doesn't exist that effectively turns you into a 'wait' :)
20:59 <@  grobian> graaff: think I got that now
20:59 <+   graaff> WilliamH: I haven't looked at this problem at all, but isn't it possible to do this with a profile switch, option set somewhere, file added to flie system?
20:59 <     _AxS_> graaff: there was such a proposal made to -dev@
20:59 <@  grobian> it's called masks, and special variables
21:00 <@ Chainsaw> WilliamH: Moving ahead now, and saying "the hell with the udev fork" sounds very scorched earth to me.
21:00 <@  grobian> I would like to finish on this topic
21:00 <@ WilliamH> graaff: maybe a  use flag could be added?
21:00 <@  grobian> I think we've had a lot of feedback now
21:01 <@ WilliamH> Chainsaw: I can go along with what you said about waiting for a month.
21:01 <@ Chainsaw> WilliamH: That's all I ask. If we're not ready by next meeting, we have failed.
21:01 <@ WilliamH> Chainsaw: if the fork isn't ready and the blockers are cleared, we move on though...
21:01 <@ Chainsaw> WilliamH: Yes. I will sign that ultimatum.
21:01 <@  grobian> right
21:01 <+    rich0> Tend to agree, I think that in practice a month delay won't actually hold anything up by much, since the blockers are still ongoing.
21:02 <@ Chainsaw> grobian: I think we can move on with that on record?
21:02 <@  grobian> I'm affraid I'll have to record it, tes
21:03 <@ WilliamH> Chainsaw: you might want to look at the bug I sited earlier for gen_usr_ldscript in the next month as well.
21:03 <@  grobian> ok, I want to close this topic now
21:03 <@  grobian> and move on to the second topic
21:03 <@  grobian> Policy on "<" versioned dependencies
21:04 <@ WilliamH> I don't know of one.
21:04 <@  grobian> did anybody do something ont that one?
21:04 <@  grobian> if you haven't, I did, and put it in the agenda as gentle help
21:05 <@  grobian> with that said, I'd like to suggest in this case for devrel to have a look at it
21:06 <@  grobian> and next to that, I'd suggest that the issue clearly is nasty from a package perspective
21:06 <+    rich0> afaik there is no policy against < dependencies.  They're reasonably common in my experience.
21:06 <     _AxS_> grobian: ... specifically what is it devrel would be looking at?  the usage of < deps , or the non-usage of them?  or just a general "get back to us with a policy" ?
21:06 <+    rich0> But obviously there needs to be some level of cooperation.
21:06 <@  grobian> which indeed leads to "common sense" + case by case judgment
21:07 <+    rich0> I think common sense makes more sense than forced policy - if an issue comes up, then we deal with it.
21:07 <@  grobian> _AxS_: read the bugs
21:07 <+    rich0> They're obviously discouraged, like ignoring CFLAGS/etc.
21:07 <@  grobian> rich0: unfortunately we've seen in the past that common sense doesn't really exist
21:07 <@  grobian> in particular the common part
21:07 <     _AxS_> grobian: Ah, missed that link, sorry
21:08 < NeddySeag> Common sense is much rarer than you may suppose.  Its only found in people who agree with the particular PoV
21:08 <+    rich0> Sure, but rules can be even worse sometimes.  They won't be applied using common sense either.
21:08 <@  grobian> rich0: I agree with you
21:08 <+    rich0> I guess the issue is, what's broken here?
21:08 <@  grobian> hence my suggestions
21:09 <@  grobian> rich0: for that you'd have to have done your homework
21:09 <@  grobian> anyone else having something to say here?
21:09 < NeddySeag> A policy is not a rule, or set of rules.  Its top level guidence
21:09 <+   graaff> I hate these dependencies in ruby packages, but I love that I can use them to at least provide some llvm support in rubinius.
21:10 <+   graaff> I hope a policy will reflect that …
21:10 <@  grobian> can we agree on something like "The council sees no rule that makes it illegal to use < dependencies, and suggests QA to reconsider its behaviour towards other developers that use them."
21:11 <+   graaff> I would still like to strongly discourage these dependencies
21:11 <@  grobian> + base-system
21:11 <@  grobian> fine with mee
21:11 <+   graaff> Downgrades like these can be very nasty.
21:12 <@ Chainsaw> As long as it isn't glibc that you're downgrading, life goes on.
21:12 <@ Chainsaw> These < dependencies sound like a necessary evil to me.
21:12 <+   graaff> Chainsaw: I don't want to watch up/downgrade fights between different packages
21:12 <  chithead> if I may add, packages where it leads to serious problems already have checks in place against downgrades
21:13 <@ Chainsaw> They should be used responsibly and sparingly. But outlawed? Sorry, that seems a bridge too far.
21:13 <+   graaff> Also, if others use < dependencies for packages it becomes very hard to clean up package revisions and not break the tree.
21:13 <     _AxS_> it's more the preventing-known-to-break-upgrades that makes these dependencies attractive
21:13 <@ Chainsaw> And if your consumers keep using < dependencies for your library... think for a minute.
21:13 <@  grobian> The council sees no rule that makes it illegal to use < dependencies, but strongly discourages the use of them.  It must be noted that for some packages, a downgrade is very undesirable.  This can make some teams to step up.  However, the council requests those teams to act reasonably and in good cooperation with the maintainers of the packages in question.
21:13 <@ Chainsaw> Who is at fault here?
21:14 <+   graaff> grobian: I can go with that.
21:14 <+    rich0> grobian, ++
21:14 <@scarabeus> i agree
21:14 <+   graaff> Chainsaw: in my case usually the consumers, but let's discuss that another time :-)
21:14 <@ Chainsaw> "This can make some teams to step up" is not grammatically correct.
21:14 <@ Chainsaw> Please adjust.
21:14 <     _AxS_> grobian: it might possibly be of note here that the package managers might be able to handle the < deps a bit better, too, as portage right now doesn't handle downgrades or prevented-upgrades due to < deps particularily well
21:14 <@  grobian> Chainsaw: please suggest
21:14 <@ Chainsaw> grobian: It's not apparent to me what you wanted to say.
21:15 <@  grobian> ok
21:15 <@ Chainsaw> grobian: "the use of them" -> "their use"
21:15 <@ Chainsaw> grobian: Same meaning, lot shorter.
21:15 <@  grobian> Using a < dependency can trigger some teams to remove a package.
21:15 <     _AxS_> (note is for the minutes, rather than the statement)
21:16 <@  grobian> Chainsaw: ^^^ that sentence, would it be clear to you?
21:16 <@ Chainsaw> graaff: "This has triggered package removals in the past."
21:17 <@  grobian> ok
21:17 <@ Chainsaw> That seems to be what you meant?
21:17 <@  grobian> yeah
21:17 <@  grobian> However, the council requests the teams responsible for 
21:17 <@  grobian> that removal to act reasonably and in good cooperation with the maintainers of
21:17 <@  grobian> the packages in question.
21:18 <@  grobian> like that?
21:18 <@Betelgeus> Is there anything new in that?
21:18 <@  grobian> no, but apparently QA doesn't know
21:18 <@ Chainsaw> Betelgeuse: Looks like it is our turn to be the voice of reason.
21:19 <@  grobian> ok. if we all agree please move on to the open bugs
21:19 <@ Chainsaw> I'm happy to sign off on the revised wording, yes.
21:19 <@ Chainsaw> Is the jmbsvicetto bug handled?
21:19 <@ WilliamH> Same here.
21:19 <@  grobian> can't ask ulm, but apparently he did it
21:19 <@Betelgeus> it should be easy to verify
21:19 <@  grobian> I'll send it around for your review anyway, but thanks
21:19 <@Betelgeus> open the council page and look
21:20 <@  grobian> seems to me they are there
21:20 <@  grobian> http://www.gentoo.org/proj/en/elections/council/
21:20 <@scarabeus> chainsaw the bug is done
21:20 <+   graaff> ulm didn't specifically mention anything about this to me
21:21 <@  grobian> ok, let's give him the final ack on it
21:21 <@ Chainsaw> scarabeus: Excellent.
21:21 <@  grobian> next, that devmanual update with EAPI5
21:21 <@  grobian> is there anything we can/should do here
21:21 <@  grobian> ?
21:22 <@  grobian> I consider that as a no ;)
21:22 <@  grobian> ok
21:22 <@  grobian> Open Floor
21:22 <@  grobian> anyone who likes to raise an issue?
21:23 *** Chainsaw turns on the microphone
21:23 <@ Chainsaw> An orderly queue please. Single file.
21:23 <     _AxS_> i'd like to commend grobian on the live-summary-writing , which was very effective this meeting
21:23 <@  grobian> ok, great, so that finishes this meeting
21:23 <@  grobian> _AxS_: I do that each meeting I chair...
21:23 <@ Chainsaw> grobian: But it works well, and not all of us can do that.
21:24 <@  grobian> Next meeting is 11 December 2012, 20:00 UTC, is that ok?
21:24 <@ Chainsaw> grobian: I freely admit that chairing a meeting takes all my time. I use a note-taker.
21:24 <@ Chainsaw> grobian: That works for me, yes.
21:24 <@  grobian> please check the date/time
21:24 <@ WilliamH> That's good for me also
21:24 <@  grobian> I don't want to make the same mistake again!
21:24 <@ Chainsaw> My calendar tells me that is the second Tuesday of December in week 50.
21:25 <@  grobian> OK!
21:25 <@  grobian> thank you all
21:25 <@ WilliamH> Chainsaw: query?
21:25 -!- grobian changed the topic of #gentoo-council to: Next meeting: 2012-12-11 20:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/