18:00:45 #startmeeting FESCO (2013-10-02) 18:00:45 Meeting started Wed Oct 2 18:00:45 2013 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:48 #meetingname fesco 18:00:48 The meeting name has been set to 'fesco' 18:00:50 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:50 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:52 #topic init process 18:00:54 Hello all 18:00:56 t8m can't join today 18:01:00 hello. 18:01:06 morning 18:01:07 * pjones has a hard-stop again at 2:45 18:01:14 (I expect this to continue for the indefinite future. 18:01:15 ) 18:01:24 * notting is here 18:01:33 pjones: should we be looking for a new time? 18:01:34 * sgallagh settles in for an interesting meeting 18:01:44 pjones: the meetings will continue until morale improves? ;) 18:01:53 * abadger1999 has something to throw onto open floor as well. 18:02:16 Should we perhaps do Open Floor first, since the agenda topics look like they'll take a while? 18:02:20 * jreznik is lurking 18:02:20 abadger1999: you throw it on the floor, you have to clean it up 18:02:23 * mattdm is here 18:02:38 abadger1999: I mean, I'm trying to make sure that I'm caught up on tickets well before the meeting, and if this time is working for everybody else I think we can get by with just the occasional ordering constraints on tickets? 18:02:39 notting: As long as I have permission to use the fesco mop ;-) 18:02:52 abadger1999: That's my *head*! 18:03:06 pjones: sure. just say the word if it becomes an issue. 18:03:15 hi 18:03:24 OK, that's everybody 18:04:00 Is there anything for open floor that we would want to take care of first? 18:04:31 abadger1999? 18:04:57 * abadger1999 gets linlk 18:05:06 https://bugzilla.redhat.com/show_bug.cgi?id=1014209 18:05:21 There were a bunch of mass filed bugs against python packages just prior to this meeting. 18:05:24 * nirik added a comment. 18:06:03 That seems to be likely to be as much as a time sink as everything else, so - any objections to just following the schedule? 18:06:03 The text of the bugs says that maintainers of the packages are required to update their packages to support python3 (whether or not upstream is participating in that). 18:06:51 Proposed solution: have the reporter comment that the bugs are on hold and have him file a Fedora 22 Change to implement this. 18:07:08 ouch 18:07:19 mitr: yeah -- if people would rather discuss than just go with my proposal, I'd be fine with following hte schedule. 18:07:31 well, if we're attempting to move the minimal install + anaconda to python3, yeah, each of those needs *some* remediation. although it could just be "move to some other py3 lib" 18:07:32 abadger1999: hm, ok. 18:07:44 #topic Python 3 support 18:07:45 notting: yep. I'd be okay with that. 18:08:11 (with making clear that an option is to move to a different python3 lib or application. 18:08:35 abadger1999: 1) My reading of this is "if you don't want to, just say so", which is as soft as it can be 18:08:42 2) AFAICT we _will_ need to move to Python 3 18:08:50 mitr: there's nothing in the bugs that say that. 18:08:54 or rewriting the program entirely in go 18:09:02 "I offer my help with this task, so if you have no idea, how to work on this, or it is just not your priority, don't hesitate to ask for help." 18:09:03 18:09:08 In fact: "When upstream is dead or unwilling to support Python 3, you'll need to patch this package on Fedora level." 18:09:33 mattdm: if you do it right, get each package to move to a different language... go, lua, haskell, ocaml, erlang, scala... 18:09:49 which is expressing "you must add python3 support" 18:10:00 ... by Python 22 18:10:25 mitr: I assume you mean Fedora 22, and we don't actually know when that's going to be 18:10:31 Python 22 will be written in Go. 18:10:34 Minimum of 12 months, I would guess 18:10:35 sgallagh: yes 18:10:42 I don't recall us approving a change to do this. 18:10:51 nirik: We haven't. 18:11:06 right 18:11:08 * mmaslano agree that having Change approved before mass filing bugs would be a good thing 18:11:11 nirik: I'd be in favor of it, but that's irrelevant without a proposal 18:11:12 Right now it is, and reads like, somebody's personal wish 18:11:26 So, I'm -1 the proposal for another mass-comment that "this is on hold"; I can't see an urgent reason to do this. 18:11:49 mitr: Well, I think I remember reading that Python upstream was abandoning 2.x as of December 2014, so this is becoming important 18:11:53 +1 to asking them to file a Change; we can get that figured out and send a comment to all of them later 18:11:55 proposal: close all bugs, ask filer to make a change and work with FPC and others and discuss on devel list before filing anymore. 18:12:10 Well -- it also violates the packaging guidelines... So a comment would need to be made. 18:12:18 i remember there _was_ some discussion on devel list 18:12:27 nirik: -1, i think we can pull them into a Change later. i'd be +1 to removing the "close all bugs" of your statement 18:12:40 sgallagh: I agree it needs to happen $fairly soon, which is why I don't like confused opening/closing/we don't know/opening another bug... 18:13:04 mitr: Agreed. 18:13:16 maybe a message could be added saying that this is in support of a planned future change and that the more that's done sooner the less work it will be later? 18:13:17 * nirik really wishes people wouldn't mass file bugs without doing the right steps. 18:13:28 mattdm: I would prefer it 18:13:33 nirik: agree 18:13:36 nirik: +1 18:13:55 Proposal: Ask them to file a Change now, to be discussed at next week's meeting; delay mass updates to the bugs until a plan and a decision exists. 18:14:02 mitr: +1 18:14:05 mitr: +1 18:14:11 mitr: +1 18:14:16 * mattdm is looking for the fedora devel thread 18:14:18 mitr: Well -- I'll have to mass comment those bugs if there's no comment on them. 18:14:18 it's not as if we weren't expecting a Change for this in the near future 18:14:24 without noting to people about the thing thats against guidelines? 18:14:27 (by the reporter) 18:14:28 mitr: +1 18:14:37 abadger1999: why? 18:14:38 https://lists.fedoraproject.org/pipermail/devel/2013-July/186098.html 18:14:46 to say that patching the package at the Fedora level is contrary to guidelines. 18:15:22 abadger1999: Then the guidelines need to change IMHO, \but that's for another week 18:15:33 mitr: no -- supporting python3 is still possible. 18:15:40 Ah, I was wrong. It's going to see a final update in May 2015, but I'd suggest we want to move before then. 18:15:41 * nirik doesn't want people to start doing that and waste time/effort 18:15:41 mitr: But you create a second package in that case. 18:16:12 abadger1999: A second package or a subpackage? 18:16:13 sgallagh: also note -- that's for binary builds (and possibly source tarballs) the scm will still see updates beyond that. 18:16:16 sgallagh: second package 18:16:22 sgallagh: the subpackage is what's disallowed 18:16:30 sgallagh: because you've really forked at that point 18:16:31 abadger1999: would you prefer to speak about Change which says "python3 as default" or Change which make some first steps for such change? 18:16:35 * sgallagh nods 18:16:37 abadger1999: My proposal is to delay mass bug updates _until we actually have a plan_. Telling them that they shouldn't do $A and later deciding that $A is the right thing is just a waste of mental energy 18:16:37 sgallagh: so there should be a seond package for the fork. 18:17:04 mitr: but so is 'do A' and they start doing it and find out later that 'you can't do A' is the answer. 18:17:10 mitr: well -- letting them do A) and then tellingthem to revert A is also a waste of effort. 18:17:44 Proposal: mass-close all bugs that Miro opened and ask that they be reopened *following the mass filing policy* after a Change is approved. 18:17:45 Isn't most of the effort in the coding, not in the packaging ? 18:17:47 anyhow -- we've hit ten minutes. So I think we should push the rest of this discussion until after the other agenda items. 18:17:57 Sorry, not reopened but refiled 18:18:42 i think mitr's proposal did pass. 18:18:46 * nirik is fine with that, since it's what I proposed above. ;) 18:18:53 sgallagh: I'd be willing to +1 as that's more strict than what I proposed. 18:19:02 notting, sgallagh: It did, with sgallagh's +1, but he seems to have changed his mind 18:19:05 notting: yeah, it does. 18:19:26 mitr: Yeah, I'm thinking that the clearest thing we can do right now is assert that *nothing* is the approved behavior yet 18:19:53 So I'm withdrawing my +1 from mitr's proposal. 18:20:05 So, let's split this and get it away with: 18:20:19 Proposal A: Ask them to file a Change by next week 18:20:27 Proposal B: mass-close the filed bugs 18:20:37 * mitr is A+1, B-1 18:20:44 A+1, B+1 18:20:49 A+1, B+1 18:20:52 A+1, B+1 18:20:53 * mmaslano is A +1, B -1 18:21:11 A+1, B-1 18:21:22 A+0, B-1 18:21:51 I'm not seeing how either of those addresses the problem that people have been told to do the wrong thing 18:21:52 I'd really be happy with just "Filed bugs are comented." ... I'll have to do that with my FPC hat if we (fesco) don't ask the reporter to do the commenting. 18:21:53 (But I think some clarification should be added to all the existing bugs.) 18:22:21 (I could be +1 to A though, I guess) 18:22:23 pjones: Closing the bugs with "This was filed in error, please disregard" would be pretty clear 18:23:14 anyhow --I think we have enough to pass asking hte reporter to file his Fedora Change for next week. 18:23:21 +1 comments on filed bugs about fpc compliance, correcting those bits, and keeping the bug open as a tracker seems okay to me. 18:23:24 #accepted: Ask the Python 3 bug filers to file a Change by next week 18:23:53 If we want to discuss fesco/reporter vs fpc comments the bug, we can do that after the regular agenda items. 18:24:06 fair enough. 18:24:16 Proposal B is at +3-4 now 18:24:22 So let's move on for now 18:24:28 #topic #1177 Codify how we are going to select the working group members 18:24:30 .fesco 1177 18:24:31 mitr: #1177 (Codify how we are going to select the working group members) – FESCo - https://fedorahosted.org/fesco/ticket/1177 18:24:32 https://fedorahosted.org/fesco/ticket/1177 18:25:03 So, I made an initial proposal as a straw-man to start the conversation. It's not intended to be complete and without flaw. 18:25:08 So here, we are blessed with too much of a good thing. :) 18:25:29 sgallagh: I don't like items 2 and 3 18:25:37 Honestly, I was worried that we wouldn't have enough serious volunteers to fill the groups 18:25:40 re: 2, I'd rather be upfront with that this needs to work for Red Hat 18:26:02 mattdm: well, if we go to 9 for all groups, we *don't* by policy #2 18:26:07 * abadger1999 notes that last he looked, 2 would be impossible to achieve with nine members on a WG 18:26:10 re: 3, we need coordination, at the very least for base design vs. products, and I'm not sure playing Chinese Whispers through FESCo is affective 18:26:15 mitr: Well, the proposal still allows for a Red Hat majority, just not a super-majority. 18:26:48 I.e. five out of nine members. 18:27:08 I'm more worried about having representation from qa, releng, marketing, ambassadors than I am about having too many red hatters 18:27:42 mattdm: which... we don't really for most of them. depending on which hats nirik and I are wearing at any given time 18:27:56 mattdm: well, I think mitr is saying something orthogonal to that - basically if whatever they come up with doesn't work for RH, it's a non-starter. 18:28:25 mattdm: I'm not sure... I can see the case for having all stakeholders well represented, OTOH there's also a case for the WGs actually being able to do the work, either by having available mapnpower or by being able to command it, which would imply a more technical bias 18:28:25 pjones: +1 18:28:27 could we have groups self select? or is that doomed? 18:28:38 pjones Right. that's a big elephant that underlies everything Fedora does without actually being in our mission docs. That's another issue. 18:28:50 * abadger1999 notes that if we have a vision for fedora.next, he'd rather steer clear of self-selection. 18:29:20 yeah, but it's hard to see who would be good to match a 'vision' for a lot of people I suspect. 18:29:25 I also note that we have fesco members listed for all of the groups except desktop 18:29:33 * sgallagh also notes that if we drive a vision that doesn't align with the community, we'll be voted out and the new FESCo will retarget anyway 18:29:41 unless i missed something 18:29:51 mattdm: I suspect we actually want to solicit self-nominations and then have /fesco/ vote. 18:29:56 +1 sgallagh 18:30:07 pjones yes, that's what we said we'd do. 18:30:10 well, we already did solicit them no? 18:30:33 the question is finding a process for narrowing down the lists to a practical working-group size 18:30:39 My statement was in contrast to "We should set up range voting for each of the working groups and request that ONLY volunteers for those groups vote." 18:30:42 Well, one of my suggestions was to have the members of each group of volunteers range-vote for the other members. 18:30:45 sgallagh: that we be the other side of the coin from the WG's not coming up with something that works for RH. 18:30:51 nirik:: Perhaps what we want to knou about everybody is not a "vision", but hearing "what are you planning contribute" ? OTOH too late for that as well I think. 18:30:52 so, have each fesco member come up with their list, cross match and ? 18:30:53 If nothing else, it would give us a sense of the group's internal recommendations. 18:31:19 sgallagh: we can't have them vote and then take the results as recommendations. That'll just piss people off. 18:31:21 Self-voting within a group doesn't necessarily work - one can sign up only to have a vote 18:31:26 i'm happy to have everyone who volunteered participate, but in order to be effective we need an actual formal structure with a small core with voting powers. like, 9, since that's our magic number for existing groups. 18:31:32 +1 pjones 18:31:36 +1 mitr 18:31:39 additionally, there should/must be input from more than the 9 people in any group... this would be just voting people/decision makers no? and some of them may step down, etc. 18:31:47 * jreznik would say number of people interested in WGs will sort out automatically - expect a lot of people for the first meeting, a few brave people to finalize it 18:31:51 sgallagh: however -- I will note that it might be better if the community could vote a new fesco -- the strawman of self-selection within a group doesn't allow the community at large to have any say; just the wg members. 18:32:33 abadger1999: sgallagh: what if we worry about doing a good job instead of political fallout ;) 18:32:35 pjones: Well, we *can* if we establish guidelines before the vote of how we're going to handle the results (i.e. if the nine highest-voted people are all doc-writers, we're going to select some engineers0 18:32:48 * notting tries to remember. FPC membership is... who showed up that current FPC approved? 18:33:15 it's fesco seeded, new members added by FPC vote? 18:33:17 (I think) 18:33:31 I would like to post another message (or several messages) targetted specifically at the various parts of fedora that i want to make sure are involved to make sure everyone got the message 18:33:36 nirik: I *think* that's right 18:33:37 notting: yeah -- the original FPC was selected from people who were knowledgable and willing by spot. The current FPC were people who volunteered (or persuaded to volunteer) that the current FPC then approved. 18:34:19 proposal: have the FESCo member responsible for each WG select the initial voting team in the same way 18:34:30 voting team? 18:34:36 The more serious issue is that we need to get the people who need to be involved to actually be involved. 18:34:38 mattdm: +1 18:34:39 people with voting rights in the working group 18:34:40 nirik: The nine-member Working Group that has a vote 18:34:43 doesn't that require a fesco member repsonsible for each WG? 18:34:52 If we just elect some people to serve as the desktop WG and they're not people working on desktop code, then what good are they? 18:34:56 notting: We stated that as a requirement originally 18:34:56 notting we put that in the original proposal 18:35:03 That each WG would have a FESCo representative 18:35:11 ok, who are those? ;) 18:35:19 pjones: +1 18:35:22 Perhaps we should start there 18:35:33 pjones they're working on qa and marketing for the desktop product? 18:35:41 fedora isn't just code and packages 18:35:55 mattdm: The desktop product that won't exist because nobody was involved in creating it? 18:36:00 mattdm: that's fine and all, but it still produces a decision making body that can't implement the decisions. 18:36:19 mattdm: sure, but you don't want marketing to necessarily decide what you're shipping on what schedule. at least not in isolation 18:36:22 sgallagh: do you suggest we should pick WG members and then pick FESCo members from those WG? 18:36:28 (as much fun as MRDs are) 18:36:32 right, we definitely want _some_ coders and packagers involved 18:36:56 mmaslano: Other way around. One FESCo member should be an appointee 18:36:59 So, to be honest focusing on a process for deciding should probably take a back door to the simpler question: who can we get? 18:37:05 but I don't think the upstream projects will go away regardless of what we decide. we're not _that_ powerful. 18:37:16 And responsible for relaying the working status back up to FESCo as a whole 18:37:52 pjones: if there's a poor pool of nominees, we should try and get people who are desireable to nominate before the period is over? 18:37:59 pjones there is no shortage of engineers in any of the working groups 18:38:06 https://fedoraproject.org/wiki/Fedora.next/WG_Nominations 18:38:07 nirik yes we should 18:38:24 ^ (above) no shortage in any of the wg self-nominations 18:38:28 * nirik thinks we should hit up marketing and docs and qa lists asking for more folks there if they are interested. 18:38:38 +1 nirik 18:38:48 nirik: ah, that list makes that a whole lot more clear. okay. 18:38:50 also i just said that a little bit ago :) 18:38:52 nirik: not sure how I missed it ;) 18:38:53 but anyhow. How do we pick which fesco member is contact for each wg? 18:39:09 mattdm: if you consider QA engineer, then it's nothing *but* engineers, afaict 18:39:15 nirik: Well, I'd start by seeing which groups have a single FESCo member volunteer. 18:39:20 5 groups 9 fesco members... anyone specifically NOT want to be a contact for any wg? 18:39:21 oh, and fearless leader rbergeron 18:39:25 notting, and ryan 18:39:36 +1 jwb 18:39:46 or +1 rlerch as the case may be :) 18:39:46 * mitr is still planning to sign up for something FWIW 18:40:06 anyway... 18:40:19 So, I think the fesco members who have volunteered for a given wg can decide amongst themselves which one wants to be 'it'? 18:40:19 (I do _not_ want the fun job of deciding which of the people will have a voting right) 18:40:34 mitr: ah ha! So you're the one to get the desktop WG ;-) 18:40:36 cloud and workstation have 0 fesco membres? 18:40:46 all others have more than 1 18:40:47 Cloud should have mattdm ... 18:40:50 (nominated) 18:40:52 it doesn't 18:40:57 nirik yes how am i not on that list? 18:40:58 he's obviously slacking 18:41:02 did I only do that in my sleep? 18:41:16 * mattdm has been doing a lot of things in his sleep recently 18:41:30 let's go ahead and assume i'm on that list :) 18:41:41 we do need someone for workstation. 18:41:45 server has 2, base design 2, stacks 3 (if i read it right) 18:41:55 If no one else wants that hot-potato, I'll volunteer. 18:42:10 I'm at least physically local to most of the Red Hat desktop folks, so that's useful. 18:42:48 sgallagh that is fine with me, although I kind of thought you'd be taking point on the server 18:43:03 but we've got nirik on there too 18:43:13 We should note someplace that this ads items to the "so there's a new fesco" process. 18:43:14 q: is the goal of the workstation product *a* desktop, or a collection of desktops? doing so influences what is chosen 18:43:18 * nirik is very busy these days... not sure I would make a good 'point person' 18:43:33 Since I assume if any of our representatives leave fesco, that means we're swapping out who represents fesco. 18:43:55 yeah 18:43:57 * abadger1999 notes nirik is in both base design and server atm too. 18:43:59 cant red hat just develop it's own distro completely internal since it seem to be that you have already decided how and what fedora next will be " basically if whatever they come up with doesn't work for RH, it's a non-starter." and you are going about to ensure the next future of fedora will be in RH best interst instead of what ever the community would like it to be? surely it must be better then this 18:43:59 mattdm: Server would be my first choice. (And probably the most obvious one) 18:44:01 pjones maybe... could be up to the individual governence of the group as set up in the future 18:44:17 mattdm: I think we want fesco to have a persistent voice. 18:44:29 (also I've got to go now. Will check up on the tickets and log later.) 18:44:54 Viking-Ice: It needs to be both. 18:45:06 Viking-Ice red hat could but it would be a huge loss 18:45:26 mattdm: stacks my first choice, also obvious. 18:45:31 the comment about "must work for rh" is just a statement of reality 18:45:51 does anyone _other_ than sgallagh want to represent desktop? 18:46:29 seriously be honest about what you are about doing 18:46:52 Viking-Ice I promise you I am being entirely honest. 18:47:01 mattdm, when you have already decided the way forward what good is the communtiy 18:47:05 back to nottings question, I thought the goal was 'a' desktop... but perhaps that could be decided by the group too. 18:47:06 and if I see anyone from Red Hat not being honest I will call them out 18:47:22 +1 nirik 18:47:54 mattdm: was that a +1 for "a desktop" or for "decided by the group" ? 18:47:59 nirik: that can be made self-fulfilling, though. by creating the WG, fesco essentially determines whether it's 1 DE or multiple DEs, and which DEs it is 18:48:04 +1 "a desktop" 18:48:11 cool. 18:48:27 * abadger1999 was thinking exactly notting's thoughts if it was self-determined. 18:48:38 notting: true 18:48:54 mattdm, RH should not be dictating the way forward for the community in it's best intrest it's not right and since that is the case why are you even bothering with some fake election 18:49:02 in other words, unless we say we are allowing for each desktop to be their own product, or forcing them all to be one product, we can't weasel out of that decision 18:49:12 just pick the bloody people that align with the already decided vision and be done with it 18:49:14 +1 "a desktop" (but honestly not interested in the details) 18:49:54 Viking-Ice because that's not what's happening? we can talk more later if you want. 18:49:56 I'm ok with 'a desktop' since it's one product, but I do want a way to build and distribute others for sure... 18:50:11 yeah sure and we all know what that desktop is going to be and we all continue to argue why xDE was not chosen but YDE was 18:51:46 anyhow, so we want to assign contacts for workstation and cloud now, and others pending on discussions/more nominations? 18:52:13 Viking-Ice: So, here's a deal. Bring me a proposal for a desktop product that is _clearly targeted at developers_ (that is not a WM, but IDEs, SCMs, and tooling), and I'll vote for it. 18:52:14 notting: yep.. I recall a disucssion on the ml about the products being extensible in the future... I think the current workstation target might be what we prototype with but we'll likely have others as we move along. 18:52:35 Viking-Ice: There's really not that kind of consenuss, although there is a definite ... tendency :) 18:53:05 mitr, or rather just allow all the sub-community to decide their own target audience and bring about their own products 18:54:04 * mmaslano says 29 minutes on the topic, some proposal, decision, more discussion? 18:54:05 Viking-Ice: It has been discussed that we may need to change or replace the products, yes; something like we have secondary archs. 18:54:30 * notting is -1 to sgallagh's proposal, if it's all or nothing 18:54:41 mitr, it's good that it has already been discussed and probably decided as well 18:54:54 Viking-Ice: the FESCo/board discussions have been public 18:55:01 sgallagh: which proposal? 18:55:05 We started with a FESCo representative choosing the WG, continued with discussion of the FESCo representatives; now that that's somewhat sorted, can we go back to the question of choosing the WGs? 18:55:07 sorry, notting: which proposal? 18:55:17 nirik: the one in the ticket 18:55:26 ah, ok. 18:55:31 yeah, -1 for that as well here... 18:55:52 notting: Yeah, like I said at the beginning, that was only meant to spark discussion 18:56:05 I'm worried that I'll find it easy to -1 any proposal... what can actually work? 18:56:18 mattdm: were you going to seed a call for more reps from non-packagers? 18:56:19 proposal: assign fesco members as contacts to each WG. These contacts should be in the group, they will select the initial 9 members for the group. After that the group will elect new/replacement members. 18:56:42 proposal: we pick the fesco member for each group, that fesco member picks the initial wg, that group comes up with the final governance structure, board approves 18:56:47 s/initial 9/initial/ 18:56:48 (addon: fesco approves selections) 18:56:57 nirik: conflates groups, i think. there should be a voting body > initial members to select new members 18:57:01 those are basically the same :) 18:57:02 mattdm: ... 0 (I can see it working well but I can't see how I would do it) 18:57:24 notting: ok, how about contact proposes, fesco votes on? 18:58:04 nirik: i mean, you don't want the WG being the only thing picking its membership on an ongoing basis. i.e., even if there are 9 members of the WG, the overal SIG (or whatever) should be bigger 18:58:06 nirik: I like that better 18:58:31 notting: For FESCo, that's "essentially those doing something FESCo-influenced". How would the voting body for the products be formed? All packagers, or somehow restricted to that product (how?) 18:58:55 notting: hum, I agree there should be more folks than voting members involved, but I don't see a better way to for sure pick people, unless it just falls to fesco to replace members leaving wg's 18:59:09 notting: depends on ow much continuity you want... which in turn, depends on what the WG ends up being for.... 18:59:16 nirik: Yes, that's better 18:59:24 abadger1999: and around and around we go... 18:59:32 I guess people will pick themselves, how many people will be interesting in meetings, writing proposal and so on... 18:59:58 But yeah -- the products WG's? I think those should have more emphasis on the group. 19:00:02 i do wonder how many people volunteered out of a sense of duty. i guess we'll find out! 19:00:18 Not so sure about base design and environments and stacks. 19:01:09 mmaslano: +1 19:01:45 those seem a bit more like the FPC where having continuity and building on what came before are important. 19:01:51 proposal: (modified from nirik) assign fesco membr to each WG. this member is part of the WG, and they will select the initial 9 members (approved by fesco). succession planning and governance is a deliverable *of* the WG 19:02:07 +1 notting 19:02:08 notting: +1 19:02:11 sure, +1 19:02:14 notting: +1, close enough 19:02:20 notting: +1 19:02:34 notting: probably best wording +1 19:02:52 #agreed assign fesco membr to each WG. this member is part of the WG, and they will select the initial 9 members (approved by fesco). succession planning and governance is a deliverable *of* the WG (+7) 19:03:37 Do we want to do the assignment now? 19:03:44 I'd rather wait until the end of the sign-up period 19:03:54 that seems reasonable 19:04:00 (which is when?) 19:04:08 yeah, we could ask more QA, docs, marketing and others to join 19:04:11 mitr: I'd at least like to sort out which of us are willing to volunteer for the Workstation product. 19:04:17 notting: Oct 11 19:04:26 message says at least one month from when i sent it out two weeks ago. 19:04:45 because I thought that like four people would sign up total for some of them, i left it open 19:04:48 so, perhaps we figure it on the 16th meeting? 19:05:32 Sounds good 19:05:37 Okay if I add October 16th to the wiki page as the noinations cut off? 19:06:16 abadger1999: make it the 15th? 19:06:23 Do we want to address the question of having people on more than one WG? 19:06:24 abadger1999: Oct 14 at the latest I think, to avoid TZ differences and allow us to think about the FESCo nominations for at least a day 19:06:35 yeah... some time before meeting would be nice. 19:06:51 How about "the beginning of the FESCo meeting on October 16th" 19:07:19 sgallagh: I guess they will drop. Who would attend so many meetings :) 19:07:34 sgallagh: at least I'll do it 19:07:38 * notting will not be at that meeting. not that that should change things. 19:07:53 sgallagh: I do think there should be an overlap, although not necessarily formal 19:07:56 * abadger1999 just remembers elections with late candidates who then were still allowed in and what "discussions" that caused. 19:08:27 notting: We'll just put you in charge of unrelated WG's :-) 19:08:48 Proposal: End nomination period on Oct 14 0:00 UTC 19:09:15 mitr: +1 19:09:30 mitr: sure, +1 19:09:38 mitr: +1 19:09:44 mattdm: You should send an email about the end of nominations since the original email was open-ended. 19:09:47 ok. +1 19:09:55 wfm +1 19:09:56 abadger1999 yeah, i will 19:09:58 (another email would be a good reminder to people too) 19:10:06 #agreed WG nomination period will end on Oct 14 0:00 UTC 19:10:14 * abadger1999 adds Oct 14 00:00 UTC to the wiki 19:10:14 mattdm: do you want to send the announcement, or shall I? 19:10:37 mitr if you could send that announcement that would be awesome 19:10:42 mattdm: will do 19:10:51 i'll send some other messages to docs and qa and so on asking about interest 19:10:56 should we work on a procedure for proposing new WGs? 19:11:35 notting: ISTM we already have too much meta-governance discussions... do we need it more precise than "talk to the board and FESCo"? 19:12:00 sgallagh: re: member overlap - we could pre-commit to no overlap, or just implicitly decide by voting on the specific proposals on Oct 16 19:12:08 notting: let's do that after the original WG's get off the ground. 19:12:13 mitr: i think it's sort of a requirement of having a desktop/workstation/whatever product, though 19:12:17 mostly talk to FESCo 19:12:27 sgallagh: do you want to propose a wording to vote on now? 19:12:28 it'll probably prove informative watching them bootstrap as well. 19:12:46 mitr: Well, I'd like to pre-decide on that, because we can ask people to remove themselves from one or more WG volunteer lists. 19:12:54 It'll let us know where they think they can do the most good. 19:13:26 sgallagh: In that case I'd probably want to self-nominate to one WG and add a contingent self-nomination to at least one other... 19:14:02 Proposal: In the reminder email, add the following wording. "Membership in a Working Group is a significant investment in time. We strongly recommend against volunteering to serve on more than one, lest you get your wish." 19:14:05 notting: Perhaps once we have an idea how / whether spins and products interact, that question will already be answered? 19:14:44 notting: IOW, if we keep the existing non-release blocking spins even in the 3-product world, other desktops can use this process 19:14:52 +1 sgallagh 19:15:21 yeah, i'm okay with that wording. 19:15:35 mitr: ... maybe? just that creating a desktop product draws an arbitrary line in the way that a server or a cloud doesn't (well,l except the weird line between server and cloud). 19:16:05 notting: wait for the webmin on server dicussion (wait, did I jinx it?) 19:16:19 single worst spec I have ever seen in my life. 19:16:27 mitr: "openlmi or linuxconf? pistols at dawn." 19:16:35 notting: right 19:16:41 sgallagh: hm. Not thrilled about it, but a reasonable thing to say, +1 19:16:50 More votes on sgallagh's wording? 19:17:24 sgallagh: sure, +1 19:17:42 * abadger1999 notes that if people sign up for more than one, the fesco selectors can still talk to each other and select an alternate if they have one. 19:17:57 #agreed In the reminder email, add the following wording. "Membership in a Working Group is a significant investment in time. We strongly recommend against volunteering to serve on more than one, lest you get your wish." 19:18:05 Anything else on WG member selection? 19:18:44 notting: Do you want to talk about the new WG procedure now, or in a separate FESCo ticket? 19:19:11 mitr: if we've got other agenda items, it can wait 19:19:22 mitr: I was still hoping that someone else would volunteer for the Workstation wrangler job so I don't have to do it :) 19:19:53 sgallagh: sorry, not me 19:19:57 Any other volunteers? 19:20:13 notting: noted 19:20:15 i think my name is in too many places 19:21:03 dibs on notting ;-) 19:21:44 * mitr reads thas as "no volunteers", moving on 19:21:49 #topic #1178 Fedora 21 scheduling strategy 19:21:52 .fesco 1178 19:21:53 mitr: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 19:21:54 https://fedorahosted.org/fesco/ticket/1178 19:23:18 jreznik's proposals: 19:23:20 1) continue F21 using the current process, use WG output only for F22+ 19:23:22 2) ask for specific proposals what to delay F21 for, using the Change process 19:24:09 I hate to be slow, but the flock scheduling point is compelling 19:24:19 (I don't really think the second makes much sense ... if we are not ready for the 3 products thing just do a regular release in the meantime .... maybe with less changes because people are busy) 19:24:23 note, releng groaned very loudly at the prospect of another short cycle. 19:24:34 mattdm: when is next flock? 19:24:40 qa isn't thrilled about the prospect, either 19:24:48 I'd prefer 3) do the 3 products for F21 already, just using the existing spins for "content", only getting the rel-eng and QA done. Assume a normal schedule, with accepting a heightened risk of slips 19:24:52 notting tbd, but the funding isn't there until march 19:24:52 well it does not have to be shorter one 19:24:54 notting, it's up for bids right now. no set time 19:24:59 and that includes buying plane tickets 19:25:09 if it were up to me I'd have it in january 19:25:09 mattdm: so, 'after march', ok. 19:25:12 in the bahamas 19:25:35 expect more july+ 19:25:44 mitr: i think QA and releng are the things *most likely to need more engineering time* 19:25:48 mattdm: or July in Fairbanks? 19:25:58 notting: yet they didn't ask for any specific amount IIRC 19:26:10 mitr: I agree, let's start to working on it 19:26:18 I'm really worried that if we give WGs 3 months to produce ... a wiki page, and nothing at all will change in our actual work for the next ~9 months, all momentum for the products restructuring will just evaporate 19:26:31 maybe we could have a Fedora Activity Day to work on qa and releng automation plans? 19:26:40 19:26:40 +1 mitr 19:26:40 notting: Hence the proposal for assuming the current cycle, and just seeing how much slipping is necessary 19:26:42 I don't think we want two shortened cycles in a row, FWIW. 19:27:02 mitr: didn't realize that we were supposed to have submitted proposals already 19:27:12 sgallagh: it does not have to be shorter one... 19:27:29 shorter cycles -> burned out qa and releng... and we already have done that after the long f18 one... and short f19/f20 ones 19:27:49 tflink: the "slowing down the development schedule for a release." thread was where we were hoping to see _specific_ benefits to slowing down 19:27:51 the only problem is I have is - there were a few generic - yeah, we could use that time for stuff we wanted to do years ago... 19:28:27 there are only so many hours in a day - I just got started working on stuff for qa automation 19:28:35 mitr: and except qa automation idea we did not hear any real proposal we can say how much we want to slip and why 19:28:37 which is true for everyone, I know 19:28:42 in addition for time for 'doing specific things', I think it's also important to have time to be more relaxed about doing the things we are doing... less mistakes, etc. 19:29:12 jreznik: right; everyone has years of backlog but that alone is not automatically a reason to slow down 19:29:19 nirik: but then - do you want month, three, six, ten? 19:29:25 jreznik dgilmore also had a list of things 19:29:29 nirik: more time just means people will do more stuff which means more bugs unless we have really long freezes but not sure that flys either 19:29:32 which i'm sure he could flesh out if he had more time. 19:29:51 mattdm: that's why I say - let's try to collect it 19:29:57 drago01_: so we should do nothing, and no bugs? 19:30:10 * nirik kids 19:30:26 in more formal way and we can say then - x months is what we want, not blindly guessing 19:30:37 nirik: no because we already have bugs ;) 19:30:37 is having a FAD for planning the automation and other paydown-of-tech-debt projects something we could reasonably do? 19:30:42 tflink: I suppose it would make sense for QA to say "for the N-month pre-release crunch we always want a C*N-month quiet development period" or something like that, to get the basic proportions workable at all 19:30:48 I'd need to know: are we delivering our current deliverables for f21? or 'new, TBD' ones? 19:31:08 mitr: sure, I'm not saying that we shouldn't have to make more specific proposals 19:31:24 mattdm: Would that help? The last day of Flock was supposed to be where these things get implemented IIRC and... didnt? 19:31:25 saying "we need X months for ... stuff" isn't going to end well 19:31:26 mattdm, wtf does 'paydown-of-tech-debt' mean? 19:31:38 mattdm: i would be all for that 19:31:45 mattdm: automate-all-the-things FAD 19:31:47 jwb: for qa, actually making progress on automation 19:31:56 if we can come up with goals specific enough for FADs sure. 19:32:00 That is FAD for Fedora Activity Decade? 19:32:06 jwb too buzzwordy? :) accumulation of things we know could be improved but keep taking shortcuts on because we don't have time to do it 19:32:07 autoqa has been getting along on bandaids since ~ f17 19:32:12 nirik: that's the question #1 - as WGs output is expected in January, do we want to hold f21 schedule completely and start from scratch? 19:32:22 mattdm, hella-buzzwordy. 19:33:10 jreznik: it's really hard for me to say without a time machine so I could look at what we have in january. ;) 19:33:51 nirik: the nice and sweet next fedora? :) 19:34:13 we can also put releases on hold until we define a new strategy... 19:34:32 jreznik: ugh 19:34:36 jreznik: that seems a bit risky to me without a more firm deadline 19:34:42 anyhow, personally, if we are doing another f21 'traditional' release, I'd not want a short cycle. I would want a more normal one. If we are doing a fedora.next f21, I'm not sure I can say until I know deliverables and what all we need to retool. 19:34:46 jreznik: that's asking our users "go elsewhere" 19:34:47 jreznik: That's supposed to be a threat?:) 19:35:24 nirik: Right, there seems to be no strong case for making f21 _short_. 19:35:31 nirik: I'm more inclined to normal release too 19:35:48 well, one thing that was mentioned was realignment with gnome upstream releases. 19:36:03 nirik a long f22 cycle would do that too 19:37:01 * nirik doesn't see off hand a projected 3.12 release date. 19:37:10 Can we do a _regular_ f21 cycle and still make room for some automation work? 19:37:27 'march 2014' I guess 19:37:47 nirik, 3.12 kernel? 19:37:52 nov... 19:37:58 no, gnome. ;) 19:38:04 oh. version collision 19:38:06 yep. 19:38:08 sorry 19:38:11 nirik: yeah end of march 2014 should be about right 19:38:12 the only thing I don't like about mitr's proposal a few pages back is that it means that the new products aren't really very new 19:38:14 mattdm: that's the hope for qa, we just got a new hire and in theory, josef and I are going to be spending more time on devel 19:38:34 s/going to/hopefully going to 19:38:46 and I guess it's okay for the products to more slowly diverge rather than sharply branch 19:39:15 mattdm: I don't like that either, but when the Board has approved that the WG output is due in January so I can't see a way to significantly impact F21 19:39:28 mattdm: I would prefer start working now on release of 3 products, so we have more time to change web pages, release engineerin stuff etc. 19:39:45 mattdm: well, we already have two of three products... I don't expect cloud to be really very different to what we have now and workstation would mostly depend on our current gnome team, so we only need server one and then we can dismiss WGs :) 19:39:48 mattdm: This is a way to get the "infrastructure" parts closer to done now, so that we can have all the nice flamewars about content later 19:41:58 * jreznik would be ok with f21 with renamed current offering to the new one with normal release cycle 19:42:25 let's vote on this one ^ 19:42:31 jreznik: So are you thinking that f21 (three products) would be built with mostly the same infra -- just hosted and marketed differently/ 19:42:45 abadger1999: yep 19:42:45 I'm not sure how practical that will be. 19:43:11 * nirik ponders 19:43:14 that sounds like a nightmare to me 19:43:33 tflink -- you'd still like the longer cycle? 19:43:34 why? 19:43:54 is there any scenario where fedora ships 3 products that doesn't sound like a nightmare to you? 19:43:57 jreznik: 3 times the things to test with our current processes? 19:44:00 tflink: why? There's already the cloud and desktop spin and the DVD image, is there even extra work? 19:44:14 tflink: it's exactly what we have now, just one more server image 19:44:21 that is the definition of extra work :) 19:44:33 one more straw, etc 19:44:55 we really need to get tim et all the time and resources to improve the processes 19:45:01 i'm for whatever does that best 19:45:06 jwb: there are ways to do it that don't sound like a nightmare to me 19:45:07 jreznik: I sthat even "one more" or replacing the DVD? 19:45:22 tflink, great! be verbose about them and tell FESCo 19:45:32 because THAT IS WHAT THEY ARE TRYING TO FIGURE OUT 19:46:01 i am all for launching the dvd image into the sun 19:46:09 the biggest thing that doesn't scale is the amount of manual testing we do 19:46:17 I was one of the people asking for the shorter F21 cycle (to get back on track with the March / November releases and with upstreams that release at that time) 19:46:22 in my opinion, it would be nice to make it a few weeks shorter than the F20 release but it doesn't necessary have to be much, to not burn out releng / QA 19:46:28 if we can get some/most of that automated, qa is going to scale much better to multiple products 19:46:32 a bit shorter to make up the time lost in F20 slips + two additional weeks cut off, perhaps 19:46:48 mattdm: I'm not quite sure that it is a time problem... perhaps it's more a cultural thing of not being hell-bent on automating everything possible? 19:46:54 three products within one normal release cycle I'm pretty sure the entire QA is against that or a shorter release cycle which is equally bad 19:47:11 kalev: I think another schedule the same as f20 would burn out releng. 19:47:31 Viking-Ice: now we have more two of them and I don't expect we would have that 3rd for F21 (server) 19:47:39 mitr: when we're constantly going back and forth between 100% testing and 75% devel, it's hard to get anything significant done 19:48:29 tflink: Right, that comment was more targeted on other areas... 19:48:30 kalev: i assume you mean may/nov, btw 19:48:38 ah yes 19:48:42 One issue I see with making it a goal of f21 to get back onto May and November releases is that if we're implementing fedora.next changes in f22, we may well immediately get out of sync again. 19:48:46 making it longer than 6 months after all the heroic releng / QA effort to get back on track with F20 seems silly 19:48:52 the proper way to go forward is to essentially deliver 21 as an November oktober release and allow the service sub community to work on various bits and preferably get anaconda on different track ( be close to ready at branch time ) 19:49:16 that would allow QA to focus on 3 or more products 19:49:58 and probably for the working group to work out what those products are 19:50:26 you know if that actually was an option to begin with ( which it does not seem to be since it seems to be already determine how they should look like ) 19:50:53 kalev: there's no need to try sync with fedora.next - workstation could sync with it's own upstream (gnome for example) 19:51:30 jreznik: ? if it's not forking its entire base, and other things are a subset of it there needs to be some sync 19:51:34 * nirik is not happy with non synced releases, but thats another topic I suppose. 19:51:35 jwb: there are lots of papercuts that we'd like to address - ie, being able to tell when test cases where last run - that would help 19:51:42 jreznik: well.... depends on base design... workstation could end up syncing to two upstreams (gnome and fedora-code) 19:51:57 jreznik: non-synced releases seem like a world of pain 19:52:42 so: aim for june f21 release followed by flock, with current deliverables, and then big three-product launch in may 2015? that sounds like a long way off 19:52:48 tflink, sounds reasonable. so, from a timeframe standpoint, is there an estimate of how long that would take, etc? 19:52:51 mattdm: +1 19:53:01 nirik: the way I've visioned it is that we might perhaps have 2 syncronization points, twice a year. Workstation would probably want to release at both syncronization points, and server maybe once a year? 19:53:12 jreznik +1 to we'll all be old and grey by then, or +1 to that schedule 19:53:15 mattdm: i'd rather push f21 later and split that 19:53:22 jwb: just got started working on it - have been busy putting out fires 19:53:41 tflink, ok. well, that's the kind of info FESCo is asking for 19:53:48 i know 19:53:52 mattdm: So thought - what's the minimum three-products based redesign we would consider to be a working prototype? How long woulod it take to get that out the door? 19:54:11 kalev: I don't think server folks would like that... but I suppose it could be discussed. 19:54:17 mattdm: Maybe we do that for f21. rather than the "perfect plan" that hte wg's come up with. 19:55:06 if we already have a plan, why do we have WGs? 19:55:11 doing it was spins but allowing more free reign in divergence from the common base seesm pretty reasonable. for example, there's great pressure to drop iptables package filtering from the cloud spin, but we've resisted because it would be so different 19:55:17 it's going to end up being a balance between getting automation done and not delaying too far - I'd really like to get some of the base tools done, though - makes it easier to make progress on other related fronts 19:55:29 Also, doing the automation and cleanups in the non-product world and changing immediately afterwards seems like a waste 19:55:29 notting: I don't know -- do we have a plan? Do we need WG's? 19:55:59 jwb: I'm getting stuff put together but it's not going to happen today 19:56:01 jreznik: seems to have an idea of how to release three products. 19:56:04 the plan, I mean 19:56:38 tflink yes please! 19:56:53 so in that vision, the WG's are probably there to define what goes in the three products and form QA/packager/docs/etc groups to take care of them. 19:56:55 tflink, jreznik: so, defer a week for a plan? Or would we rather make a decision now to avoid another long meeting? 19:57:16 abadger1999 yes. and steward them as they go beyond that. 19:57:19 * jreznik is always happy to spend a late evening with you! 19:57:31 19:57:52 * nirik would like to get input here from dgilmore. Another week is likely good. 19:58:02 mattdm: well I think we are pretty close to the idea of having more products already - after that decision to allow desktop spin not to ship sendmail 19:58:23 So -- it sounds to me like tflink and dgilmore both have things they would like to get done -- we just don't have a ballpark for actual time we should delay to get those things done. 19:58:28 * mattdm nods 19:58:43 proposal: defer for a week 19:58:46 I think I'm +1 to a delayed f21. Just need to work out how long to delay for next week. 19:59:20 mitr: yes, +1 19:59:22 abadger1999: and what we want to achieve... 19:59:22 +1 mitr let's get more info 19:59:28 +1 19:59:30 +1 19:59:43 so that's more like my option 2) call for proposals 19:59:46 #agreed defer for a week, pending input from tflink and dgilmore 19:59:52 mitr: +1 19:59:53 you guys are kind of boxing yourselves in here. 19:59:56 you could say that in the beginning :) 19:59:58 it's not "delayed f21" 20:00:19 if f21 is fedora.next, it cannot possibly be delayed because it's fscking NEW 20:00:26 jwb +1000000 20:00:32 * nirik nods. 20:00:57 jwb: that's the question nobody answered - will be f21 fedora.next already? :) 20:01:03 why just wait for them? 20:01:11 #topic #1179 Interactions of the various Products 20:01:13 .fesco 1179 20:01:14 mitr: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179 20:01:15 https://fedorahosted.org/fesco/ticket/1179 20:01:15 heh -- except that I don't think people agreed on whether f21 was fedora new and improved or fedora old and inferior above. 20:01:30 abadger1999: yep, see above :))) 20:01:51 So, https://fedoraproject.org/wiki/Fedora.next/ProductInteractions is... exploring the future 20:01:58 if fedora.next is the way, the future, and the light, then i don't understand why f21 wouldn't be fedora.next. otherwise it sounds like you guys came up with this awesome thing and didn't actually think it through 20:01:59 Do we even want to make this kind of decisions? 20:02:05 fedora old and inferior has names. names stopped with f20, therefore it's the new thing, and can wait until we're ready. *shrug* 20:02:09 mitr: I must say I found the wiki page very confusing. ;) what are we trying to solve here? 20:02:24 notting, sure. whatever it takes to get over the mental hurdle 20:02:29 but damn people 20:02:32 nirik: "we want to be able to run Cloud network services on the Server, and develop them on the Workstation" is the one-line summary 20:03:01 ok... then lets do? :) 20:03:21 notting: I like your criteria for separation ;-) 20:03:33 the web page seems to be trying to define the products, which the WGs are supposed to do? or is this supposed to define the minimum things they're expected to do? 20:03:49 mitr: it's a good start 20:03:51 looks like this request is a bit premature 20:03:55 notting: the minimum, or 20:04:21 what FESCo wants from the WGs. Do we even want anything? 20:04:23 jwb: if f21 is fedora.next, then it does not make sense to discuss it's schedule now, put it on hold and wait on what's actually fedora.next and thus f21 should be and then plan, just my 1 cent 20:04:32 sure 20:05:24 mitr: fwiw imo your draft is to much focused on the cloud 20:05:45 I hope that our working groups are full of reasonable people who can cooperate... if they can't, it can be escalated to fesco to try and sort out? 20:06:08 mitr The board (well, specifically Matthew Garrett) was very strongly against having FESCo set initial guidance like this for the working groups 20:06:12 drago01_: The first question I have is, should these things be FESCo-driven or arise from the WGs talking? (and if the latter, how?) 20:06:15 Proposal: F21 is dead, long live Fedora Server, Fedora Cloud, Fedora Workstation. Schedule to be decided firmly after WG report-in. QE and Rel-Eng can count on the next two months for working on their backlog. 20:06:31 with constrained resources, we would require as much coordination and I really hope people will realize it :) 20:06:54 sgallagh: except the next two months are getting f20 out. ;) 20:07:03 * jreznik will try to sheppard them to realize that and cooperate and offers to work on processes that will help share stuff 20:07:22 nirik: I meant December and most of January, really. 20:07:25 mitr: IMHO, they should work out these things and come to fesco if agreement can't be reached. 20:07:27 'next' was wrong 20:07:28 sgallagh: -1, I'm fairly convinced that feature-based releases don't work (or we don't know how to make them work) 20:07:29 mitr: well I mean it is stating the obvious "the server must be able to run the cloud" ... well yes why not ... "you must be able to develop for the cloud on the workstation" ... err yeah but no only for the cloud 20:07:44 mitr: I'm not necesarily talking about feature-based release 20:08:05 sgallagh: Then we can decide on a provisional schedule already 20:08:08 I too think that feature based releases don't work. Schedule first and then see how much we can fit in there. 20:08:13 Historically, Fedora N final freeze == Fedora N+1 kickoff 20:08:31 I'm suggesting that we put a gap here where the WGs can do their jobs 20:08:33 kalev: but we don't do it for a few releases, we do something in between 20:08:53 And then build a schedule starting from the report-in date 20:08:54 drago01_: It's not obvious to me that these things will automatically be true. Yes, "why not" but it may well happen that the products will decide to diverge too much 20:08:54 sgallagh: even earlier 20:10:34 guys, we said defer, so what are we trying to solve now? 20:10:42 does anyone another proposal? 20:11:02 proposal : we do not necessarily need to define these interactions yet 20:11:09 +1 20:11:12 notting: +1 20:11:24 notting: +1 20:11:48 notting: works for me; then I'll ask whether that means "repropose to FESCo later", "repropose to WGs" or something else 20:12:41 mitr: hm.... wait for the WGs to start checking in, see if there are obvious conflicts? 20:13:01 notting +1 20:13:17 notting: I'm worried that this will amount to the old "we ship what upstream does" mindset that IMHO doesn't work that well now 20:13:54 mattdm: was the +1 to notting's proposal or the later comment? 20:14:04 proposal 20:14:07 #agreed we do not necessarily need to define these interactions yet (+5) 20:14:24 #topic Next week's chair 20:14:29 Any volunteer? 20:14:39 * nirik will very likely not be at next weeks meeting. 20:14:44 mitr: I guess I don't see how the present page is going to help with the interactions. 20:15:43 abadger1999: 1) something to account for in the design by everyone, 2) explicitly tasking the base design WG to design the "packaging" 20:17:05 mitr: okay -- for 1) - I think take the those to the working groups. 2) -- yeah fesco could talk about that before the base design wg is present... probably best to write something that fousses strictly on that then. 20:17:50 mitr: I'll take the chair if you close the meeting. Deal? 20:18:11 :) 20:18:19 mitr: note -- I somewhat disagree with the requirement under base design -- I think that's more the env and stack and fpc. 20:18:21 mmaslano: works for me ... we are way over 0x80 minutes. Objections? Any urgent items for open floor? 20:18:32 abadger1999: Then what does base design do? 20:18:42 base design defines the base fedora platform. 20:19:05 what is in the base fedora platform. how long is a base fedora platform maintained. 20:19:07 That doesn't say anything specific to me 20:19:31 Seeing no urgent items and objections... 20:19:38 #action mmaslano to chair the next meeting 20:19:42 Thanks enveryone! 20:19:49 #endmeeting