17:06:29 <mmaslano> #startmeeting FESCO (2011-11-07)
17:06:29 <zodbot> Meeting started Mon Nov  7 17:06:29 2011 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:06:36 <mmaslano> #meetingname fesco
17:06:36 <zodbot> The meeting name has been set to 'fesco'
17:06:42 <mmaslano> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
17:06:42 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:06:56 <mmaslano> #topic init process
17:07:20 * nirik is here.
17:07:26 * t8m too
17:07:34 <mmaslano> I forgot to send meeting agenda, so I hope everyone is here anyway
17:07:34 * nirik thinks we might be missing some folks due to time change.
17:07:46 <mmaslano> nirik: yes, I forgot on time change too :-/
17:07:54 * cwickert is confused about the meeting time
17:08:06 * t8m wonders if we should shift the time with the DST change
17:08:09 <cwickert> the wiki page still says we meet at 17:00 UTC
17:08:21 <nirik> yeah, we have switched in the past...
17:08:26 <cwickert> oops, it's 17:00 utc :)
17:08:41 <t8m> actually 17:08 UTC now :D
17:08:47 <mmaslano> only four of us?
17:08:52 <cwickert> alright, problem solved
17:09:10 <cwickert> but I'll need to leave early today, so lets start
17:09:47 <nirik> well, with 4 thats no quorum. ;(
17:09:53 <t8m> mjg59, ping? around?
17:10:15 <mmaslano> let's wait for a while
17:10:50 <cwickert> hooray
17:11:01 * nirik goes to grab coffee. back in a min.
17:11:01 <cwickert> now I can leave :)
17:11:08 <sgallagh> ?
17:11:16 <cwickert> we need to have a quorum
17:11:19 <mmaslano> sgallagh: 5 people, we have quorum
17:11:25 <sgallagh> ah
17:11:42 <mmaslano> do you want to start or wait for others?
17:11:55 <sgallagh> Sorry, DST issues. Yesterday the USA shifted an hour
17:12:52 <cwickert> I think we can wait for nirik to return, but that should be it
17:12:59 <gholms> ajax: You're here, right?
17:13:23 <ajax> i am
17:13:24 <mmaslano> so we can probably start with followups
17:13:50 <mmaslano> #topic #667
17:14:11 <mmaslano> #topic #667 Request to fix CRITPATH update process
17:14:19 <mmaslano> .fesco 667
17:14:20 <zodbot> mmaslano: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
17:14:57 <t8m> I think the bodhi changes we agreed on are still not implemented?
17:15:04 <nirik> t8m: yeah.
17:15:19 <nirik> also mjg59 started some discussion of proventesters on the list.
17:15:42 <nirik> but I'd like to see another week of feeback before we do anything with that. QA folks are still mulling it.
17:15:55 * t8m did not see any strictly negative response to that.
17:16:18 <mmaslano> nirik: fine with me
17:16:19 <t8m> (to the dropping of proventesters)
17:17:41 <j_dulaney> t8m  That's because today was the first some of heard of it
17:17:41 <t8m> nirik, can we somehow help with moving the bodhi change forward? Apart from becoming fedora infrastructure admins that is.
17:18:15 <pjones> sorry I'm late.
17:18:18 <nirik> t8m: not sure. I can ask lmacken. I'm sure if someone wanted to make a patch for it that would be appreciated. ;)
17:18:26 <pjones> totally spaced on the time change effecting our meeting time.
17:19:04 * mcepl strongly believes DST is pure evil ...
17:19:20 <nirik> yeah.
17:19:22 <pjones> mcepl: yep
17:19:29 <sgallagh> agreed
17:19:30 <nirik> so, proposal: defer this to next week.
17:19:36 <sgallagh> +1
17:19:38 <t8m> +1
17:19:40 <mmaslano> +1
17:20:07 <mjg59> Oh sigh I'm here
17:20:08 <mjg59> Sorry
17:20:22 <mjg59> I've gone through two DST changes in the past week and a half
17:20:43 <mjg59> +1
17:20:48 <ajax> +!
17:21:25 <mmaslano> if ajax is +1, then
17:21:40 <mmaslano> #agreed defer this to next week for response
17:21:44 <sgallagh> I think ajax is just very excited about deferring :)
17:22:03 <pjones> +¡
17:22:14 <mmaslano> new business
17:22:15 <ajax> +‽
17:22:29 <nirik> interrobang rules. ;)
17:22:42 <mmaslano> #topic #691 Please consider and approve Fedora 17 schedule.
17:22:48 <mmaslano> .fesco 691
17:22:48 <zodbot> mmaslano: #691 (Please consider and approve Fedora 17 schedule.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/691
17:23:15 <mjg59> +1
17:23:20 <pjones> -1
17:23:23 * nirik checks other distros/de's releases.
17:24:06 <pjones> I don't believe a 6 month schedule has really been working well for us in quite some time, so I'm not voting +1 to one.
17:24:18 <nirik> ubuntu - 2012-04-26
17:24:26 <nirik> pjones: do you have a counter proposal?
17:24:39 <pjones> nirik: 9 seems like it'd be worth trying for a while?
17:24:57 <pjones> though that's not the question we've been asked, obviously.  what we've been ask for is token agreement.
17:25:07 * t8m would like a slightly longer schedule as well
17:25:12 <sgallagh> pjones: Well, our schedule has largely been determined by the upstream GNOME schedule for a long time now
17:25:26 <nirik> pjones: sure, but we could say... no. ;)
17:25:35 <pjones> nirik: and I am ;)
17:25:57 <sgallagh> pjones: Can you point to a benefit to a longer schedule?
17:26:06 <adamw> it seems to me like switching to a nine month cycle is a major decision which should go through a process of its own and then be fed back into the menial 'drawing up the schedule' process once it had been agreed
17:26:08 <pjones> sgallagh: yes.  more time.
17:26:23 <mjg59> Not aligning to the gnome schedule does give us a pile of different issues
17:26:27 <ajax> six months really is barely a blink.
17:26:29 <nirik> issues with 9months: hard to avoid holidays on various cycles. Could cause issues with fudcon or budget.
17:26:42 <adamw> in other words, voting -1 on the specific dates of the f17 schedule, within the currently accepted framework that 'fedora does six month releases', seems like a silly way to raise the proposal 'let's not do six month releases any more'.\
17:26:43 <pjones> adamw: but again, what we've been asked for is token agreement.  In lieu of that discussion having happened, I'm not agreeing.
17:26:49 <nirik> pros tho: might align better with kde, more time to get things done.
17:26:51 <sgallagh> pjones: More time is not inherently a win
17:27:00 <pjones> nirik: we have the holiday problem with 6 months as well.
17:27:08 <sgallagh> If something isn't ready in 6 months, it's our prerogative to say "wait until the next release"
17:27:17 <mjg59> nirik: Given where the vast majority of our development focus lies, aligning with KDE seems like a very fringe benefit
17:27:18 <nirik> pjones: sure.
17:27:22 <sgallagh> pjones: But it's the same problem, not an ever-shifting problem
17:27:38 <nirik> mjg59: I don't know that it would, just tossing it out there.
17:27:41 <ajax> sgallagh: "but what happened to fedora being 'first'?"
17:27:47 <pjones> sgallagh: that's nice.
17:27:49 <mjg59> A longer release cycle means we spend more time in development rather than polishing
17:27:59 <ajax> which is a broken argument, but that doesn't mean people don't try it.
17:28:01 * cwickert wants to continue with the 6 months schedule and doesn't like slow-downs
17:28:11 <mjg59> If we assume (handwavily) that polishing takes a relatively constant amount of time then a longer release cycle results in more development being done
17:28:41 <sgallagh> ajax: It's a broken argument as you said. If it's ready, it gets released. If it's not, it catches the next release
17:28:44 <mjg59> But really if we're going to have this discussion then I think we need to actually prepare for it
17:28:49 * nirik nods.
17:28:50 <t8m> To me it still seems that the 6 months cycle means really just 3 months of disruptive development and that is very short time
17:28:51 <sgallagh> (or ends up a mid-cycle update, which happens)
17:28:55 <mjg59> So I'm happy to change to -1 in lieu of actually doing some research
17:28:59 <adamw> mjg59: that is extremely hand-wavy: the more development is done, the more polishing is needed. but i think you do get a _bit_ more dev time on a longer cycle.
17:29:03 <mjg59> I suspect I'll end up still in favour of six months
17:29:11 <ajax> i'm not really opposed to six month schedules though.  there's going to be a schedule; i guess that length works.
17:29:18 <pjones> sgallagh: except more often what happens is that we push features that aren't really done, and we mark them as done anyway while we limit the scope to something we probably wouldn't have signed off on at the beginning.
17:29:23 <pjones> sgallagh: that's my experience anyway.
17:29:26 <nirik> I'm happy to defer the schedule vote and ask pjones to submit a actual 9 month schedule plan. ;)
17:29:36 <sgallagh> pjones: That will happen on any time-driven schedule
17:29:39 <mmaslano> we had to change our release model more, if we want more time for polishing. I don't think 9 months will save us
17:29:40 <adamw> i'm really not sure this is the best way to go about re-considering the length of the release cycle. unless you really think you're going to go away and come up with a proposal to switch *f17* to a 9-month cycle, with no prior notice.
17:29:48 <sgallagh> pjones: Only feature-driven schedules can avoid that specific problem
17:29:50 <pjones> sgallagh: you say that, but I doubt you could back it up.
17:29:53 <sgallagh> (Bringing in others in the process, of course)
17:29:54 <t8m> Shouldn't the schedule be decided by the Board?
17:30:03 * nirik also wonders if this isn't a board issue... since it's longer term and non technical.
17:30:07 <pjones> sgallagh: it happens, but that doesn't mean it doesn't happen more with such a short time frame.
17:30:09 <mjg59> t8m: It's an engineering issue
17:30:20 <mmaslano> I'm missing details of this request in robyn's ticket
17:30:22 <cwickert> if we extent the development cycle to 9 months, then we have to extent the live cycle to 19 months. this means we have 3 more months for development but 6 more months for maintenance. as work force is limited, we in the end we have *less* resources for development
17:30:24 <mjg59> I think it's valid for us to provide feedback, even if the board makes the decision
17:30:41 <t8m> I mean the basic length of the schedule not the concrete dates within some limits
17:30:44 <ajax> cwickert: assuming we don't change the EOL schedule, sure.
17:30:47 <nirik> adamw: +1
17:30:51 <pjones> mmaslano: https://fedoraproject.org/wiki/User:Rbergero/F17DraftSchedule
17:31:03 <cwickert> ajax: I think people should always be able to skip a release
17:31:15 <mmaslano> pjones: I ment, why it is requested ;-)
17:31:26 <pjones> cwickert: that's an interesting point, but I'm not sure the assumptions it makes are set in stone.
17:31:29 <pjones> mmaslano: it's pro-forma.
17:31:55 <cwickert> pjones: but?
17:31:55 <mmaslano> cwickert: I agree, at least many do that
17:32:05 <pjones> cwickert: excuse me?
17:32:19 <cwickert> pjones: which assumption is not set in stone?
17:32:43 <mjg59> mmaslano: It's requested because it's always been requested, as far as I can tell
17:32:50 <pjones> that we'd actually have to extend the lifecycle, or for that matter that we actually have to provide updates in the extended timeframe.
17:33:03 <mjg59> I've got no idea what happens if fesco don't sign off on the proposed release schedule
17:33:04 <nirik> proposal: +1 f17 schedule, ask pjones to come up with a plan for 9 month cyles and get buyin from board/etc for f18? (because I kinda agree here that changing f17 right now is anoying to teams that might have planned for 6 months)
17:33:25 <cwickert> +1
17:33:27 <adamw> mjg59: for a start, i expect rbergeron would explode. especially if your rejection is on the grounds 'we'd like to chin-stroke about nine month releases for a bit, so just hold all your work until we're done.'
17:33:42 <ajax> anyway, i'm +1 to this specific request, it's exactly what you'd expect.  and while i'd like a re-evaluation of the broader 6-month heartbeat, i don't think we'd get any real results out of that.
17:33:46 <t8m> nirik, we are still just on the beginning of F17 so I think change to 9months should not be impossible
17:34:09 <mjg59> adamw: I mean, I don't see why this is fundamentally fesco's decision
17:34:11 <nirik> t8m: sure, if theres a concrete 9 month plan we all like, we can revise the f17 schedule?
17:34:25 <nirik> mjg59: I think orig it was due to fine tuning...
17:34:37 <mjg59> adamw: In that if fesco says no then the entirely appropriate thing to do would be to follow that schedule anyway
17:34:43 <nirik> ie, other distros releases shouldn't be the same time.
17:34:46 <adamw> mjg59: heh
17:34:57 <nirik> we should know when out upstream projects release so we could say 'oh no, wait a week'
17:34:59 <adamw> mjg59: point
17:35:01 <brunowolff> Maybe people should think about starting work earlier (after branch) instead of extending the time between releases.
17:35:15 <pjones> brunowolff: we do start work after branch
17:35:31 <t8m> brunowolff, that really depends on teams
17:36:05 <t8m> brunowolff, f. e. anaconda team is usually hard working on stabilizing the branch I think
17:36:07 <cwickert> pjones: you can either extent the lifecycle to 19 months or reduce it to 10. the latter will not make users happy, the first not maintainers
17:36:23 <nirik> but it would make users happy.
17:36:24 <pjones> cwickert: you can also redefine specific aspects of the lifecycle.
17:36:31 <kk4ewt> some people at Fudcons have been asking for a longer release cycle to hopeful get more contributors from the enterprise as well
17:36:38 * nirik knows several that would be overjoyed with 19months.
17:36:42 <cwickert> pjones: such as?
17:36:51 <drago01> kk4ewt: doubt that would happen
17:36:58 <pjones> cwickert: such as when we stop doing non-security updates ;)
17:37:02 <mjg59> There's no inherent reason for the lifecycle to be two releases + one month
17:37:06 <drago01> for that the support cycles have to be much longer
17:37:20 <cwickert> kk4ewt: AFAIK all this was for a longer live cycle, not a longer development cycle
17:37:40 <kk4ewt> cwickert,  can be both
17:37:48 * gholms rings the 15 minute bell
17:37:51 <notting> sorry, missed time change, was grabbing some food
17:37:55 <mmaslano> gholms: thanks
17:37:56 <cwickert> kk4ewt: well, that's what I remember
17:37:59 <pjones> notting: I did the same thing.
17:38:00 <drago01> also the 6 months cycle aligns pretty welll with some upstream projects
17:38:08 <cwickert> +1 drago01
17:38:21 <kk4ewt> and is killing the QA team
17:38:25 <cwickert> Gnome, KDE, Xfce (12months)
17:38:26 <mmaslano> we can't vote for 9 month development cycle without thinking about lenght of suport
17:38:37 * nirik finds the 9 month cycle idea intriguing, but it's hard to fit into things.
17:38:47 <nirik> cwickert: Xfce isn't really any defined cycle. ;)
17:38:48 <pjones> drago01: anyway, the reason I'm saying that I'm using my vote to vote -1 is that I think this discussion needs to happen *before it gets to us for approval*.
17:39:01 <cwickert> nirik: it is, at least on the paper ;)
17:39:12 <cwickert> they started with 4.8
17:39:14 <drago01> pjones: ok fair enough
17:39:15 <nirik> cwickert: yeah, but that paper gets lots of whiteout. ;)
17:39:18 <nirik> anyhow.
17:39:27 <cwickert> pjones: you mean something like 9 months full updates, 9 more months of security updates?
17:39:27 <mjg59> #proposal Assume that the proposed schedule based on a 6 month release will be followed, but leave things open for discussion about overall release cycle changes
17:39:43 <pjones> cwickert: that would be one example of what you could change.
17:39:54 <nirik> sure, thats essentially what I proposed a while ago, so +1
17:39:57 <mmaslano> could we discuss it with Robyn and Board people?
17:40:08 <mjg59> mmaslano: I'd hope so
17:40:12 <cwickert> pjones: IMHO this is the only example because we cannot stop in the middle of a cycle
17:40:27 <t8m> alternative proposal:
17:40:59 <nirik> also playing into things: when branching occurs.
17:41:22 <nirik> and if its more devel time before feature freeze, or more bugfixing time after.
17:41:34 <t8m> #proposal Pjones will start discussion on fedora-devel and the final vote on the schedule is deferred to the next meeting.
17:41:47 <mmaslano> +1 to t8m's proposal
17:41:48 <sgallagh> t8m: +1
17:41:49 * nirik is -1 to that.
17:42:00 * rbergeron looks in
17:42:21 <rbergeron> ohmygod
17:42:39 <drago01> ugh no
17:42:42 <cwickert> -1
17:42:49 * nirik can just see the horrified look on rbergeron's face from here.
17:43:02 <mjg59> There's no way we could have this conversation in a week
17:43:06 * pingou hands a camera to nirik
17:43:16 <cwickert> right, it's too late for F17 already
17:43:17 <rbergeron> Sorry, Robyn was working on the webpage promo and now has heartburn
17:44:08 <mjg59> cwickert: No, I don't think that follows
17:44:16 <notting> caught up now. i'm +1 to mjg59's proposal, -1 to t8m's
17:44:20 <mjg59> cwickert: If we can slip by several weeks at the end of the cycle, we can slip by three months pratway through
17:44:33 <sgallagh> mjg59: I disagree
17:44:38 <mjg59> It changes various people's expectations, but we *can* do it
17:44:48 <nirik> we can. we shouldn't.
17:44:50 <mjg59> Whether it's a good idea is an entirely separate discussion
17:44:51 <cwickert> mjg59: if we now argue for 4 weeks but in the end agree to continue with 6 months, we have a problem
17:44:53 <sgallagh> We haven't established whether the additional time would be before or after Feature Freeze, or some amount of both
17:45:04 <mjg59> cwickert: We should assume that F17 is going to be six months
17:45:09 <cwickert> alright
17:45:13 * nirik wonders what the votes tally is.
17:45:35 <sgallagh> #proposal: Approve rbergeron's F17 schedule and open a dialog for F18
17:45:37 <rbergeron> okay, so, a few things: I think this is just altogether a bad time to think about this for F17. I'm asking for an extra week, if we want to take that up with teh board as well, that's fine. Though IIRC, Fesco has the call on the schedule.
17:45:50 <cwickert> +1 to sgallagh
17:46:10 <nirik> +1
17:46:15 <t8m> I am +0
17:46:22 <pjones> sgallagh: obviously I'm okay with that, though I can't vote plus one to it because that would remove the entire purpose of my dissenting vote.
17:46:24 <rbergeron> I think that having a serious session on (a) schedule and (b) feature process, and how those would work together, for F18, in a lengthened way, or at least an improved way, would be AN EXCELLENT FUDCON IDEA. Or at least, a nice group work idea.
17:46:34 <ajax> +1 to sgallagh
17:46:52 <notting> sgallagh: modal dialog?
17:46:59 <notting> in all seriousness, i can be +1 to that
17:47:11 <mmaslano> rbergeron: Fedora is upstream for RHEL. Did you speak with them? ;-)
17:47:14 <mjg59> Well sure +1
17:47:17 <rbergeron> WHO?
17:47:33 <rbergeron> I'm saying that the DISCUSSION is a good idea. Not that it IS a good idea :)
17:47:46 * nirik reads +5 there
17:47:49 <t8m> So it is already too late for the feature process changes for F17 as well?
17:48:04 <notting> t8m: i suspect it depends on what the changes might be
17:48:47 <sgallagh> nirik: Yes, I counted 5 +1s, t8m's +0 and pjones' -1
17:49:03 <mmaslano> #agreed Approve rbergeron's F17 schedule and open a dialog for F18
17:49:23 <gholms> Any dialog-related action items?
17:49:27 <mmaslano> what about discussion with board?
17:50:15 <nirik> I sure hope the Board is involved...
17:50:21 <sgallagh> pjones: You're driving this discussion. Would you mind raising it at the next Board meeting?
17:50:33 <rbergeron> mmaslano: the schedule is ratified by fesco. http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Schedule_Methodology
17:51:09 <rbergeron> But if you guys want to consult them, by all means. :)
17:51:10 <mmaslano> ok, new topic
17:51:32 <sgallagh> rbergeron: Schedule is one thing; lifecycle is something else
17:52:13 <rbergeron> sgallagh: Ah, you mean with regards to major changes, not F17.
17:52:19 <sgallagh> yes
17:52:32 <sgallagh> Sorry for the confusion
17:52:39 <mmaslano> sgallagh: do you want to start discussion?
17:52:48 <rbergeron> np, just wanted to make sure everyone was on teh same page (I was in a different book, apparently, let alone page)
17:52:59 <pjones> sgallagh: lemme see when that is before I agree to it
17:53:32 <sgallagh> mmaslano: I'm not sure I'm the right person to do so. In general I'm opposed to switching to a longer schedule. (I'm eligible for convincing though)
17:53:56 <mmaslano> I'd like to go to next topic if anyone wants everything else then please in new ticket
17:54:03 * gholms rings the 30-minute gong
17:54:12 <sgallagh> mmaslano: please do
17:54:14 <t8m> mmaslano, +1
17:54:14 * nirik waits for next topic
17:54:17 <mmaslano> #topic #692 Adjust FESCo election policy
17:54:22 <mmaslano> .fesco 692
17:54:24 <zodbot> mmaslano: #692 (Adjust FESCo election policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/692
17:54:38 <cwickert> +1 to my own propsal :)
17:54:48 <cwickert> proposal*
17:54:57 <pjones> sgallagh: so... if I read right, it's tomorrow morning at 11 EST5EDT?  or is it 10 EST5EDT?
17:55:00 <sgallagh> I'm in favor of allowing heavily-involved QA members eligible for FESCo
17:55:07 <t8m> Who defines the FESCo election policy?
17:55:13 <nirik> t8m: we do. ;)
17:55:16 <gholms> t8m: FESCo does.
17:55:16 <mmaslano> strange
17:55:17 <pjones> t8m: looks like we do ;)
17:55:33 <nb> fwiw, although i'm not a fesco member, I am opposed to changing it in the middle of an election cycle, but am in favor of changing it
17:55:36 <mmaslano> I'm also for QA in fesco, they can provide different perspective
17:55:44 <sgallagh> nirik: That seems kind of ridiculous. I mean, we could just all vote that this current selection of members will rule in perpetuity.
17:55:45 <t8m> so eventually we can decide that only we are eligible to be voted :D
17:55:54 <sgallagh> (I've always wanted to try my hand at dictatorshiop)
17:55:56 <nirik> sgallagh: yep. ;)
17:55:59 <mjg59> sgallagh: And then the board could overrule us
17:56:05 <nb> I have nothing against QA in fesco, i just don't think we should change it after nominations are closed, because of one person who wants to run
17:56:08 <pjones> I can be +1 to allowing Fedora QA people to run.  Let's not let them win though, okay?
17:56:08 <nb> change it after this election
17:56:13 <mjg59> With great power comes etc
17:56:14 <nirik> I am not sure the group mentioned makes sense here.
17:56:23 <cwickert> pjones: lol
17:56:40 <nirik> nb: we have made exceptions before for people at the last minute...
17:56:47 <nirik> (too late submitting, etc)
17:56:47 <nb> well true
17:56:52 <mjg59> Nominations are closed now, so I don't see a problem with changing it at this point
17:57:01 <sgallagh> Yes, as I recall, we allowed some three nominations last cycle *after* the deadline
17:57:02 <nb> although i don't think we should have, but anyway
17:57:13 <ajax> i'm +1 to this change
17:57:18 <sgallagh> mjg59: Well, at the same time, one has to wonder if other QA people would have run, given the opportunity.
17:57:24 <brunowolff> Note that j_dunelay has been nominated but doesn't qualify under the current rules.
17:57:27 <t8m> sgallagh, +1
17:57:31 <nirik> This group isn't really used for anything I thought...
17:57:34 <sgallagh> But I'm inclined to say allow j_dulaney and change it for the future
17:57:43 <pjones> sgallagh: yeah, I'm +1 to that
17:57:44 <t8m> so I am, -1 for this cycle, allow it for the next
17:57:57 <mmaslano> hm, I'm also for this cycle
17:58:01 <nirik> how about we seperate out the issues here.
17:58:02 <nb> sgallagh, t8m i agree
17:58:09 * cwickert counts +5 and -1
17:58:15 <nirik> lets discuss the critera first, then decide if the new critera applies now?
17:58:37 <abadger1999> sgallagh: Try it, you'll deserve to have the work for perpetuity ;-)
17:58:39 <nirik> is there a better group we could use here? or just cla_done+1 group?
17:58:40 <mjg59> Oh right
17:58:53 <mjg59> It's clearly invalid for someone to nominate themselves if they're not able to be elected
17:59:39 <pjones> nirik: I would actually be okay with leaving it fairly restricted, but I do see the advantage of letting QA people participate.
17:59:39 <gholms> nirik: Are there no groups that have no real technical elements?
17:59:42 <EvilBob> mjg59: You mean vote?
17:59:47 * cwickert needs to leave now
17:59:50 <mjg59> So I'm +1 to this change, and also +1 to any nomination that didn't meet the criteria at the time of nomination being invalid
17:59:58 <pjones> mjg59: likewise.
18:00:01 <nirik> gholms: proventesters? bugzappers?
18:00:14 <pingou> gholms: ambassadors, design (to some extent)
18:00:20 <mmaslano> let's split votin into more steps
18:00:23 <sgallagh> gholms: documentation?
18:00:39 <mmaslano> #proposal 1: allow also QA in FESCo
18:00:51 <nirik> mmaslano: what do you mean by QA?
18:00:57 <t8m> mmaslano, that's too inconcrete to wote on
18:01:15 <cwickert_afk> lets say "members of the FAS group QA"
18:01:15 <mmaslano> hm
18:01:15 <cwickert_afk> https://admin.fedoraproject.org/accounts/group/members/qa
18:01:20 * abadger1999 notes that all of the mentioned groups are heavily involved in activities fesco regulates... which is why it was decided to give them a vote.
18:01:27 * nirik isn't sure he has a problem with cla_done+1
18:01:28 <sgallagh> mmaslano: Revise that to "Members of the qa group allowed to run for FESCo next cycle' (we can discuss the current cycle next)
18:01:35 <mjg59> EvilBob: ?
18:01:38 <mmaslano> sgallagh: ok
18:01:44 <nirik> abadger1999: the voting critera is ? cla_done+1 ?
18:01:50 <t8m> nirik, I'm ok with cla_done+1 as well
18:01:53 <nirik> sgallagh: what qa group?
18:01:56 <nb> jdulaney is not part of the qa group in FAS
18:01:57 <cwickert_afk> nirik: cla_done+1 means marketing, ambassadors etc
18:01:58 <mjg59> EvilBob: I don't know what you mean
18:02:01 <pjones> cwickert_afk: yes.
18:02:02 <abadger1999> nirik: I'm pretty sure.  I can check i nthe db for last election
18:02:10 <nb> he is part of proventesters
18:02:11 <nirik> cwickert_afk: yep.
18:02:12 <sgallagh> nirik: I withdraw that and happily back cla_done+1
18:02:22 <Viking-Ice> QA is only for autoqa these days if memory servers me right
18:02:29 <Viking-Ice> fas group
18:02:32 <cwickert_afk> I don't think we want ambassadors in FESCo, just like ambassadors won't accept a packager in FAmSCo
18:02:37 <nirik> yeah, it's not really used for anything.
18:02:43 <pjones> cwickert_afk: yeah
18:02:45 <cwickert_afk> (just as an example)
18:03:13 * t8m wonders if votes should not be the decision and not too strict selection of eligible candidates
18:03:16 <abadger1999> nirik: yep, CLA +1
18:03:27 <sgallagh> t8m: +1
18:03:30 <nirik> well, fesco covers a lot of areas... technical content...
18:03:37 <cwickert_afk> I am strongly opposed to CLA_done+1
18:03:40 <notting> well, as long as it's 'engineering' steering, i'd say: packager, proventester, qa, rel-eng
18:03:42 <nirik> why wouldn't an ambassador be good in fesco?
18:03:53 <cwickert_afk> we should at least restrict it to something technical
18:03:59 <pjones> t8m: so you're proposing... what?  Anybody involved in Fedora on a (handwavy) technical level is eligible?
18:04:15 <sgallagh> cwickert_afk: Well, we don't currently have such a grouping available  (necessarily)
18:04:19 * abadger1999 notes that cla +1 includes people who are marginally involved with fedora -- people who have an upstream  project on fedorahosted , for instance.
18:04:35 <pjones> abadger1999: yeah, that's why I'm against it.
18:04:38 <pjones> well, part of why.
18:04:47 <sgallagh> abadger1999: I agree with t8m that candidate selection shouldn't be too stringent
18:05:00 <gholms> Is it that hard for people who aren't in whitelisted groups to ask?
18:05:08 <cwickert> nirik: because many ambassadors have no clue about technical details and the group of ambassadors is HUGE, so we probably have many ambassadors elected for FESCo then
18:05:09 <mmaslano> we could say yes to qa in this election and think about details for the next one
18:05:15 <sgallagh> Votes will ultimately determine who the Fedora constituency wants to see in FESCo
18:05:23 <nirik> cwickert: I'm not sure people would vote for them... but ok.
18:05:41 <cwickert> take a look at the board elections: candidates from ambassadors always get elected
18:05:43 <pingou> what about packager, proventester, qt and other on case by case basis ?
18:05:53 <sgallagh> nirik: He makes a good point. Voting is largely name-recognition, and one overwhelmingly-large group may skew the votes to its own candidates
18:05:58 <cwickert> sounds reasonable
18:05:59 * nb is -1 to cla+1
18:06:00 <pingou> nirik: people vote for nicks/name they know
18:06:08 <nirik> sure.
18:06:09 * nb is fine with packager, proventester
18:06:15 <nb> releng if they aren't already one of the above
18:06:17 <cwickert> ok, proven packager then
18:06:23 * nirik notes we have a proposal to get rid of proventester. ;)
18:06:29 <cwickert> ouch
18:06:30 <mmaslano> nirik: yeah
18:06:37 * sgallagh considers rending this point moot by offering j_dulaney co-maintainership of one of his packages
18:06:39 <abadger1999> cwickert: That line of argument would raise the question, though, what makes testers better than your assessment of ambassadors?
18:06:41 * pjones actually like's notting's list modulo the proventester change: package, qa, rel-eng
18:06:51 <nb> sgallagh, yeah, i've considered just sponsoring jdulaney into packager
18:06:58 <pjones> abadger1999: direct technical involvement with current fedora.
18:07:00 <pingou> abadger1999: they don't necessarily :)
18:07:16 <cwickert> abadger1999: I assume that every proven tester has more technical insight than 90% of the ambassadors
18:07:18 * t8m is really -1 on the change now given this discussion
18:07:42 <pingou> FESCo could decide on case by case basis for people not part of one of the formentioned group to make sure that they have some sort of technical knowledge
18:07:57 <pjones> pingou: but we're not going to do that, because it's terrible.
18:08:03 <mmaslano> pingou: that's not right. We can't decide who can run
18:08:08 <nb> .fasinfo jdulaney
18:08:09 <zodbot> nb: User: jdulaney, Name: John Dulaney, email: j_dulaney@live.com, Creation: 2010-06-28, IRC Nick: j_dulaney, Timezone: US/Eastern, Locale: en, Extension: 5149140, GPG key ID: 20100628, Status: active
18:08:13 <zodbot> nb: Approved Groups: fedorabugs packager +proventesters cla_fedora cla_done cla_fpca ambassadors
18:08:20 * nb notes that jdulaney is now a member of packager
18:08:23 <t8m> hehe
18:08:27 <nirik> case by case is bad.
18:08:28 <mjg59> As of when?
18:08:29 * sgallagh snickers
18:08:33 <pjones> okay, so jdulaney is eligible anyway.
18:08:33 <t8m> so it's solved now?
18:08:41 <nirik> that means we are bringing in bias of current fesco on future fesco
18:08:42 <cwickert> pingou: case by case doesn't work. people need to nominate before we can decide and in order to nominate we need to have a criteria
18:08:46 <mjg59> pjones: Well presumably only if that was the case during nominations
18:08:51 <pingou> pjones: mmaslano true there needs to be a fix criteria
18:08:52 <tibbs> Well this is disappointing.
18:09:05 <pjones> mjg59: okay but still we can discus that outside of the policy discussion.
18:09:15 <pjones> or discuss it, if we feel so inclined.
18:09:33 <nirik> whats the current policy/?
18:09:35 <nirik> packager?
18:09:40 <t8m> yeah
18:09:42 <pjones> nirik: yes.
18:10:30 <abadger1999> dhttps://fedoraproject.org/wiki/FESCo_election_policy#Candidates
18:10:41 <notting> nb: yeah, i wonder how that happened. a little disingenous?
18:10:46 * nirik thinks we could get some good perspectives from bugzappers or proventesters, but not sure if that would leave things open to a flood of non tech people nominating.
18:10:48 <abadger1999> "Candidates may be any member of the packager group in the Fedora Accounts System. This helps ensure FESCo members have some experience with the processes of Fedora but still allows relatively new contributors to sit on FESCo and bring fresh ideas to the table. "
18:11:04 * nirik nods.
18:11:18 <mmaslano> I agree with abadger1999
18:11:22 <nirik> ok, so where are we here? is there a current proposal?
18:11:36 <mmaslano> #proposal Candidates may be any member of the packager group in the Fedora Accounts System. This helps ensure FESCo members have some experience with the processes of Fedora but still allows relatively new contributors to sit on FESCo and bring fresh ideas to the table.
18:11:51 * abadger1999 notes that he's just quoting current policy... which was decided on when he was on fesco... but that was in a different time.
18:11:52 <t8m> mmaslano, that is the current policy
18:12:28 <mjg59> Ok given that there is precisely nothing time-sensitive about this conversation, how about we move it to -devel@?
18:12:32 <mmaslano> does anyone have any other proposal or defer ths to next week?
18:12:34 <t8m> mjg59, +1
18:12:38 <mmaslano> mjg59: +1
18:12:45 <cwickert> mjg59: +1
18:12:49 <mmaslano> mjg59: do you want start discussion?
18:12:54 <mjg59> Sure I'll do that
18:13:08 <cwickert> thanks mjg59, I was afraid I had to do it
18:13:08 <nirik> ok.
18:13:11 <notting> mjg59: well, he wasn't eligible when he applied, or when the nomination period closed
18:13:14 * sgallagh abstains
18:13:18 * cwickert really needs to run now
18:13:22 <mmaslano> #action mjg59 will start discussion about candidates for FESCo on fedora-devel
18:13:32 <mjg59> However
18:13:40 <mjg59> jdulaney became a packager at 2011-11-07 18:08:03 GMT
18:13:47 <mjg59> Which is after nominations closed
18:13:55 <mjg59> So I'd add:
18:14:05 <pjones> Proposal: let jdulaney run anyway.
18:14:31 <mmaslano> +1
18:14:38 * pjones is +1
18:14:41 <ajax> +1
18:14:49 <t8m> It is nowhere said that he must be packager member at the time of nomination
18:14:54 <t8m> so +1
18:15:05 <cwickert_afk> +1
18:15:07 <mjg59> Eh, sure. I've no reason to think he's a bad candidate so I guess it does otherwise just seem churlish
18:15:11 <mjg59> +1
18:15:23 <nirik> +1
18:15:30 <sgallagh> +1
18:15:31 <nirik> especially since we have excepted others in the past.
18:15:32 <notting> t8m: it's sort of implied if that's the criteria. but, sure,+1
18:15:46 <gholms> t8m: One cannot be a candidate without membership in that group.
18:15:51 <mmaslano> #agreed jdulaney is acceptable candidate for this FESCo elections
18:16:01 <mmaslano> #topic #687 SysVtoSystemd
18:16:05 <mmaslano> .fesco 687
18:16:06 <zodbot> mmaslano: #687 (SysVtoSystemd) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/687
18:16:26 <pjones> gholms: yes, but there's a disparity in being a candidate and being nominated.  it's subtle, and in this case has become irrelevant.
18:16:52 <nirik> I think this is fine, and we should approve it once the feature comes thru again...
18:17:08 <nirik> try and get more going in f17.
18:17:18 <notting> what's involved to discuss w/o a feature?
18:17:34 <mmaslano> I guess no action is needed here. Now.
18:17:43 <pjones> yeah, I'm not sure why we're involved here at this point.
18:17:47 <sgallagh> notting: I think he wants FESCo to define a conversion schedule
18:18:00 <Viking-Ice> nirik wanted me to run it through again
18:18:14 <mjg59> Well +1
18:18:16 <Viking-Ice> I was just going to continue where we left off in F16
18:18:18 <nirik> Viking-Ice: yes, the feature should do that tho. ;) Sorry if that was confusing
18:18:57 * t8m is not sure that conversion of the remaining packages is really high priority. However no new package with sysvinit without systemd unit should be allowed in of course.
18:19:15 <sgallagh> t8m: That sounds like a packaging proposal
18:19:31 <abadger1999> sgallagh: it is in the guidelines
18:19:53 <t8m> sgallagh, yes, and it is already in the guidelines I think
18:19:54 <sgallagh> ok
18:20:18 <nirik> excellent.
18:20:21 * nirik wasn't sure it was.
18:20:28 <sgallagh> I proposed last cycle that we could consider removing the sysv support in F17 entirely
18:20:30 <Viking-Ice> so what we are waiting for wrangler crew to review this?
18:20:32 <sgallagh> Thus forcing upgrades
18:20:50 <notting> sgallagh: big old -1 for that
18:21:02 <t8m> sgallagh, I am against that for third party sysvinit scripts at least
18:21:25 <nirik> Viking-Ice: yeah, we can stamp it when it flows thru from that.
18:21:42 <mmaslano> #info no action from FESCo is needed at the moment
18:21:51 <mezcalero> (we cannot remove sysv compat anytime soon for the sake of compat with 3rd party software; maybe in 10y. however we should not make use of that in fedora anymore)
18:22:05 <sgallagh> t8m: Ok, a valid point. But perhaps we could decide this time around that if a package is still shipping the sysv script without a unit file, it should be blocked from the release?
18:22:28 <abadger1999> sgallagh: http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files   "Each package that contains software that wants/needs to start a traditional service at boot MUST have a systemd unit file. "
18:23:24 <nirik> sgallagh: we could see where we are before beta?
18:23:37 <sgallagh> abadger1999: Ok, fine. I'm proposing we block any packages that don't meet that MUST criterion
18:23:38 <t8m> nirik, rather before alpha
18:23:47 <nirik> sure.
18:23:57 <abadger1999> sgallagh: <nod> That's certainly something that fesco can decide to do or not.
18:24:14 <mmaslano> #info review state of sysv conversion before alpha
18:24:23 <nirik> sgallagh: block at alpha?
18:24:31 <sgallagh> Yes
18:24:37 <Viking-Ice> what about the obsoletes like I though anyterm was supposed to be removed in F15 then again in F16 but we are still shipping it?
18:24:40 <notting> although applying that only to systemd, and not any other packaging guideline seems a little odd
18:24:41 <sgallagh> That way they have until Beta to fix it or gtfo
18:25:19 <nirik> well, if you you mean block in koji, that could be a fair bit of rel-eng overhead...
18:25:24 <sgallagh> notting: That's highly-visible. Most other infractions are hidden at least
18:25:35 <nirik> I fixed 'foo' please unblock now (x300)
18:26:12 <t8m> nirik, do we have any other option?
18:26:20 * nirik ponders
18:26:51 <pjones> notting: well, in most cases I'd prefer not to punish people for our irresponsibly short development cycle.  Though in this case a) it's a fairly easy thing to fix, at least hopefully, and b) we're on the second release where it should be done.
18:26:53 <nirik> not sure there's much else I guess.
18:26:54 * nb would be willing to help if granted privs
18:26:58 * nb only has override right now
18:27:20 <nirik> Viking-Ice: we have ~300 or so left?
18:27:34 <Viking-Ice> around 330
18:28:04 <Viking-Ice> from a simple repoquery that probably pulls in a couple if packages that violate the guidelines as in are shipping both
18:28:16 <Viking-Ice> legacy sysv and systemd units
18:28:39 <nirik> I guess I'm a weak +1 to that idea, but agree that it's odd to block for this but not other packaging violations.
18:29:37 <Viking-Ice> I think we finished most of the heavy hitters in F16
18:29:39 * nirik looks at everyone else. votes?
18:29:50 * sgallagh is +1 to his own proposal
18:29:52 <mmaslano> #proposal block packages which doesn't have systemd unit file according to guidelines
18:30:06 <t8m> #proposal Warn on fedora-devel that FESCo might decide to block the packages that violate this packaging guideline before Alpha. Defer the decision on the blocking to next meeting.
18:30:07 <mmaslano> sgallagh: ^ is it ok?
18:30:41 <mmaslano> +1 to t8m's proposal
18:30:44 <sgallagh> mmaslano: #proposal Starting at Alpha release, block packages that do not have a systemd unit file as per packaging guidelines
18:31:04 <nirik> I suspect that many/most of the remaning packages are where packagers aren't very active...
18:31:17 <pjones> ... surely packages that don't have one and also do have sysv scripts.
18:31:26 <sgallagh> nirik: Then I rather feel this is a boon. We'll drop some packages that aren't being maintained.
18:31:31 * nirik nods
18:31:46 <sgallagh> pjones: Sorry, I'll clarify
18:32:00 <sgallagh> #proposal Starting at Alpha release, block packages providing services that do not have a systemd unit file as per packaging guidelines
18:32:44 <t8m> sgallagh, OK +1
18:33:05 <mmaslano> -1 we should start blocking also other packages with strong packaging violation
18:33:21 <t8m> mmaslano, that's true
18:33:28 <pjones> mmaslano: surely you could propose that separately under Open Discussion later? ;)
18:33:44 * nirik is still weak +1 to this.
18:33:49 <mmaslano> pjones: why should we treat systemd unit files differently?
18:33:54 <sgallagh> mmaslano: I'm inclined to agree, but let's take each violation individually
18:33:59 <sgallagh> Some of them have more value than others
18:34:30 <pjones> mmaslano: I'm not saying we should treat them differently - but what's wrong with enacting *specific* cleanups one at a time?
18:34:31 <sgallagh> I don't know that blocking a package because its spec file name doesn't match the package name is worth doing.
18:34:35 <nirik> we should probibly draft a actual policy here.
18:35:00 <nirik> ie, when can/should a package be blocked for packaging guidelines violations?
18:35:01 * notting is +1 to t8m's proposal (warn that we may) and we can work out the specifics
18:35:04 <abadger1999> and also more cost
18:35:29 <notting> blocking is painful, after all... guidelines require re-revieiw on unblock, etc.
18:35:32 <abadger1999> (for instance, bundled libraries are both higher value and higher cost)
18:35:45 <nirik> yeah, and we haven't blocked them. ;)
18:35:48 <nirik> for them
18:35:56 * nirik is +1 to t8m's as well.
18:36:04 <t8m> abadger1999, +1
18:36:15 * mmaslano is still for t8m's proposal
18:36:42 <sgallagh> I'm +1 for t8m's proposal for this week
18:36:42 * t8m is +1 to my proposal as well :)
18:37:14 <mjg59> +1
18:37:17 <mmaslano> #agreed on t8m's proposal
18:37:44 <notting> who wants to take action on a proto-policy for what we should o?
18:37:47 <notting> do, even?
18:38:53 <mmaslano> t8m: do you want to start discussion?
18:39:29 * nirik listens to the crickets chirp.
18:39:49 <sgallagh> I'll do it
18:39:51 <t8m> mmaslano, I'll write the warning e-mail to fedora-devel however I don't feel I can make comprehensive proposal for the blocking policy
18:40:12 <sgallagh> t8m: Ok, you write the initial warning, I'll follow up with my proposal :)
18:40:17 <mmaslano> #action t8m will write warning email, sgalagh will start the discussion about blocking policy
18:40:30 <mmaslano> #ticket #690 move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove
18:40:34 <mmaslano> .fesco 690
18:40:35 <zodbot> mmaslano: #690 (F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/690
18:40:47 <sgallagh> mmaslano: topic
18:41:07 <mmaslano> #topic #690 move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove
18:41:26 * nirik is a weak -1 to the feature. The advantages don't seem to me to be worth the pain and shuffling around of things. I guess I could be convinced otherwise.
18:41:45 * t8m is -1 to the feature for now as well.
18:41:52 <sgallagh> I am also -1
18:41:56 * mmaslano is strong -1
18:42:15 <haraldh> t8m, sgallagh, can you elaborate why?
18:42:24 <notting> i am a moderate +1. main concern would be the reliability of the implementation
18:42:44 <mjg59> I'm a fairly strong +1
18:42:54 <t8m> haraldh, basically I am not convinced it brings more positives than the havoc it causes
18:43:00 <sgallagh> haraldh: As a general rule, I'm opposed to any changes of such magnitude without (to my view) any significant advantage
18:43:08 <nirik> "less clutter" seems a poor reason for the pain. ;) snapshotting /usr ? how many people would do that?
18:43:21 <mjg59> sgallagh: Making the majority of the system read-only seems like a significant advantage
18:43:29 <haraldh> nirik, have you even read the recent feature page changes?
18:43:33 <nirik> yes.
18:43:39 <pjones> I'm a pretty week +1 so far.
18:43:39 <nirik> how would that work tho?
18:43:46 <nirik> surely people would want to apply updates?
18:43:54 <sgallagh> mjg59: You can't do that though. Updates wouldn't work.
18:44:00 * nirik re-reads to see if he missed anything.
18:44:03 <mezcalero> nirki: have you read my summary on the topic? i list a couple of reasons besides snapshotting
18:44:03 <abadger1999> mjg59: but -- what stops you from doing that already?  Isn't the feature actually... ability to make more of the system read-only?
18:44:05 <pjones> That's a bit of strawman
18:44:06 <sgallagh> This is only useful in systems that are mounted over NFS
18:44:15 <mjg59> abadger1999: Making /usr read-only right now achieves basically nothing
18:44:15 <haraldh> https://fedoraproject.org/wiki/Features/UsrMove#FAQ
18:44:24 <mjg59> Because so much of the system is in /
18:44:44 <pjones> We could certainly arrange things so that you can run RO at your site and move it to RW to do an update, then move back to RO.
18:44:58 <abadger1999> mjg59: uhhh..... I guess that shows that making /usr read-only is a means to an end rather than an end in itself.
18:45:03 <nirik> and so intruder waits until rw.
18:45:10 <mezcalero> (ntw, seems cwickert is +1, according to his comments in the ticket)
18:45:16 <mezcalero> s/ntw/btw
18:45:17 <mjg59> People have been complaining about the lack of support for NFS /usr
18:45:30 <abadger1999> mjg59: Since I certainly see the benefits of making /usr read-only right now.
18:45:39 <pjones> nirik: sure, but there is utility to limiting the attack surface, especially if we're limiting it to times people might be looking to see if things work in the first place ;)
18:45:43 <mjg59> So having /usr be read-only is a definite win
18:45:48 <nirik> mjg59: since the dawn of time.
18:46:03 <pjones> nirik: no, it used to work.
18:46:08 <abadger1999> mjg59: how does this feature achieve that though?  Isn't that the initrd changes that are separate from this feature?
18:46:17 <notting> mjg59: sure, but this is giving them NFS /usr in the context of making it just be a variation of NFS /
18:46:19 * drago01 is not really conviences that "read only" gains much
18:46:21 <drago01> if anything
18:46:23 <mjg59> But currently, as described in the feature page, if you want to have a shared /usr you then still need to update a huge number of packages that write stuff to /
18:46:23 <nirik> sorry, I was using hyperbole there.. yes, for a long time, and we said "doesn't work anymore, get over it"
18:46:35 <t8m> that's limiting attack surface of the whole earth to half of it :D
18:46:52 * sgallagh remains -1
18:46:58 * t8m remains -1 as well
18:46:59 <Viking-Ice> haraldh, I notice that you have not added to the FAQ "What happens to initramfs less setup with this move and how much larger the initramfs size get with this change and how it affects ( if any ) the memory size available to the secondkernel (i.e. crash kernel) since you know if it's is not sufficient you will get OOM if I'm not mistaken..." as I mentioned on G+
18:47:05 <pingou> if you do /usr over nfs why not /bin and /sbin to ?
18:47:25 <haraldh> Viking-Ice, so, you want initramfs less _and_ /usr on NFS ??
18:47:45 <mjg59> pingou: And /lib and /lib64
18:47:50 <haraldh> Viking-Ice, sorry can't do that for you now and afterwards
18:47:51 <pingou> mjg59: indeed
18:47:53 <mjg59> And yes you *can* do that
18:48:11 <mjg59> But it's an increase in management complexity
18:48:21 <mjg59> Whereas this is a one-off hit in packaging complexity that we can then ignore forever
18:48:33 <kay> but it's not atomic, if you update install stuff, multiple mountpoints is just a mess
18:48:47 <kay> hence the conversion to symlinks
18:49:06 <Viking-Ice> haraldh, not sure where nfs comes in the picture
18:49:41 <haraldh> Viking-Ice, ok, then make it /usr separate and no initramfs
18:49:53 * t8m doesn't want to imagine how the symlinking in %post will work in case of upgrades from older releases
18:49:54 <kay> Viking-Ice: the main feature is "system in one directory instead of 5 (rather randomly split today)"
18:50:11 <t8m> kay, what about /etc and /var?
18:50:14 <haraldh> Viking-Ice, does not work right now
18:50:23 <sgallagh> t8m: Why would symlinking happen in %post?
18:50:24 <kay> t8m: non-shareable by definition
18:50:33 <sgallagh> It would be done by %files, I'd assume
18:50:35 <kay> t8m: they are host-only
18:50:36 <nirik> sgallagh: the feature page suggests that
18:50:44 * sgallagh shudders and remains -1
18:51:00 <mezcalero> t8m: you don't have to imagine that, there are examples even in the feature page
18:51:10 <mezcalero> t8m: would be cool to read the feature page before voting!
18:51:46 <t8m> mezcalero, I said it wrong - what I wonder about is how fragile that will be in case of the upgrades
18:51:47 <abadger1999> kay: not true.
18:52:12 <t8m> kay, what but for snapshotting on upgrades you'll still have to snapshot the /etc and /var as well
18:52:20 <nirik> has dwalsh weighed in on the selinux changes? probibly just path changes?
18:52:22 <gholms> kay: And /boot, for that matter
18:52:29 <t8m> and /boot
18:52:30 <abadger1999> kay: /etc is a mixture of host and site configuration.  /var is a mixture of host and site data.
18:52:34 <mmaslano> and /var/lib/rpm?
18:52:45 <mezcalero> nirik: dwalsh said, he wants to be notified, so that he can fix the policy, that's all
18:53:02 <nirik> ok
18:53:07 <haraldh> mmaslano, what's with /var/lib/rpm ?
18:53:20 <abadger1999> kay: There have been several different systems that separated the host and site stuff in different ways (ltsp, stateless, ...)
18:53:34 <kay> think of 100 kvm instances running sharing the same /usr (== /System)
18:53:50 <haraldh> abadger1999, nothing is going away with this feature...
18:53:59 <mmaslano> haraldh: rpm database? do you want to snapshot from it to or not
18:54:09 <gholms> kay: And then you update one and have 99 VMs with incorrect rpm databases?
18:54:17 <mezcalero> or think 1000 light-weight containers with LXC, all running apache with slightly different configuration, sharing the same /usr
18:54:21 <abadger1999> haraldh: I'm just responding to kay's assertion that /etc and /var are host-specific *by definition*.
18:54:27 <abadger1999> haraldh: That assertion is incorrect.
18:54:29 <haraldh> mmaslano, personally I don't care much about snapshotting.. I want /usr shareable...
18:54:36 <kay> gholms: they usually have one single master not 100 rpm databases
18:54:54 <t8m> what's wrong with sharing the current usr
18:55:00 <t8m> is it non-shareable now?
18:55:01 <t8m> >D
18:55:03 <t8m> :D
18:55:05 <mezcalero> in fact, if we want to make it possible to share the OS between KVM/LXC systems and some master system that they all are based on, /usr as one tree is crucial
18:55:07 <kay> t8m: it's only half of the system
18:55:16 <t8m> half? really?
18:55:22 <haraldh> t8m, https://fedoraproject.org/wiki/Features/UsrMove#What_is_currently_broken_with_having_.2Fusr_as_a_separate_partition.3F
18:55:25 <mjg59> t8m: You then need some other mechanism to manage updates to the rest of the system
18:55:31 <kay> t8m: and you really want to share the libs in the rootfs too
18:55:35 <haraldh> t8m, read the FAQ please
18:55:39 <nirik> would this also suggest a change to default paritioning? ie, give people a /usr by default?
18:55:40 <mezcalero> t8m: if you share /usr right now, you miss almost everything that's interesting, such as libc
18:55:42 <mjg59> And yes, that's an obvious one
18:55:55 * sgallagh strikes the 15 minute gong
18:55:55 <mjg59> If /usr gets an update but your /lib doesn't, binaries may be missing symbols
18:55:56 <notting> abadger1999: 'by definition' means 'as defined in the FHS'
18:55:58 <gholms> kay: You can't share /boot, but that is still under package management.
18:56:06 <haraldh> t8m, https://fedoraproject.org/wiki/Features/UsrMove#So.2C_why_don.E2.80.99t_you_just_mount_.2Fusr_from_the_initramfs_and_leave_the_files_where_they_are.3F
18:56:20 * mmaslano bang 15 minute gong
18:56:21 <gholms> kay: And by the time you share that you're already PXE-booting.
18:56:30 <mmaslano> I suppose we want continue in discussion
18:56:33 <abadger1999> Some portions of /var are not shareable between different systems. For instance, /var/log, /var/lock, and /var/run. Other portions may be shared, notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.
18:56:34 <sgallagh> -1
18:56:42 <t8m> -1
18:56:42 <sgallagh> I'd rather call for a vote.
18:56:45 <mjg59> gholms: LTSP-type setups often have small local disks
18:56:52 <kay> gholms: please keep focus, that's not related to the discussion
18:56:53 <abadger1999> notting: So at least, the fhs does not define /var as host-specific
18:57:14 <gholms> kay: It isn't related to "they usually have one single master not 100 rpm databases"?  My apologies.
18:57:41 <notting> abadger1999: part of it is...
18:57:48 <mmaslano> your votes for continuing in discussion
18:57:52 <sgallagh> -1
18:57:54 <t8m> -1
18:58:02 <mmaslano> -1
18:58:04 <mezcalero> if you run 1000 light-weight apache containers on a single host, then you don't care at all about the RPM db...
18:58:14 * nirik is re-reading the wiki page, since it seems there's more stuff in talk than he recalls last time he read it.
18:58:38 <ajax> yeah, this is a lot more than i feel comfortable digesting in one go.
18:58:52 <abadger1999> haraldh: Your FAQ entry does nothing to say why your feature is going to make it so people can mount /usr separately -- if I have read everything correctly, in fact, it does not fix that -- the modern use of initrd fixes that.
18:58:53 <ajax> (also i apologize for being away, got pulled into a meatspace conversation)
18:59:21 <haraldh> abadger1999, https://fedoraproject.org/wiki/Features/UsrMove#So.2C_why_don.E2.80.99t_you_just_mount_.2Fusr_from_the_initramfs_and_leave_the_files_where_they_are.3F
18:59:34 <mmaslano> it's -3 for discussion, any other votes?
18:59:37 <nirik> so, vote? defer for more reading? sounds like several folks don't want more discussion...
19:00:09 * nirik is ok with more discussion, might be in the minority
19:00:21 <abadger1999> haraldh: Still doesn't fix the issue -- as others have pointed out, you still have things in the other non /usr directories.
19:00:21 * notting is +1 to having more discussion for now
19:00:51 <haraldh> abadger1999, like?
19:00:58 * sgallagh remains -1 to the feature. Nothing I've heard has made me waver.
19:01:03 <mjg59> Well, we might as well vote
19:01:04 <mjg59> If people aren't clear on the details by now then they're probably never going to be
19:01:04 <t8m> haraldh, configuration files can change on upgrades
19:01:22 * t8m remains -1 as well
19:01:25 <haraldh> t8m, in a cluster env with 100s of clients sharing the same /usr
19:01:26 <abadger1999> haraldh: /var/lib/rpm was just pointed out to you, was it not?
19:01:33 * mmaslano is still -1
19:01:44 <haraldh> t8m, you want config files to be handled with management sw
19:01:50 <mezcalero> abadger1999: rpm is not something you want to use to update the containers, but the master copy of the container
19:02:07 <haraldh> abadger1999, the clients with a shared ro /usr cannot use RPM!!!
19:02:10 <mezcalero> abadger1999: hence you don't want to share it between systems
19:02:21 <abadger1999> mezcalero: Exactly -- but /var/lib/rpm is not on /usr.
19:02:38 <haraldh> abadger1999, yes, and? the clients wont use rpm
19:02:40 <abadger1999> You want /var/lib/rpm shared between systems so you can do things like rpm -ql
19:02:43 <mezcalero> abadger1999: yupp, hence not shared, awesome!
19:02:54 <haraldh> abadger1999, no, you don't want :)
19:02:59 <abadger1999> rpm -qf /usr/bin/python etc.
19:03:02 <mezcalero> ajax: say something
19:03:21 <ajax> mezcalero: i'm pretty sure i said what i meant to.
19:03:46 <haraldh> abadger1999, and the current situation is the same
19:03:55 <t8m> also mixing up the move to usr with the bin/sbin merge is ugly
19:03:56 <ajax> i'm broadly in favor of the change but it's a lot of crap to digest and this meeting is already two hours longer than i wanted it.
19:03:58 <haraldh> sharing /usr does not involve sharing the rpm DB
19:04:05 <mmaslano> if I count correctly that we don't have 5 for accept or denial
19:04:06 <haraldh> the feature only grows /usr
19:04:10 <abadger1999> haraldh: correct.  You are the one proposing an invasive change and then saying it fixes that situation.
19:04:11 <ajax> so i don't feel comfortable voting on it right now.
19:04:16 <abadger1999> haraldh: when in fact, it does not.
19:04:27 <mjg59> t8m: FPC have already indicated that they're not enthusiastic about the merge of /sbin and /bin
19:04:37 <haraldh> yes, because it grows the binary part
19:04:38 <mjg59> So that's going to have to be a separate conversation anyway
19:04:54 * notting looks at the clock, digests ajax's statement
19:04:58 <mmaslano> #proposal defer to next week
19:05:03 <abadger1999> Yeah, we're against the /sbin /bin merge... / => /usr is up to fesco to decide.
19:05:08 * nirik was waiting for that proposal.
19:05:18 <t8m> +1 to defer
19:05:22 <sgallagh> +1 to defer (Still -1 on the feature though)
19:05:30 <ajax> sbin/bin really can't Just Work as it is.  i mean, consolehelper still exists.
19:05:44 <mmaslano> +1 we can't make any decision now anyway
19:05:46 <nirik> +1 I'd like to re-lookover the wiki page...
19:05:51 <haraldh> ajax, move it to /usr/libexec :)
19:05:53 <notting> ajax: that's a solvable problem
19:05:55 <mjg59> Ok, let's bring it up next week
19:05:57 <ajax> notting: i know.
19:06:00 <notting> +1 to defer for now
19:06:05 <notting> ajax: involves fire
19:06:10 <ajax> +1 defer like everyone else
19:06:21 <ajax> notting: the best solutions always do
19:06:23 <haraldh> and, yes.. please read the entire feature page and ask me, if things are not clear
19:06:59 <abadger1999> haraldh: I asked many questions that you moved to a different page -- you should answer them directly.
19:07:02 <nirik> haraldh: could you expand on what you envision for read-only and snapshots? ie, how would an end user use that setup, etc.
19:07:07 <mezcalero> may i ask that the ones who said -1 put together a lot of questions with the issues they have with the proposal?
19:07:09 <abadger1999> haraldh: It would be appreciated.
19:07:15 <mmaslano> #topic #689 Consider including bash-completion package by default (base, not core)
19:07:21 <mmaslano> .fesco 689
19:07:22 <zodbot> mmaslano: #689 (Consider including bash-completion package by default (base, not core)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/689
19:07:26 <mezcalero> so that the folks behind the proposal have the chance to reply to that in detail?
19:07:27 <nirik> mezcalero: can do.
19:07:33 <mjg59> #proposal Move all further feature discussion to next week
19:07:51 * nirik opens the talk page.
19:08:01 <t8m> mjg59, yeah, we are already very late
19:08:03 <mezcalero> i think the least the -1 sayers can do is give the submitters of the proposal the chance to convince them
19:08:31 <mezcalero> nirik: thanks, now i would like to see the same response from the other naysayers ;-)
19:08:45 <mmaslano> ok, let's move
19:08:54 <mmaslano> I will postpone this ticket for next week
19:08:54 <sgallagh> mezcalero: Don't worry, I have plenty to say :)
19:08:58 <mmaslano> #topic Next week's chair
19:09:10 <sgallagh> I'm just sticking to my "If I don't have anything nice to say, don't say anything" nature
19:09:43 <mmaslano> who will chair next week?
19:09:45 * nirik guesses he could do it if no one else will.
19:10:04 <mjg59> One thing - do we want to move the time back an hour again now that we're all off DST?
19:10:13 <mjg59> Because right now the meeting covers the entire period where I can get lunch
19:10:13 <nirik> mjg59: yes. +1 here.
19:10:20 <t8m> mjg59, +1 to move the time
19:10:24 <sgallagh> mjg59: +1
19:10:28 <notting> +1
19:10:28 <mmaslano> +1 to move time
19:10:28 <pjones> mjg59: +1 yes
19:10:33 <mjg59> And while I do love you all, I also love not collapsing with low blood sugar at the end of the day
19:10:41 <mmaslano> #action nirik will be chair next week
19:11:00 <nirik> 18UTC next week?
19:11:12 <mmaslano> probably
19:11:13 <mjg59> Yup
19:11:24 <sgallagh> May I make one more suggestion on the UsrMove discussion? Given the size of the topic, perhaps we should defer its decision until the new FESCo elections are complete?
19:11:29 <pjones> we could always redefine it as 1pm EST5EDT :)
19:11:34 <mmaslano> #agreed meeting will start at 18UTC
19:11:46 <pjones> sgallagh: meh.
19:11:55 <sgallagh> Since the new electees will be the ones who have to actually deal with it
19:11:56 <shaiton> if meeting channel is free :)
19:11:58 <notting> sgallagh: give people an opportunity to stack the board?
19:12:03 <mjg59> sgallagh: Given that we've all already spent time reading up on it, deferring until post elections just means that any new members have to get up to speed
19:12:17 <mmaslano> sgallagh: put your proposal into ticket please
19:12:17 <mjg59> Which means the discussion is even more drawn out
19:12:23 <nirik> quick, someone add that to the elections questionare. ;)
19:12:25 <sgallagh> notting: The candidates are already decided on
19:12:32 <mmaslano> #topic Open Floor
19:12:41 <sgallagh> mmaslano: I will do so
19:12:43 <mmaslano> I hope no one has any issues for this meeting
19:13:06 * mmaslano will end meeting in few minutes!
19:13:41 <nirik> thanks for chairing mmaslano
19:13:52 <sgallagh> mmaslano: Thanks for chairing.
19:13:54 <mmaslano> #endmeeting