17:29:37 #startmeeting FESCO (2013-08-14) 17:29:37 Meeting started Wed Aug 14 17:29:37 2013 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:29:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:29:37 #meetingname fesco 17:29:37 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 17:29:37 #topic init process 17:29:37 The meeting name has been set to 'fesco' 17:29:37 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 17:29:59 hello, world. 17:30:05 Aloha 17:30:08 hello, pjones 17:30:13 also everyone else 17:30:24 hi 17:30:25 sgallagh: was I supposed to be wearing my aloha shirt today? 17:30:40 t8m regrets, he can't make it today 17:30:43 I'd prefer that to you *not* wearing it ;-) 17:31:16 Hello 17:31:27 Hello all 17:31:40 abadger1999: you around? 17:31:48 Ah.. yeah. 17:32:10 * abadger1999 stops reading about SCLs and pays attention to the meeting :-) 17:32:13 cool. Lets go ahead and get started then... 17:32:25 We have first up our sendmail/rsyslog tickets: 17:32:31 #topic #1143 F20 System Wide Change: No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail 17:32:31 .fesco 1143 17:32:31 https://fedorahosted.org/fesco/ticket/1143 17:32:32 nirik: #1143 (F20 System Wide Change: No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail) – FESCo - https://fedorahosted.org/fesco/ticket/1143 17:32:38 what do we want to do here? 17:32:47 did you speak about it on FLock? ;-) 17:32:57 mmaslano: It was a running joke at Flock -_- 17:33:27 cool 17:33:28 If we are splitting into products post-F20, I think it's reasonable to give spins the freedom for F20 17:33:45 * nirik is ok with that too. 17:33:58 mitr: I can get behind that (especially since most of the spins plan on killing off sendmail) 17:33:58 mitr: That combined with what notting said in ticket about the current status makes sense to me. 17:34:05 * pjones is too. would also vote +1 again to just removing the damned thing 17:34:07 i'm okay with that too 17:34:08 yeah, I don't care about it if we have really tiny minimal, core 17:34:27 * nirik would also vote to remove it, but unless anyone else changed votes... 17:34:35 I think that we do need some sort of story about alerting in the base design. 17:34:53 nirik: Perhaps worth just re-voting to make sure? I forget who was against it originally 17:35:03 and i don't think that sendmail is that story, but... 17:35:22 Would rather not vote again on removal but is +1 to letting hte spins do their own thing. 17:35:24 it was my understanding that mitr argues that it _should_ be in the fedora base design. is that correct? 17:35:38 I'd note that if most spins are already removing sendmail, it might make sense to instead remove it from @core, and list it in comps for to the spins want to ship it 17:35:40 Kinda defining what we meant as "this applies to the dvd install" for F20 17:35:47 kalev: it is removed from core. 17:35:47 mattdm: No. If you were 0 based on that understanding, just be +1 and make everyone happy :) 17:35:51 kalev we *did* rmeove it from core 17:35:53 it's only still in standard. 17:35:59 sorry, I mixed up the names. 17:36:00 mitr: that is, in fact, the case. 17:36:00 mattdm: since nobody gets alerted by it, it would be hard for it to be the alerting mechanism. 17:36:11 pjones a-yup. 17:36:12 My argument was that 1) lacking a specific product/direction, we should be doing locally optimal decisions, and 2) removing sendmail for the space/time savings is not locally optima. 17:36:23 I agree with mitr 17:36:34 wouldn't make more sense to review all groups and cut them down? 17:36:56 what is "locally" in your argument? 17:36:59 I would guess that even if we did put a MTA in an official base design it probably wouldn't end up being sendmail 17:37:06 local to spins? local to fedora? local teach install? 17:37:06 mattdm: if you already did it, and you didn't like only those two, then fine 17:37:09 proposal: revisit: remove sendmail from standard 17:37:10 +1 notting_ 17:37:44 -1 17:37:46 mattdm: "local" as in "this decision alone, without giving significant weight to any particular spin/target use case" 17:38:08 nirik: +1 (as before) 17:38:16 * nirik is +1 to his proposal as before 17:38:17 nirik: +1 Kill it with fire, I'll provide the matches. 17:38:24 thats +3, -1 so far 17:38:29 (wait, are we voting on "should we revote"?) 17:38:34 heh 17:38:40 yeah, what' the current proposal? 17:38:42 85% of installs sendmail gets disabled so why keep pushing it 17:38:44 I assumed we were revoting on "Remove it" 17:38:45 nirik: -1 (but would be automatically revisited / abolished by seetting up the products) 17:38:46 mattdm: no, I am asking for a revote to see if anyone changed their minds. 17:38:55 Southern_Gentlem: prove it ;-) 17:39:17 thats +3, -2 so far 17:39:30 mmaslano: proposal: revisit: remove sendmail from standard 17:39:33 my abstaining was totally based on the argument I heard that /usr/bin/sendmail (not necessarily sendmail the mta) should be part of the standard base we are offering to people 17:39:52 -- I agree with that argument. 17:40:01 and I was abstaining pending giving people some time to actually draw up what that standard base is beyond "we know it when we try to remove things from it and people yell" 17:40:03 notting_: and it's unclear how much good that can do without user configuration anyway, given that most people's port 25 outbound in many countries looks like: http://www.fpaste.org/32126/50382013/ 17:40:05 I'm fine if no one changed their minds, just wanted to know that. 17:40:32 * pjones is still +1 17:40:51 thats +4, -2 so far 17:41:21 who's not yet voted? :) 17:41:26 abadger1999 and mattdm 17:41:36 I voted -1 and was counted 17:41:46 Oh, I missed that. Sorry 17:41:50 mmaslano and mattdm 17:41:55 I didn't vote, I'm 0 now 17:42:04 ok, so no pass. ;) 17:42:07 next proposal: 17:42:08 Proposal: Let spins contain the package set they want. Our previous proposal should be seen as applicable to the dvd and netinstall rather than spins. 17:42:10 And once again it's up to mattdm 17:42:26 nirik: Well, if mattdm moves to +1, it's a pass... 17:42:33 mattdm: couldn't you rework all groups? :) 17:42:41 sgallagh: sure. I just thought he was continuing to abstain. ;) 17:43:03 Well, since we are allowing removing from spins _anyway_, the argument of "meh, let's not change it until we have a base design document" isn't much weight 17:43:23 also most people can't meaningfully run an mta without configuring it manually. 17:43:25 so I guess I'm +1 to "everyone's removing it anyway so let's just remove it from @standard" 17:43:25 abadger1999: +1 (with the caveat that if they go too crazy we can revisit) 17:43:27 mattdm: heh -- are you trying to get me to vote -1 to my own proposal ;-) 17:43:31 which makes installing it manually not much of a hurdle. 17:43:34 * sgallagh gets grumpy when people abstain where an abstention is the same as a -1 17:43:36 ok, so then it passed? 17:43:42 it seems to have passed. 17:43:42 yes. 17:44:11 huzzah? 17:44:14 huzzah. 17:44:18 \o/ 17:44:18 #agreed revisited no default sendmail proposal and approved it this time: (+5, -2) 17:44:23 next up... 17:44:26 sgallagh: I thought in fesco abstentions didn't work that way -- only in FPC were abstentions equivalent to -1 17:44:33 #topic #1144 F20 System Wide Change: No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog 17:44:33 .fesco 1144 17:44:33 https://fedorahosted.org/fesco/ticket/1144 17:44:34 nirik: #1144 (F20 System Wide Change: No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog) – FESCo - https://fedorahosted.org/fesco/ticket/1144 17:44:54 abadger1999 it was only the case because it was on the line and everyone knows one more +1 would push it over 17:45:04 abadger1999: In this particular instance, abstaining (and thereby forcing no decision) is equivalent to voting against it. 17:45:14 Since "no decision" is the opposing option 17:45:34 moving on... 17:45:38 so if it's e.g. +4/-4, and the last person abstains, that's the same as voting -1, right? 17:45:48 wwoods: Effectively, yes. 17:46:03 wwoods: yes but +4/-3/ and two abstentions would pass 17:46:14 right, so do we want to see if anyone changed their minds on this one too? 17:46:14 okay, so, for rsyslog... are we redoing the same vote? 17:46:21 abadger1999: No, all votes from FESCo have to be +5 to pass 17:46:22 abadger1999: ? I never saw it that way. 17:46:27 Unless that changed when I wasn't looking. 17:46:30 I'm pretty sure I was +1/+1 for remove from @core/@standard on this one 17:46:37 which means that there was a different split 17:46:37 abadger1999: no... 17:46:54 I changed my view after playing with journalctl more, so I'm +1/+1 as well (which last I saw did *not* change the outcome) 17:47:21 nirik: okee dokee -- that was what I saw historically but maybe I haven't been reading close votes for a long time. 17:47:37 i am +1 (as before) 17:47:49 huh. I always saw it was majority of votes needed to pass something... 17:48:01 * pjones is +1 17:48:41 abadger1999: I don't know if you're wrong or if we accidentally changed or if we intentionally changed before I was on fesco or what, but AFAIK it's always been you need 5 + votes to pass. 17:48:43 +0 (same as last time) 17:48:48 so, before it was Current vote: +3 (mattdm, notting, pjones):-4 (mitr, mmaslano, t8m, sgallagh) 17:48:55 +1/-1 to core/standard (like last time) 17:49:07 * abadger1999 notes that he was on the first elected fesco so his information could be.... dated. 17:49:10 this means that the point of order comes in pretty significantly with t8m not at this meeting 17:49:13 pjones: it's always been +5 in fesco afaik 17:49:38 https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=Development/SteeringCommittee#Agenda 17:49:42 * nirik is with mitr 17:49:43 says 5 votes 17:49:59 stil +1/-1 17:51:09 so where are we then... 17:51:34 okay. the vote for remove from @standard changes from +3/-4/2 to +4/-3/3, I think 17:51:49 Er. 17:51:53 Both numbers shouldn't go up. 17:51:54 wait no +4/-2/3 17:52:05 (better?) 17:52:11 in any case it doesn't pass. 17:52:15 At least the total count is right now ;) 17:53:10 so, next then would be if we care if spins remove it... 17:53:12 So now on to proposing whether spins can override this? 17:53:40 +1 to letting spins override 17:53:43 If the answer for that isn't the same as the answer for sendmail, I'd like to hear some good 'splaining 17:53:53 Proposal: Let spins contain the package set they want. (within reason). Our previous proposal should be seen as applicable to the dvd and netinstall rather than spins. 17:53:57 +1 17:54:19 +1 17:54:20 I'm +1 to letting spins override, but that's predictable because that'd be the outcome of +1 on the previous thing (just the override would be backwards.) 17:54:26 +1 to letting spins override 17:54:26 +1 17:54:59 +1 to override by SIGs 17:55:15 i am +1, especially in the area of straight package removals 17:55:45 #agreed Let spins contain the package set they want. (within reason). Our previous proposal should be seen as applicable to the dvd and netinstall rather than spins. (+8,0,0) 17:55:58 ok, on to new business 17:56:00 #topic #1156 F20 System Wide Change: Ruby on Rails 4.0 - https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0 17:56:01 .fesco 1156 17:56:01 https://fedorahosted.org/fesco/ticket/1156 17:56:03 nirik: #1156 (F20 System Wide Change: Ruby on Rails 4.0 - https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0) – FESCo - https://fedorahosted.org/fesco/ticket/1156 17:56:35 So this is going to be an interesting one. 17:56:36 +1 I'm not even sure if it's needed to vote again 17:56:50 mmaslano: "again"? 17:57:02 well, it was a isolated change and we asked it be made system wide 17:57:02 why? I was on CC, Josef wrote on Ruby SIG and many projects, no one complained about rails4, so... 17:57:22 I read few go for it 17:57:26 so... I am +1 to this because "we bring you all the new stuff and break your software" is the traditional fedora way.... 17:57:31 +1 here. 17:57:32 mmaslano: I was under the impression that it was not backwards-compatible and thus would be breaking a bunch of stuff. 17:57:37 +1 on this. 17:57:52 Is there a coherent plan on dealing with breakage? 17:57:58 I'm not quite clear what the plan for openshift is... the page just lists a name and email. 17:58:09 is the plan SCLs? 17:58:14 * nirik sure hopes no 17:58:17 no 17:58:23 mattdm: Wishful thinking 17:58:34 no, serious question. 17:58:47 mitr: obviously we should make that guy do it ;) 17:58:47 depending on that I would be -1 17:58:48 mattdm: That would violate temporal consistency 17:58:50 I don't think SCLs helps for the stuff packaged _in fedora_ 17:58:57 I guess we are sending these proposals, so people can complain, no one was complaining, so they are fine with update... 17:59:04 but does help the pain of people trying to use fedora to do stuff 17:59:30 i'd like to figure out how to do this better in the future (vis-a-vis scls, the rings proposal, etc.) in the meantime, i ca nbe +1 to this for now 17:59:45 Is the switch ready to be flipped if we approved it today? 17:59:53 mattdm: thats how I see it. 18:00:07 I'm wary of approving a probably-disruptive change so late 18:00:23 Here's this SCL hammer we made for you, it's nice and shiny and you can use it to go build your own house of SCLs. Have fun! :) 18:00:25 I don't want to hear that it's not going to land until Alpha freeze too 18:00:26 sgallagh better now than next week 18:00:36 I found reply from Troy, who is working in OpenShift: The change has got to come sometime, and since this is in rawhide it's better to get it done early than late. ... I'd much rather this came now so I/we can get it over with 18:00:42 notting: yeah, I'm feeling pretty similar. +1 for this now. 18:00:43 mattdm: Yes, that's my point. If it's not even ready to land, I'm against it 18:01:18 OK, +1 18:01:18 We're at +6 atm 18:01:35 ok, any other votes? 18:01:48 Since no one answered my concerns, I'm going to vote -1 on principal 18:01:57 lol fair enough 18:02:11 *principle 18:02:11 sgallagh: you mean switch ready? :) 18:02:41 mmaslano: I had two questions: 1) can the packages land immediately? 2) Do we know how much stuff will break? 18:02:42 sgallagh: WRT rails itself, there's only 1 outstanding item on the page, and the Alpha deadline applies to everyone equally, doesn't it? 18:02:46 sgallagh do you want to modify the proposal to "approved if ready to land"? 18:03:14 The contingency plan _is_ rather naive, though 18:03:21 mitr: Yes, but if a platform-breaking change lands at Alpha, that's not enough time for the other packages to clean up 18:03:25 for #2, _very much stuff will break_. 18:03:32 sgallagh: 1/ they are already in because noone complained about it, 2/ hard to say 18:03:53 sgallagh: see "dependencies" in that page 18:03:55 mattdm: there's actually fairly little rails-using stuff *in fedora proper* 18:04:11 external stuff will break, but... 18:04:21 "but who cares! It's fedora?" 18:04:23 Ok, if we're already landed, I suggest we ask for an announcement about that being the case on the list and go for it. +1 18:04:36 mattdm: how would you like to communicate such changes with not only cloud projects ? 18:04:43 mattdm: I mean next time 18:04:53 #agreed Change is approved (+7,0) Please announce that it's landed. 18:05:13 * sgallagh wants to give downstreams time to deal with it before Alpha 18:05:22 mmaslano next time i'd like to tell people that they could use openshift cartridges or scls or something else to provide a consistent stack across releases 18:05:28 mattdm: With SCLs/rings, we would just leave the old stuff in as long as someone pretends to be interested in maintaining it. Less visible pain, not sure about invisible pain. 18:05:37 mattdm: that would be better yes. 18:05:50 #topic Fedora future plans/proposals discussion 18:06:11 So.... 18:06:14 so mattdm wanted to discuss this a bit and see about sending something to the board if we were all ok with the general direction of things. 18:06:22 yeah. 18:06:40 i am working on a polished proposal to send to the board 18:06:43 * sgallagh notes that Slashdot already has a grossly-misleading story about this 18:06:47 but it feels like flock was like 5 minutes ago 18:06:51 yay slashdot! 18:06:54 So we probably want to get out in front of this story quickly. 18:07:03 My impression from Flock is that we have a general agreement 18:07:14 I personally like the "inner" part of the rings idea in general... the outer parts need more discussion and planning, but would be ok asking the board if they are generally liking this direction or not. 18:07:16 +1 general agreement! 18:07:25 My impression from post-Flock is that there's a _lot_ of implied details that we tend to differ on, that are only discovered when written down. 18:07:30 1. In order to build what we need for the future of Fedora, FESCO endorses 18:07:32 the idea of moving from a one-policy-fits-all-software policy to a tiered 18:07:33 mitr: +1 18:07:33 model as roughly laid out in http://mattdm.org/fedora/next, and 18:07:35 recommends this to the board as the technical underpinning of our 18:07:38 strategic direction. 18:07:53 So, "yes, let's do this", but I'm not in favor of formally voting on something so close to a blank check 18:07:53 (that's a paste from an email i sent to fedora-devel like an hour ago) 18:07:57 mitr: That's a fair assessment 18:08:05 inner part +1; outer part I have several ideas of what that would look like that I like a lot and several ideas of it that I hate horribly ;-) 18:08:08 mitr: yeah, that's definitely true 18:08:19 abadger1999: me too. 18:08:21 mitr: Well, we're basically asking the Board "do we have a go-ahead to try to work this out?" 18:08:36 sgallagh: right, and I think we need to phrase it that way 18:08:39 Because if they Board smacks it down (I doubt it), I don't want to spend weeks coming up with a solution 18:08:44 right. 18:08:51 sgallagh: OK, that makes sense 18:09:16 Further, as mentioned above, I think we want to get ahead of the story before it bites us. 18:10:15 mattdm, sgallagh: ISTM that the 3 products are an essential component of what we need the Board to ack (because it changes the visible identity of Fedora, not just internal rules) 18:10:17 so, should we vote on the '1' above from mattdm and ask him (or someone) to bring it to the board for general "ok, try and come up with a concrete detailed proposal" 18:10:34 mitr: My point exactly. 18:10:37 what we need is some sort of plan, break things into steps (as I understood mattdm there's no plan to do everything in once) a start working on these steps + say the idea is to come to this in the end... so pepple can prepare, we will know how many resources will be needed and when 18:10:53 How about something like: FESCo would like to move forward with exploring concrete ways of implementing the tiered model roughly laid out in http://mattdm.org/fedora/next and would like the Board to let us know if they object to that general direction 18:10:59 also to note where we need more resources for sure. 18:11:05 reading the slashdot highly-voted comments, I get: "just use arch; just use centos; how to spell my name; don't make a one-size-fits-all os; and, of course, fedora lts!" 18:11:14 abadger1999: +1 18:11:22 abadger1999 +1 18:11:24 abadger1999: +1 18:11:30 abadger1999: +1 18:11:32 abadger1999: +1 18:11:34 abadger1999: yeah 18:11:37 +1 18:11:49 yay! 18:11:58 abadger1999: +1 to that part, but I'd really like the 3 products to be explicitly mentioned. 18:12:10 #agreed FESCo would like to move forward with exploring concrete ways of implementing the tiered model roughly laid out in http://mattdm.org/fedora/next and would like the Board to let us know if they object to that general direction (+7,0) 18:12:12 mitr: mattdm lead with "1.". I assume there's more :) 18:12:21 yeah, next item? 18:12:22 yeeesss. 18:12:28 2. FESCO-created working group to draft Fedora Base Design as called for 18:12:29 in that proposal. 18:13:03 Does that need more explanation? 18:13:12 I've talked about this so much I forget what is obvious and what isn't :) 18:13:26 I'm ok with that, as long as it's clear that what they write up will almost surely require tweaks and changes when it gets full input from everyone involved. 18:13:30 mattdm: I assume you mean "create a group of people to formalize it"? 18:13:42 nirik Hence draft 18:13:43 create a group of people? like, cloning? 18:13:49 yes! cloning 18:14:04 nirik: I agree, but we should also like to choose folks who are prone to sticking to their guns. 18:14:07 "Decide that a group will be created." Not sure we need that group created Right Now. 18:14:23 also, it might be good once we populate this group to have them setup a FAD somewhere. I think this might be concrete enough for a FAD deliverable. 18:14:28 Because once it goes to devel@, there's going to be a lot of dissent. We know we cannot please everyone 18:14:29 Yep. Drafting is good. 18:14:33 sgallagh Not people who waffle on whether to remove sendmail or rsyslog 18:14:36 nirik: FAD would be nice 18:14:43 +1 FAD 18:14:54 Yes, definitely a FAD 18:15:02 anyhow, when would we populate this group then? 18:15:12 * jreznik would like to at least help this group, even you say no to have me there :) 18:15:15 sgallagh: eh.... there's also the fact that what consitutes the Base Design can change from release to release.... we don't have to get it perfect for the first Fedora release. 18:15:19 nirik: Put it on the schedule for the meeting following Board approval? 18:15:24 nirik: fwiw I'm +1 on the agreed abadger1999 proposal above. 18:15:28 We just need to set expectations of what it means and should look like. 18:15:28 abadger1999: Fair enough 18:15:30 (sorry, got pulled away temporarily) 18:15:30 wfm 18:15:39 pjones: ok, sorry. 18:16:07 I'm up for asking for volunteers and picking some people. Is that too undemocratic? 18:16:30 Perhaps treat it like the Board? Pick three appointees and four volunteers? 18:16:32 no, I guess we have experts in some area ;-) 18:16:47 mattdm: +1 to appointments from a pool of volunteers. 18:17:00 mattdm: +1 from me... 18:17:01 Yeah, abadger1999's plan makes more sense 18:17:13 (or translation of your plan) 18:17:18 who's going to appoint from these volunteers? :D 18:17:27 fesco. 18:17:29 jreznik: FESCo 18:17:33 * nirik nods. 18:17:42 "FESCO-created group" 18:17:46 Wait, are we now discussing a proposal for the board or all the things that are contingent on that proposal? 18:17:55 contingent really 18:18:10 mitr: Yeah, we should probably get back to the proposal. 18:18:17 mitr: contingent... if they say "no, the way we do things now is fine" we don't do this. ;) 18:18:19 I was going to suggest jumping to the product message 18:18:29 ... actulally - is 2. a proposal for the board or an unrelated item? 18:18:37 unrelated item 18:18:40 * mitr apologizes for being confused 18:18:41 so, perhaps we defer 2 until the board comes back... 18:18:42 never mind then 18:18:47 and we can just do it / set it up then. 18:18:48 nirik: yeah 18:19:03 +1 to abadger1999's plan 18:19:06 * mattdm is eager to get started 18:19:11 or let Board appoint a few members, same for FESCo or other groups? 18:19:23 jreznik: no, fesco appointed like fpc 18:19:33 board shouldn't need to be involved in implementation details like that 18:19:34 +1 pjones 18:19:41 * nirik nods. 18:19:48 pjones: well, this group should set future Fedora vision 18:19:51 so, the next few points are in the same boat IMHO. 18:19:59 and previously it was Board to set it and fail 18:20:01 So I also want to propose a working group for figuring out ring 2. but that's even more contingent. 18:20:17 mattdm: right, I say we skip those and go to discssion at the end. 18:20:31 Well, can we put the SCL part in? 18:20:58 mattdm: sure, that could be anytime, but not sure what FESCo has to do there. 18:21:16 unless we want to override FPC 18:21:31 Would prefer at this point to work with FPC 18:21:39 The SCL thing -- to get it into the current Fedora repo should just require going back to FPC and asking them to consider guidelines for doing it inside of Fedora. 18:21:41 * nirik would be -1 to any override 18:21:55 (in this area/case) 18:22:00 abadger1999: yeah, and that's a reasonable way of working with them I think 18:22:08 I think I've changed my (FPC) mind about those and there's been turnover in other members. 18:22:30 So FPC will have a lively debate about it if nothing else :-) 18:22:31 abadger1999: really? I can show you my proposal later than 18:22:33 Okay. So if that's not a FESCO thing at this point, I'll just continue what I was doing, which was trying to talk to everyone nicely. 18:22:36 additionally there's RHEL using them to look at for maintainability, etc. 18:22:37 mmaslano: excellent 18:23:04 okay then. moving on to the fedora os product strategy discussion? 18:23:09 please 18:24:28 I can post the notes from the whiteboard @ flock... 18:24:40 they may not make much sense without explaining but it gives a starting point? 18:24:46 That's probably a good start. Pastebin? 18:25:02 * notting notes he has to leave in 5 minutes 18:25:10 so, to clarify... this is something we want to add to our note to the board and see if they agree with this general direction? 18:25:24 oops, n/m. meeting got moved 18:25:26 (well, once we see if we all mostly agree) 18:25:39 nirik: this is either part of that note or a separate note. 18:25:41 I. Summary Statement 18:25:43 - my presentation well-received 18:25:46 - technical details fesco 18:25:48 - practical implementation asks for some changes on direction of fedora which we feel require board approval 18:25:50 II. Target Products 18:25:52 A. Workstation 18:25:54 Target audience: Creatives, Developers, Sysadmins, and other IT professionals 18:25:56 Purpose: Keep Linux users on Fedora (This is a niche market; we recognize that. But let's make it our niche.) 18:25:58 B. Server 18:25:59 Target: People for whom RHEL and CentOS don't move fast enough, and people who want to see and influence the future of RHEL 18:26:02 Purpose: Build a better RHEL, and engage customers in development of RHEL, OpenStack, and other emerging technologies. 18:26:03 C. Cloud 18:26:06 Target: Development; DevOps in production; OpenShift 18:26:08 Purpose: We do not become entirely irrelevant. 18:26:10 III. Support Structures 18:26:11 A. Product working groups 18:26:14 B. Base design 18:26:15 C. Policy rings 18:26:18 (psh, fpaste. pasting into irc works just fine) 18:26:32 * sgallagh kicks mattdm 18:26:33 The product strategy here is *clearly* board material. 18:26:41 so, could B and C be the same thing? or B is "larger" 18:26:51 B is certainly larger 18:27:02 nirik: marketed differently. also, installer-focused vs. image focused. 18:27:07 well, I could want to run any number of "server" things on my cloud instances. 18:27:08 B is where our recommended infrastructure servers would likely live. 18:27:44 but _mostly_ they share a lot 18:27:54 mattdm: ok, but note that arm might be more image centric and server... 18:27:56 nirik: Sure, but those would be selected add-ons to the cloud image, where I (at least) kind of envision having something as a more comprehensive base at least 18:28:06 nirik good point 18:28:33 The cloud target is: guests that run in the cloud? whereas the servers to host the cloud would be included in (B)? 18:28:39 That raises the question of if every arch has to provide every product 18:28:40 abadger1999 yes 18:28:41 mattdm: I'll go ahead and say that I'm not thrilled about the "creatives" item. I can see how it got there 18:28:43 abadger1999: precisely 18:28:46 18:29:02 alternate desktops would be their own products, right? 18:29:08 nirik yes. 18:29:10 mitr: by "creatives" we basically mean coders (but leaving the door open) 18:29:36 mattdm: nice work on the presentation, and the idea in general. I think it brings great clarity to the organization of Fedora 18:29:39 sgallagh: .... oh? i think that's different than what was represented in the room 18:29:41 And the proposal here is that Fedora as a project will focus on providing these products, but also on the toolkit to build them, and encourage that toolkit to build other things 18:29:42 sgallagh: ok then 18:29:49 xfce spin 18:29:50 nirik: This proposal also does not mandate (at this time) a specific desktop. Just a target audience that we will attempt to serve. 18:29:53 sgallagh: pretty sure that's the "developers" types, and "creatives" is the utterly broken term for graphical design people. 18:30:06 notting: Was it? Maybe I missed it 18:30:09 right, and part of the working group design would be requirements for what things go into these products. ie, what requirements for desktop, etc. 18:30:29 nirik: Yes 18:30:40 sgallagh: well, don't want to put emily in a box, but she certainly straddles the line between designer/coder/etc. 18:30:43 or web server, or cloud server, or whatever. 18:30:43 We also had something on the working groups on the board, but Matthew didn't paste it 18:31:03 notting: Fair enough. I'm fine with handling the Inkscape/Gimp crowd there 18:31:33 nirik: and that's why I say Board should take part of this working group - at least the first part to say what products are, for the next step and technical decisions, it's not as much needed... 18:31:34 nirik: We suggested that the working groups should be created per-target audience and chaired by a sitting member of FESCo 18:31:37 sgallagh matthew apparently didn't transcribe that part from his phone image on the plane 18:31:39 these would just be products made by/tested by/fedora and someone could surely add on whatever stuff they want right? 18:31:55 mattdm: That's fine. I just wanted to cover it 18:32:15 nirik Yes indeed. 18:32:21 nirik where you goin' with this? :) 18:32:26 Absolutely 18:32:29 jreznik: well, what goes into a product seems like a more technical decision to me... where 'should we even think of products' or 'what products do we ship/test/by default' would be more board... 18:32:43 nirik: Yes, that's my view as well 18:33:04 nirik: well, given the ring2/env/stacks/etc. - there's a bit of a dicsussion to be had about where bits come from to make other things outside of these three, and therefore what they might be called. that may be a discussion for further down the line 18:33:11 mattdm: not sure. ;) Someone could take the workstation product and decide they wanted to change up desktops or whatever and do so much like they would now 18:33:21 notting: sure. 18:33:27 abadger1999 suggested that in the future the board could have a representative for each project (changing how board is structured slightly) 18:33:42 nirik: Certainly. There's nothing stopping them from doing that, but it won't be our problem to test it :) 18:33:47 sgallagh: right. 18:34:11 (we would still, i hope, make best effort to not break our favorite alternative desktops) 18:34:14 One of the key points that we need to make clear: we want to reduce the number of things that need testing 18:34:22 all the stuff that builds and is in the 3 products would be 'ring 2' ? 18:34:32 mattdm: only our favorite ones? 18:34:41 nirik: Can you rephrase that question, please? 18:35:29 sgallagh: does the set of items used to make products imply they are in a lower ring that things that don't make up the 3 above products? I guess this is just what notting was saying and we may have to look at it down the road. 18:35:33 sgallagh: (reduce the number of things that "need" testing while actually increasing the number of things that have to be and are tested) 18:35:44 notting I was joking with that phrasing, but, realistically, yeah, we'll care more about the ones where people in the community are putting in sigificant effort. so for that wording of favorite. 18:36:03 anyhow, I'm +1 to sending this direction to the board as well. If they don' 18:36:12 nirik: I agree +1 18:36:13 nirik: No, my stance is that the basic deliverables should *not* need to be self-hosting (provided that they are *reproducible* by the public Fedora build system) 18:36:18 t like it, we can not waste time making it detailed proposal. 18:36:43 One part I want to make particularly clear here is that the vision for Fedora's products here may differ from the vision of any upstream projects we use to compose them. 18:36:56 nirik: +1 18:37:40 sgallagh: well, but we want to test the build chain too, or we can't make the deliverables... so to me that implies they are in a similar testing/policy or lower than the products. 18:37:45 mattdm: And when that arises, the various working groups have authority to change from upstream to meet the needs of the target audience? +1 18:38:05 To take the big example: the Gnome project has a certain vision for their desktop environment, and while I respect that vision and wish them the best in targetting it, it is not necessarily the same vision as that needed to meet _our_ goals for Fedora Workstation 18:38:06 mattdm: that works for me. 18:38:11 so, thats +4 for sending this to the board for a broad ack 18:38:19 uh, +1? 18:38:22 mattdm: +1 18:38:29 * sgallagh is +1, obviously 18:38:34 sorry, did I miss your vote. ;) 18:38:43 nirik: i'm +1 to the general idea of the main proposals. still catching up, as behind on list mail 18:38:50 * pjones is +1 on that 18:39:20 So, not clear I guess what we are voting on, let me make a proposal here: 18:39:20 mattdm: i think for something like that it would be good to have a much more defined goal/userbase than just the couple of lines above, so active designs can be made rather than anecdotal "i don't like this thing over here" 18:39:24 One thing I'm not hugely clear on here - would the expectation be that Workstation would be equivalent to the current Desktop in terms of visibility? 18:39:37 notting absolutely 18:39:43 mjg59 define visibility? 18:39:45 mjg59: which desktop? 18:39:50 mattdm: The thing on the front page of the website 18:39:51 mmaslano: Desktop 18:39:56 proposal: send to the board the idea of fedora producing 'products' and allow fesco to work on a detailed proposal around those and what might be in them, etc. 18:40:04 &quit 18:40:12 nirik: +1 to that 18:40:19 nirik: +1 18:40:20 * nirik is +1 to his own proposal. 18:40:25 mjg59 I think we will put all three things on the front page. 18:40:25 mjg59: I think for this to work it needs to be the most prominent thing on the page, but all of these things need to be on there 18:40:28 mjg59: yes, as I understand it. 18:40:31 nirik: +1 18:40:41 I'm okay with having desktop on the top 18:40:51 nirik: +1 18:40:51 * abadger1999 envisions that we'd see a page attempted to push people towards one of the three products depending on what they wanted to do with it. 18:40:51 Proposed Addendum: mattdm will send his proposal draft to the FESCo list for tweaks before it goes to the board 18:40:52 all three should be very visible. 18:41:06 Ok, so the natural thing is that the people defining Workstation would be the existing Desktop SIG? 18:41:17 right. right now, it's desktop is visibile, others are in the basement. 18:41:28 (And Server the Server Sig, and Cloud the Cloud Sig) 18:41:30 why the desktop sig? 18:41:31 mjg59: To the extent that the visions differ it's not quite obvious 18:41:37 mjg59: Not exactly. They should be implementing a technical vision identified by FESCo and the Board. 18:41:37 mjg59: I don't think so, since "sigs" don't really exist... 18:41:41 Viking-Ice: benefactors in kind 18:41:46 I would prefer a concrete listing of who is in them. 18:41:50 Well ok, that's why I'm asking 18:41:50 but the broad answer is "not really" 18:42:01 nirik: +1 to your proposal 18:42:24 nirik: +1 18:42:25 abadger1999: That's an implementation detail, but I'd like to see that too 18:42:30 There's a set of people who currently produce what you get by default from the website 18:42:41 nirik Cloud SIG -- we're a real thing. 18:42:47 If the proposal changes who that set of people is, I think it needs to justify that pretty strongly 18:42:49 sgallagh: that's sort of a mixed bag. we're setting a vision for layout and consumption, but they're still the ones defining e.g. desktop experience in a real way 18:42:56 mjg59: Yes, but right now it's "Whatever upstream produced" 18:43:03 #agreed send to the board the idea of fedora producing 'products' and allow fesco to work on a detailed proposal around those and what might be in them, etc. (+7,0) 18:43:11 We're proposing that Fedora should have some leeway to adjust that where it's better for Fedora 18:43:16 sgallagh: No, it's just that there's significant overlap between upstream and them 18:43:19 mattdm: perhaps I phrased that poorly... but it's not a concrete membership, voting, etc. 18:43:38 so idea is to give power to sigs but cut that power by saying what sigs has to do :) 18:43:45 there are places where gnome the project and fedora desktop are different... browser choice for example 18:43:46 nirik I'm okay with asking for these sigs to become more formal -- progress to Team in the existing model 18:44:12 mjg59: Ok, I think we're talking in circles here. My point is that if we and the Board define a target audience, and the existing Desktop SIG is *not* targeting that audience, we have leeway to course-correct 18:44:21 Using the mechanism we see fit. 18:44:57 it's all about enshrining cross-department hostilities 18:44:59 jreznik: heh. I don't think the idea has SIGs involved... or perhaps better stated... not the current definition of SIGs. 18:45:07 I think the groups that control the products should be formal enough to where someone can ask them something and get a concrete answer that is from that group, instead of someone in a sig said. 18:45:25 (i.e. that mechanism might be as simple as carrying an extension or as grandiose as picking a different DE, but it needs to be in our power) 18:45:47 Ok. As a board member (but not speaking for the board), I think any real proposal is going to have to include examples of cases where things would be different, and how that's going to be managed within the context of existing Fedora contributors 18:46:08 mjg59 noted 18:46:17 yeah, detailed proposal shoudl def enshrine that process and differences from current 18:46:18 But personally, I'm broadly enthusiastic 18:47:00 ok, any further discussion or voting needed on this topic for now? 18:47:25 I think we're good at least until the draft is produced. 18:47:47 * mattdm had thought he could relax after flock. aahahhhhahahhhhhh. 18:47:50 sgallagh: but you know, we rely on our upstreams... we are not canonical to fork old desktop and create exactly what they want... and I envy them sometimes for being able to do it 18:47:51 well, until we need to populate the groups that will make the draft... 18:48:23 nirik I'm going to draft a basic proposal 18:48:28 jreznik: I'd like to believe that there are sensible-enough individuals out there that they'll work *with* us. 18:48:30 jreznik: that's not exactly set in stone, just a tradition 18:48:48 we had another ticket come in this morning... https://fedorahosted.org/fesco/ticket/1157 do we want to do it this meeting? or defer to next? I'm not sure how many of you had time to look at it. 18:48:57 * sgallagh hasn't read it 18:49:04 mattdm: great. ;) It's always good to have something to pick holes in. ;) 18:49:11 jreznik: sgallagh: this is why above I said: "that's sort of a mixed bag. we're setting a vision for layout and consumption, but they're still the ones defining e.g. desktop experience in a real way" 18:49:34 jreznik, there is Gnome SIG forming which will allow it to be closer to upstream and desktop SIG or workstation SIG or whatever tailor it to Fedora 18:49:34 we're really not going to be in a position to tell the desktop people "hey, switch the stuff you're working on to CDE", because they're not working on CDE. 18:50:10 nirik I could either defer on that or proxy my vote to you because I think this is kinda an infrastructure thing 18:50:26 pjones: Right, but at the same time we have some limited ability to say "This is what we need from you. If you don't want to provide it, we'll look at alternatives" 18:50:29 lets just defer. I don't think folks have had time to read it. 18:50:49 sgallagh: Can you define "we" in that situation? 18:50:54 FESCo 18:50:59 and board 18:51:04 and board, yes 18:51:07 Viking-Ice: good point, but someone has to step in (and same for server... we have better cloud because mattdm stepped into) 18:51:09 It's pretty limited. 18:51:24 Our truth-or-consequences knob isn't particularly easy to turn. 18:51:44 jreznik: mmaslano has been trying to get her server SIG off the ground, and I'm willing to help there. 18:51:56 pjones: Desktops are the one are where we actually have several 80%-viable options 18:52:01 nirik: ticket 1157: I agree with mattdm that this seems mostly like an infra question. 18:52:30 #topic next week's chair 18:52:34 who wants it? ;) 18:52:35 sgallagh: I wouldn't say me, but there are few members 18:52:50 of server sig who can run it 18:52:53 i may be unavailable next week 18:52:59 sgallagh, is that some thing other then the current Server SIG/sub-community ( I've not seen any proposals or nothing from her on that mailing list although I might have missed it ) 18:53:03 I won't attend next week 18:53:04 nirik: I'll take the chair next week. 18:53:13 * abadger1999 adds it to his calendar 18:53:14 Viking-Ice: It's still coming up to steam. 18:53:20 thanks abadger1999 18:53:22 Are we all done with features for now? 18:53:29 #action abadger1999 to chair next week 18:53:32 proposal: naptime! 18:53:34 jreznik: ^ 18:53:40 mattdm: +12 18:53:44 or +1, even 18:53:59 abadger1999: there's Bluez 5 18:54:00 if there's a few minutes of the meeting time left, I'd like to briefly touch the BlueZ 5 topic 18:54:01 -1. Counter-proposal: cocktails 18:54:12 jreznik: k. 18:54:20 It affects a number of spins so I wanted to be sure FESCo is on board with this 18:54:22 jreznik: is it ready? or next week? 18:54:28 #topic Bluez5 18:54:33 kalev: take it away 18:54:36 kalev: That sounds like something that should go through the Changes process, then... 18:54:46 kalev: will this unbreak the thing where bluetooth is always on after my thinkpad boots or resumes from sleep? 18:55:09 mattdm: uh, I have no idea 18:55:24 hadess is really the resident bluetooth expert, I'm just filling in the shoes while he's on vacation 18:55:47 anyway, this is going through the Changes process and jreznik announced it today 18:55:48 mattdm, just blacklist the bluetooth driver. 18:56:13 sgallagh: I believe it is a Change -- just filed late: http://fedoraproject.org/wiki/Changes/Bluez5 18:56:20 however, we don't have so much time left and I think it would make sense to move forward with updating the packages 18:56:20 Sorry, I see that now. 18:56:34 my plan is to land bluez 5 today / tomorrow to leave more time to fix up issues / integrate 18:56:50 and I'd like to emphazise that there's a contingency plan to revert back to bluez 4 if it turns out we can't make it propely work for Beta for all the release blocking desktop 18:57:10 kalev: Has the code to update bluez users actually been written? 18:57:35 mitr: what do you mean, update bluez users? 18:57:36 kalev Is the plan to switch back for beta if the alpha doesn't work? 18:57:54 because switching back after beta has been proven to be practically too late 18:58:05 kalev: port applications from v4 to v5 18:58:53 mitr: yep, most apps have been ported -- gnome-bluetooth, PulseAudio, NetworkManager (still pending some patch review, but the code is available), BlueDevil 18:59:11 so gnome is fairly ready, kde has a branch that can be used, mate has an experimental thing, and lxde and xfce are....? 18:59:21 doomed. ;) 18:59:35 we could use the same think mate does if that exists. 18:59:41 nirik: So, par for the cource? 18:59:41 I believe mate and lxde and xfce are somewhat in the same boat 18:59:45 *course 18:59:59 right. all the systray using desktops 19:00:05 nirik: were you using blueman before? 19:00:13 yeah 19:00:14 the important thing to have, I believe, is to have a working panel applet, which can be used by all of these three 19:00:40 regarding blueman, its owner seemed to want to retire it anyway 19:00:55 kalev When is the planned go/no-go and contingency activation plan, and how much un-porting will that require? 19:01:23 if there's not a pannel applet I would be ok with just saying those desktops get no bluetooth support... rather than trying to hold everything else back 19:01:24 mattdm: I believe the contingency plan requires maybe 3 days. I was planning on activating it right before the Beta freeze, is that too late? 19:02:06 nirik: it shouldn't be hard to get a working panel applet by resurrecting the old panel that got removed from gnome-bluetooth 19:02:16 If we had to revert, doing it right before the beta freeze would be appropriate I think 19:02:39 If you think your 3-day estimate is good, then, yeah, sounds fine. 19:02:42 so maybe we could schedule it to discuss a week before the beta freeze, at a fesco meeting? 19:02:47 * mattdm is therefore +1 to the wholething. 19:02:49 kalev: possibly. Also that will pull in any deps gnome-bluetooh has 19:02:59 "So f21 is Ok as goal, but f20 is definitely to early for KDE!" 19:03:06 Conversations seem to be still ongoing... 19:03:15 mitr: I _just now_ talked to Kevin Kofler on #fedora-kde 19:03:44 and he said it should be okay to try to package up the git snapshot; jreznik is also on the channel and saw the conversation, I believe 19:04:05 I suppose I'm +1 if 1) we review this before beta, and 2) gnome and kde are required to be by that time 19:04:22 1 is a process matter, not really a requirement 19:04:38 mitr: +1 19:04:42 sure, +1 19:04:45 +1 19:04:49 nirik: if the other desktop teams agree I could be +1 as well... otherwise, I'd say that fixing them should be a requirement.... If the feature came in before the deaadline I think I'd be the opposite. 19:05:00 mitr: sure. +1 19:05:27 abadger1999: ok, so you are -1 to the above proposal? 19:05:31 abadger1999: Right, we _should_ get everything; I'm not willing to compromise on these two 19:05:36 anyhow... I'd be some sort of contingent +1.... 19:05:44 So that bluez can land now. 19:05:51 abadger1999: We do retain the right to activate the contingency before Beta in any case and for any reason :) 19:05:57 mitr: 19:06:05 mitr: yeah, that might be the wayto go. 19:06:50 so, counter proposal? 19:07:17 nirik: I think we are at +5 (with me voting for my proposal) 19:07:17 mitr: I'm definitely for Beta to fire up contingency plan 19:07:27 jreznik: will you make sure this gets on the agenda, please? 19:07:29 sounds like a good plan to me 19:07:34 So -- approve bluez5 landing now -- if the other alternate desktop envs agree to not be blocking, they do not need to be fixed in order for the feature to stay in. If they don't we'll need to see that they can get bluez5 support in time for F20 or evaluate whether to trigger the contingency plan. 19:07:51 sure, +1 for abadger1999's proposal 19:08:14 * notting can be +1 to that 19:08:22 +1 19:08:29 It's only barely any different, so it's pretty easy to be +1 with. 19:08:37 +1 19:08:44 abadger1999: +1 19:08:46 so sure, +1 19:08:49 pjones: yeah -- that's pretty much what we all agreed on with just some things more explicit. 19:09:11 #agreed approve bluez5 landing now -- if the other alternate desktop envs agree to not be blocking, they do not need to be fixed in order for the feature to stay in. If they don't we'll need to see that they can get bluez5 support in time for F20 or evaluate whether to trigger the contingency plan. (+7,0) 19:09:18 thanks kalev! 19:09:23 I got one request for proven packager assistance in completing tracker bug 947037 which adds an missing requirements on crontabs to corresponding packages ( as stated by the guidelines ) and all these bugs there have patches submitted to them that does exactly that... 19:09:27 #topic Open floor 19:09:33 thanks! 19:10:07 Viking-Ice: sure. We can note that here... or perhaps you could also send to devel-announce about it? 19:10:58 #info proven packager assistance wanted for crontab cleanup, tracker bug: 947037 see Viking-Ice for more info 19:11:02 nirik, the request for proven packagers? ( would have done this myself but you know my hands are tied in that regard ) 19:11:16 thanks 19:11:31 Viking-Ice: you can send the request... subscribe to devel-announce and send email to it and it can moderated through... 19:11:43 any other items for open floor? 19:12:33 If nothing else will close out in a minute. 19:13:33 Thanks for coming everyone! 19:13:36 #endmeeting