path: root/meeting-logs/20130108.txt

19:34 -!- Chainsaw [~chainsaw@gentoo/developer/chainsaw] has joined #gentoo-council
19:35 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
19:50 -!- willikins [~rbot@gentoo/bot/Willikins] has quit [Quit: seeya]
20:43 -!- willikins [~rbot@gentoo/bot/Willikins] has joined #gentoo-council
20:43 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has joined #gentoo-council
20:46 *** WilliamH is here just working on udev
20:46 *** Chainsaw ensures that the champagne carriers are at the entrance doors
20:46 *** grobian wonders about all the whispering
20:46 < Zero_Chao> darnit, they weren't there when I walked in
20:47 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has left #gentoo-council []
20:47 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has joined #gentoo-council
20:47 < Zero_Chao> oh yeah, champagne
20:47 -!- mgorny [~mgorny@gentoo/developer/mgorny] has joined #gentoo-council
20:47 <  WilliamH> Sounds good to me. :-)
20:47 <@ Chainsaw> Evening mgorny.
20:47 <    mgorny> Chainsaw: evening to you too
20:47 <@ Chainsaw> mgorny: Since your proposal is the main agenda item, I would like for you to be here.
20:47 <    mgorny> btw it's usually better to ping me
20:48 <    mgorny> invites are hardly distinguished
20:48 <@ Chainsaw> mgorny: As always... proud to be different.
20:48 <  WilliamH> Chainsaw: This udev thing is going to be able to be done w/o a use flag I think.
20:48 <@ Chainsaw> WilliamH: _AxS_ provided a convincing argument, yes.
20:48 <  WilliamH> Chainsaw: I can drop a file in /etc/udev/rules.d and leave it there... tell you to remove it when you are ok with it.
20:49 <@ Chainsaw> WilliamH: Indeed. It looks like udev upstream implemented an opt-in change. Forgive my surprise. This is out of character.
20:49 <  WilliamH> What they are doing is giving you a default if you don't have something else already set up.
20:50 <  WilliamH> I'm not that much of a kernel guy, but I guess that if you have multiple interfaces messing with the eth* names can be a mess.
20:51 < scarabeus> so what shall we broke this time
20:51 <+dberkholz> can this udev stuff go back to #-dev unless it's currently relevant to the council?
20:51 <  WilliamH> scarabeus: nothing by default.
20:51 < scarabeus> I checked hard to ensure getting here on right time :P
20:51 <  WilliamH> scarabeus: we get to prepare for this one.
20:52 <@ Chainsaw> Betelgeuse is here as well. That's good.
20:52 <  WilliamH> scarabeus: This is what is coming for network interface names. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
20:52 <  WilliamH> scarabeus: but we can prepare for this.
20:53 <@ Chainsaw> Wait, Betelgeuse has been parked there for 28 hours. He's going to get a ticket...
20:54 <@ Chainsaw> Looks like ulm is around though.
20:54 <@      ulm> here
20:54 <@ Chainsaw> Excellent.
20:54 <@      ulm> did we start early?
20:54 <@ Chainsaw> I wouldn't dare.
20:55 <@ Chainsaw> Just making sure everyone is lined up, so we can start on time.
20:55 <@ Chainsaw> If there's a number for Betelgeuse... can we send him a quick 5 minute warning?
20:55 <@  grobian> I'm working on a pot of tea here, should be ready in time
20:55 < scarabeus> grobian: btw remember your sms? it arrived next morning (i just recalled i wanted to tell ya)
20:56 <@  grobian> scarabeus: COOL! so it DID work
20:56 <@  grobian> scarabeus: so sorry to hear, at least proves I didn't lie
20:57 <@ Chainsaw> Did someone text Betelgeuse please?
20:59 <@ Chainsaw> If not, now is a great time.
20:59 <@ Chainsaw> Or an outright phone call perhaps.
21:00 <@ Chainsaw> Okay. Zero hour.
21:00 <+dberkholz> hi
21:00 <@      ulm> Chainsaw: I'm going to text him
21:00 <@ Chainsaw> Good evening.
21:01 <@ Chainsaw> ulm: It is appreciated. Let's give him 5 minutes to surface.
21:01 <@  grobian> here
21:01 *** ulm still here
21:01 <@  grobian> scarabeus: you're here too now, right?
21:01 <@ Chainsaw> According to my calculations, we have everyone except Betelgeuse.
21:01 *** WilliamH still here just testing udev.
21:01 <@  grobian> ps, I'm doing the agenda/summary thing online, Chainsaw is chairing
21:01 <+dberkholz> whoa. duncan had a good, short email.
21:01 <+dberkholz> totally didn't even see it till now
21:02 <@Betelgeus> ulm: thanks
21:03 <@ Chainsaw> Betelgeuse: Excellent. Welcome :)
21:03 <@      ulm> Betelgeuse: np :)
21:03 <@ Chainsaw> Now that we have everyone, to the order of the day.
21:03 <@ Chainsaw> mgorny has a proposal to implement stable USE masks.
21:03 < scarabeus> yep yep
21:03 <@ Chainsaw> mgorny: Did you agree with my summary on the agenda please?
21:04 <  WilliamH> Can someone link the agenda real quick?
21:04 <@  grobian> it's in topic
21:04 <@ Chainsaw> WilliamH: http://dev.gentoo.org/~grobian/agenda-20130108.txt
21:04 < scarabeus> WilliamH: http://dev.gentoo.org/~grobian/agenda-20130108.txt
21:04 <@  grobian> http://dev.gentoo.org/~grobian/agenda-20130108.txt
21:04 <@  grobian> so
21:04 < scarabeus> :D
21:05 <@Betelgeus> for the summary a link to the mailing list would be good
21:05 <@ Chainsaw> So to confirm, we have three possible approaches.
21:05 <    mgorny> Chainsaw: hmm, yes
21:05 <@ Chainsaw> mgorny: I'm glad.
21:05 <+dberkholz> here's the thread: http://www.gossamer-threads.com/lists/gentoo/dev/263988
21:05 <    mgorny> i'd just like to make clear that 3) would mean that not profiles EAPI but ebuild EAPI would matter
21:05 <+dberkholz> there's probably a version on archives.g.o but it didn't pop up in google as quickly
21:06 <@      ulm> I think that option 3 is a no-go
21:06 <@ Chainsaw> So first things first, does the council want to vote in stable USE masks? This is a yes/no; in case of "no" we push back -dev for further discussion.
21:06 < scarabeus> 3 is bad idea
21:06 <@  grobian> dberkholz: archives is disabled for months now
21:06 <@ Chainsaw> If we agree we want to vote it in, we can discuss the 3 different options.
21:06 *** grobian agrees with ulm
21:07 <+dberkholz> that's still broken? no wonder i haven't been using it.
21:07 <@  grobian> Chainsaw: doesn't it already exist (EAPI 5)
21:07 <+dberkholz> indeed. http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-580005.2.11
21:07 <@ Chainsaw> grobian: Even if it already exists, you need to vote "yes" to this list of three so we can pick one.
21:07 <@      ulm> grobian: it's in EAPI 5, but profiles are at lower EAPIs
21:08 <@ Chainsaw> grobian: Because "none of the below" is an answer too, and saves me taking you to three options.
21:08 <@  grobian> Chainsaw: then I vote for actually voting for a solution to this problem
21:08 *** Chainsaw records grobian as "yes"
21:08 < scarabeus> record mine too
21:08 <@Betelgeus> yes
21:08 <+dberkholz> yes.
21:08 <@      ulm> yes
21:08 *** Chainsaw votes "yes"
21:08 <@ Chainsaw> Excellent.
21:09 *** WilliamH votes yes
21:09 <@ Chainsaw> I do like unanimous votes.
21:09 <@ Chainsaw> So, option 3 seems unpopular.
21:09 <@ Chainsaw> Do we scrap it as unworkable?
21:09 < scarabeus> i feel particulary fond of #1
21:09 <@      ulm> Chainsaw: please do
21:09 <+dberkholz> i'm for 1.
21:09 <@ Chainsaw> I am strongly leaning towards option 1 myself.
21:09 <  WilliamH> Option 3 is what w already have isn't it?
21:10 <@  grobian> option 3) can be removed
21:10 <@      ulm> 1, with sufficiently long transition time
21:10 <@ Chainsaw> Voting is between options 1 & 2.
21:10 <@ Chainsaw> Let's try a yes/no vote for option #1.
21:10 <+dberkholz> yes
21:10 <@  grobian> I have wee problem with Prefix and BSD profiles
21:10 <@  grobian> they are unversioned
21:10 <@ Chainsaw> grobian: Can you not address that in the proposed sweeping change?
21:10 <@ Chainsaw> grobian: Option #1 mandates action for all users.
21:10 <@  grobian> my personal take was to actually just up the eapi to 5 for Prefix
21:11 <@  grobian> but I don't know what BSD wants to do
21:11 <@ Chainsaw> grobian: Should I read that as an abstention or a negative vote?
21:11 <@  grobian> Chainsaw: what would you propose for the sweep change then?
21:11 <@Betelgeus> It used to be the case that users regularly had to switch profiles
21:11 <@  grobian> nah, in general I'm for 1), but I'd like to put a note here that not all profiles are versioned
21:12 < scarabeus> you can create new versioned profiles?
21:12 <@  grobian> I guess we can
21:12 <@  grobian> in Prefix we won't
21:12 *** WilliamH doesn't see a problem with upping the eapi for *bsd or prefix
21:12 <@  grobian> so BSD is left
21:12 <@ Chainsaw> scarabeus: That is what I suggested, yes. Now that user action is needed, implement it there and then.
21:12 <@Betelgeus> any way with Display-If-Profile it's easy to bug peopleas many times as we want
21:12 <@  grobian> WilliamH: no problem indeed, just a matter of timeframe, as ulm pointed out
21:12 < scarabeus> yes we can show them news item
21:12 <@ Chainsaw> grobian: So. This is a yes/no vote. I have a yes from dberkholz. Are you an abstain, no or yes?
21:13 < scarabeus> Chainsaw: yes for me
21:13 <@  grobian> Chainsaw: my vote goes to 1)
21:13 *** ulm notes that until few years ago, we used to update profile much more often
21:13 *** scarabeus would actually preffer per year basis
21:13 <@      ulm> I vote yes for 1, too
21:13 *** WilliamH votes yes for 1
21:13 < scarabeus> so users wont forget :P (with each eapi it can be bond)\
21:13 *** Chainsaw votes yes on #1
21:13 <@Betelgeus> yes
21:14 <@ Chainsaw> That looks unanimous.
21:14 <  WilliamH> When you deprecate a profile users start getting warnings to move away from it right?
21:14 <@ Chainsaw> WilliamH: Yes.
21:14 <  WilliamH> You depricate by adding a file to the profile directory.
21:14 <  WilliamH> afaik
21:14 <@ Chainsaw> WilliamH: At the end of every emerge --sync cycle, from what I recall.
21:14 < scarabeus> does it show timeframe?
21:14 <@ Chainsaw> Now that option #1 has been chosen, we will need to put a timeline together.
21:15 < scarabeus> ege deprecated will be removed  in <countdown>
21:15 <  WilliamH> scarabeus: I think it is just a txt file so you can put what you want in there.
21:15 < scarabeus> WilliamH: excelent
21:15 <@ Chainsaw> The deprecation marks are easy enough to insert. However, the old profiles will need to be kept around.
21:15 < Zero_Chao> When a profile is deprecated you get a warning every time emerge runs. It simply says your profile is deprecated and to move to a new one.
21:15 <+dberkholz> indefinitely?
21:15 < scarabeus> i would go with 1-2years
21:15 <@ Chainsaw> dberkholz: I wouldn't say until the end of time, no.
21:15 <+dberkholz> our support period is 1 year at best for anyone who isn't a super expert
21:15 <@ Chainsaw> But a year seems reasonable.
21:16 <@      ulm> one year sounds good to me
21:16 *** Chainsaw proposes a yes/no vote for a 1 year deprecation period for current EAPI<5 profile trees
21:16 <  WilliamH> I think we can go less than a year. How long do we keep old profiles around for releases?
21:16 < scarabeus> yes
21:16 <@  grobian> not less than a year
21:16 *** grobian votes for 1 year
21:16 *** Chainsaw votes "yes" on 1 year
21:16 <@      ulm> yes
21:16 <@  grobian> at least
21:16 <@ Chainsaw> And indeed, that is a minimum, not a maximum.
21:17 *** WilliamH votes yes for a year I guess...
21:17 <+dberkholz> can/should we add a commit lock to the old profiles then?
21:17 <@  grobian> no
21:17 <@  grobian> this also fuels the discussion of deprecation of EAPIs of course
21:18 <@ Chainsaw> grobian: Provided we can agree on a timeline, that becomes more feasible at a later time.
21:18 <+dberkholz> Zero_Chaos: it also recommends a specific new profile, iirc
21:18 <@Betelgeus> I don't think this needs a separate timeline the general upgrade support timelines are enough
21:18 <@  grobian> yup, just saying as it's tied to the timeline, IMO
21:18 <@ Chainsaw> dberkholz: Vote for 1 year? Yes/no/abstain?
21:18 <+dberkholz> i guess my vote would be for 1 year as a max.
21:18 <@      ulm> we can always reconsider things at the end of the transition period
21:19 <@ Chainsaw> dberkholz: That's a yes really.
21:19 <@      ulm> and extend it if necessary
21:19 <+dberkholz> Chainsaw: it was till you started changing the wording halfway through =)
21:19 <@ Chainsaw> dberkholz: A no then?
21:20 <+dberkholz> well, frankly i'm confused
21:20 < Zero_Chao> dberkholz: I couldn't specifically recall that.
21:20 <  WilliamH> Are we voting for deprecation of eapis now?
21:20 <+dberkholz> is your vote what you originally proposed? or is it "And indeed, that is a minimum, not a maximum."
21:21 <+dberkholz> i can't tell if that's part of the proposal or appended to your individual vote
21:21 <@ Chainsaw> WilliamH: Removal of the old EAPI<5 profile trees.
21:21 <@ Chainsaw> WilliamH: Still.
21:21 <  WilliamH> Chainsaw: ok...
21:21 <@ Chainsaw> dberkholz: That's a clarification of my individual position.
21:21 <+dberkholz> ok.
21:22 <+dberkholz> in that case, my vote is yes.
21:22 <+dberkholz> i would prefer 6 or even 3 months, but i'm ok with a year.
21:22 <@ Chainsaw> dberkholz: That's compromise for you.
21:22 *** WilliamH thinks a year is long enough to keep them around
21:22 <@ Chainsaw> Unanimous then?
21:22 <+dberkholz> can bundle up old profiles with a rescue portage or something, if we need more.
21:23 *** WilliamH agrees with dberkholz  too; there isn't really reason to keep them a year.
21:23 <@      ulm> dberkholz: a shorter transition period will likely break the upgrade path for users
21:23 <@Betelgeus> Chainsaw: I still think this doesn't need a special policy
21:23 <@ Chainsaw> Betelgeuse: Abstain? Okay.
21:23 <@      ulm> if no profile with eapi < 5 is present, they canot update portage to eapi 5
21:23 <@      ulm> *cannot
21:24 <@Betelgeus> Chainsaw: I would record a no.
21:24 <+dberkholz> ulm: for anyone syncing less than once every three months and also not reading -announce? perhaps they're in need of rescuing =)
21:24 <@ Chainsaw> Betelgeuse: As you wish.
21:24 <  WilliamH> ulm: they will be getting messages every time they
21:24 <@ Chainsaw> grobian: That's 6 in favour and 1 against. The motion carries.
21:24 <  WilliamH> ulm: emerge --sync telling them a profile is deprecated.
21:24 <@Betelgeus> Chainsaw: Technically it would be closer to a competing measure.
21:24 <@      ulm> dberkholz: we previously decided that we would provide an upgrade path for 1 year
21:24 <@      ulm> for stable systems
21:24 <@Betelgeus> indeed
21:24 <@ Chainsaw> On the open bugs with council involvement, I'm pleased to report that the two missing master ballots have been located & uploaded.
21:25 <+dberkholz> that's why i mentioned a rescue portage.
21:25 <@      ulm> Chainsaw: finally!
21:25 <+dberkholz> freeze the profiles and throw 'em in a tarball.
21:25 <@ Chainsaw> ulm: As such, could you please close the bug as FIXED?
21:25 *** WilliamH agrees with dberkholz 
21:25 < scarabeus> dberkholz: actually we could provide it for any nuts with no-longer-sync tree, could releng do such things?
21:25 <@  grobian> Chainsaw: can the bug be closed then?
21:25 < scarabeus> jmbsvicetto: mate, you around? read this ^
21:25 <@ Chainsaw> grobian: Yes.
21:26 <@  grobian> DOIT
21:26 <@  grobian> :P
21:26 <@ Chainsaw> grobian: ulm was the last to post, I would like for him to confirm he is happy that all is resolved.
21:27 <@      ulm> Chainsaw: results and rank still missing
21:27 <@      ulm> for 2012
21:27 <@  grobian> haha
21:27 <@      ulm> but maybe we should close it nevertheless
21:27 <+dberkholz> bbiab
21:27 <@      ulm> it's on the table way too long
21:27 <@ Chainsaw> ulm: Okay. Could you post the new status to the bug and leave it open then please?
21:27 <@ Chainsaw> ulm: It stays on the table until it is sorted.
21:28 <@      ulm> will do
21:28 <@ Chainsaw> Any other business from the council?
21:28 <@ Chainsaw> Or shall we open the floor to the community at this point?
21:29 <@  grobian> I have nothing to raise
21:29 <@ Chainsaw> Okay, thank you.
21:29 <@ Chainsaw> Anyone wishing to raise issues with the council at this point? The floor is open.
21:30 < Zero_Chao> I would like to seek the councils advice on something.
21:30 <      johu> who is responsible to document the "one year end of support" decision and where?
21:30 *** Zero_Chaos yields to johu 
21:31 < scarabeus> johu: it will be written on council summary and then in the deprecation file, so no need to stamp it more
21:31 <@ Chainsaw> johu: grobian will add it to the summary, and that will be binding.
21:31 <@  grobian> refresh ;)
21:31 <@ Chainsaw> johu: grobian has added it to the draft summary, which will soon be binding.
21:31 <@ Chainsaw> johu: If you are happy with that answer, Zero_Chaos is next in line.
21:31 <      johu> thanks all for this wonderfull news ;)
21:32 < Zero_Chao> I'd like to try to get more qa added directly to portage. For the most part this is not really a council choice, however, one of the things I have found is we seem to have no policy on relative symlinks. I'd like to officially require relative symlinks.
21:32 <@ Chainsaw> Zero_Chaos: Could you raise that on -dev please?
21:32 <@ Chainsaw> Zero_Chaos: Provided there is no resulting riot, it can be tabled for the next meeting, in February.
21:32 < Zero_Chao> Chainsaw: I can and will, but I wanted to see if the council thought that was worthwhile to raise or if I was wasting time.
21:33 <@  grobian> Zero_Chaos: I vaguely recall having this seen again
21:33 <@  grobian> s/again/before/
21:33 < Zero_Chao> secondarily, I have one more. Also will be sent to -dev but wanted to get some feedback.
21:33 <@  grobian> and that there was somethign impossible to do relatively
21:34 < Zero_Chao> I'd like to raise the idea of micro-eapis. So we can have a new 5.1 or whatever with just one feature, instead of bikeshedding all the features at once we can approve each at a time.
21:34 <@ Chainsaw> Zero_Chaos: Provided you can generate some semblance of agreement on -dev, I am happy to put it to a vote.
21:34 < scarabeus> Zero_Chaos: hahum, that would be nuts in tree, what for would you need it?
21:34 <@ Chainsaw> Zero_Chaos: You'd have to get that approved by zmedico and the authors of other package managers, as you would significantly increase their workload.
21:35 <@ Chainsaw> Zero_Chaos: On personal title, it seems unlikely to succeed.
21:35 < Zero_Chao> scarabeus: I notice a very long time between eapis due to ONE controversial feature being bikeshedded.
21:35 <@      ulm> Zero_Chaos: I for my part am not willing to draft PMS versions more often
21:35 <@ Chainsaw> Zero_Chaos: With my council hat on... you're welcome to raise it on -dev.
21:35 < Zero_Chao> Chainsaw: zmedico already does it
21:35 <@  grobian> Zero_Chaos: I think this is a misconception
21:35 <@  grobian> Zero_Chaos: EAPI6 could just contain one single feature
21:35 <@ Chainsaw> Zero_Chaos: We have been speedy with EAPI5.
21:35 <@      ulm> Zero_Chaos: but if you would volunteer, go ahead ;)
21:35 <@ Chainsaw> Zero_Chaos: By picking all the non-controversial features and voting them in at a rapid pace.
21:35 <@  grobian> Zero_Chaos: the work is still the same, it needs to make sense, have PMS stuff, etc.
21:36 < Zero_Chao> each new changes often has a EAPI 5-some-new-feature already implemented in portage
21:36 < Zero_Chao> so that much isn't really new
21:36 <@ Chainsaw> Zero_Chaos: So that seems to be punishing us for past results, rather than the current situation.
21:36 < Zero_Chao> Chainsaw: it's not an attempt to punish anyone, merely to make it harder to stall development as a whole.
21:36 <@ Chainsaw> Zero_Chaos: Overworking ulm is also risky business.
21:36 <@  grobian> Zero_Chaos: it's always easier to work on your own, not caring about anyone else (re EAPI 5-some-new-feature)
21:36 < Zero_Chao> if the only reason this is a bad idea is overworking ulm then I'll just have to start helping him :-P
21:37 <@  grobian> I'll record that in the summary :P
21:37 <@      ulm> another aspect is that dev need to remember features of all eapis
21:37 < Zero_Chao> With respect, the focus of this question is fading, and I have the input that I desired. Thank you for sharing your experiences
21:37 <@      ulm> *devs
21:38 <@ Chainsaw> Then we will move on Zero_Chaos, thank you.
21:38 <@ Chainsaw> Any other questions please?
21:38 < Zero_Chao> ulm: I'll officially write it up for -dev later. we can chat at another time.
21:38 <@      ulm> so unless we have a deprecation scheme, more than one or two per year isn't feasible IMHO
21:38 <@ Chainsaw> If not, then I propose that we hold our next meeting on February 12, 2013 at 20:00 UTC.
21:38 <@ Chainsaw> Does that work for everyone please?
21:39 < scarabeus> wfm
21:39 <@      ulm> fine
21:39 <  WilliamH> Chainsaw: that's fine for me.
21:39 < scarabeus> btw just offtopic question: anyone knows if there is some progress on the unified dependencies concept?
21:39 <@ Chainsaw> dberkholz: Does Feb 12 20:00 UTC work for you please?
21:39 <@ Chainsaw> grobian: And you?
21:40 <@Betelgeus> scarabeus: do you mean exherbo style?
21:40 <@  grobian> yes, I think it does
21:40 <@Betelgeus> scarabeus: I remember it being put to Portage some years back but then I never had the time to push it more
21:40 <@Betelgeus> feb 12 is fine
21:41 <@ Chainsaw> Betelgeuse: Excellent. That's nearly everyone.
21:41 < scarabeus> Betelgeuse: brian was talking about it few months ago, but i dont remember how it ended :-)
21:41 *** Chainsaw closes the meeting
21:41 <@ Chainsaw> Thank you everyone.
21:41 <@      ulm> thanks for chairing
21:41 <@ Chainsaw> See you in February.