18:00:45 <mitr> #startmeeting FESCO (2013-10-02)
18:00:45 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:48 <mitr> #meetingname fesco
18:00:48 <zodbot> The meeting name has been set to 'fesco'
18:00:50 <mitr> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:00:50 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:52 <mitr> #topic init process
18:00:54 <mitr> Hello all
18:00:56 <mitr> t8m can't join today
18:01:00 <pjones> hello.
18:01:06 <nirik> morning
18:01:07 * pjones has a hard-stop again at 2:45
18:01:14 <pjones> (I expect this to continue for the indefinite future.
18:01:15 <pjones> )
18:01:24 * notting is here
18:01:33 <abadger1999> pjones: should we be looking for a new time?
18:01:34 * sgallagh settles in for an interesting meeting
18:01:44 <nirik> pjones: the meetings will continue until morale improves? ;)
18:01:53 * abadger1999 has something to throw onto open floor as well.
18:02:16 <sgallagh> 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 <notting> abadger1999: you throw it on the floor, you have to clean it up
18:02:23 * mattdm is here
18:02:38 <pjones> 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 <abadger1999> notting: As long as I have permission to use the fesco mop ;-)
18:02:52 <sgallagh> abadger1999: That's my *head*!
18:03:06 <abadger1999> pjones: sure.  just say the word if it becomes an issue.
18:03:15 <mmaslano> hi
18:03:24 <mitr> OK, that's everybody
18:04:00 <mitr> Is there anything for open floor that we would want to take care of first?
18:04:31 <mitr> abadger1999?
18:04:57 * abadger1999 gets linlk
18:05:06 <abadger1999> https://bugzilla.redhat.com/show_bug.cgi?id=1014209
18:05:21 <abadger1999> 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 <mitr> 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 <abadger1999> 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 <abadger1999> 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 <mattdm> ouch
18:07:19 <abadger1999> mitr: yeah -- if people would rather discuss than just go with my proposal, I'd be fine with following hte schedule.
18:07:31 <notting> 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 <mitr> abadger1999: hm, ok.
18:07:44 <mitr> #topic Python 3 support
18:07:45 <abadger1999> notting: yep.  I'd be okay with that.
18:08:11 <abadger1999> (with making clear that an option is to move to a different python3 lib or application.
18:08:35 <mitr> 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 <mitr> 2) AFAICT we _will_ need to move to Python 3
18:08:50 <abadger1999> mitr: there's nothing in the bugs that say that.
18:08:54 <mattdm> or rewriting the program entirely in go
18:09:02 <mitr> "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 <mattdm> </notserious>
18:09:08 <abadger1999> 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 <notting> mattdm: if you do it right, get each package to move to a different language... go, lua, haskell, ocaml, erlang, scala...
18:09:49 <abadger1999> which is expressing "you must add python3 support"
18:10:00 <mitr> ... by Python 22
18:10:25 <sgallagh> mitr: I assume you mean Fedora 22, and we don't actually know when that's going to be
18:10:31 <mattdm> Python 22 will be written in Go.
18:10:34 <sgallagh> Minimum of 12 months, I would guess
18:10:35 <mitr> sgallagh: yes
18:10:42 <nirik> I don't recall us approving a change to do this.
18:10:51 <sgallagh> nirik: We haven't.
18:11:06 <nirik> right
18:11:08 * mmaslano agree that having Change approved before mass filing bugs would be a good thing
18:11:11 <sgallagh> nirik: I'd be in favor of it, but that's irrelevant without a proposal
18:11:12 <mitr> Right now it is, and reads like, somebody's personal wish
18:11:26 <mitr> 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 <sgallagh> 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 <mitr> +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 <nirik> 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 <abadger1999> Well -- it also violates the packaging guidelines... So a comment would need to be made.
18:12:18 <mattdm> i remember there _was_ some discussion on devel list
18:12:27 <notting> 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 <mitr> 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 <sgallagh> mitr: Agreed.
18:13:16 <mattdm> 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 <mmaslano> mattdm: I would prefer it
18:13:33 <mmaslano> nirik: agree
18:13:36 <sgallagh> nirik: +1
18:13:55 <mitr> 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 <notting> mitr: +1
18:14:05 <pjones> mitr: +1
18:14:11 <mmaslano> mitr: +1
18:14:16 * mattdm is looking for the fedora devel thread
18:14:18 <abadger1999> mitr: Well -- I'll have to mass comment those bugs if there's no comment on them.
18:14:18 <notting> it's not as if we weren't expecting a Change for this in the near future
18:14:24 <nirik> without noting to people about the thing thats against guidelines?
18:14:27 <abadger1999> (by the reporter)
18:14:28 <sgallagh> mitr: +1
18:14:37 <mitr> abadger1999: why?
18:14:38 <mattdm> https://lists.fedoraproject.org/pipermail/devel/2013-July/186098.html
18:14:46 <abadger1999> to say that patching the package at the Fedora level is contrary to guidelines.
18:15:22 <mitr> abadger1999: Then the guidelines need to change IMHO, \but that's for another week
18:15:33 <abadger1999> mitr: no -- supporting python3 is still possible.
18:15:40 <sgallagh> 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 <abadger1999> mitr: But you create a second package in that case.
18:16:12 <sgallagh> abadger1999: A second package or a subpackage?
18:16:13 <abadger1999> sgallagh: also note -- that's for binary builds (and possibly source  tarballs) the scm will still see updates beyond that.
18:16:16 <abadger1999> sgallagh: second package
18:16:22 <abadger1999> sgallagh: the subpackage is what's disallowed
18:16:30 <abadger1999> sgallagh: because you've really forked at that point
18:16:31 <mmaslano> 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 <mitr> 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 <abadger1999> sgallagh: so there should be a seond package for the fork.
18:17:04 <nirik> 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 <abadger1999> mitr: well -- letting them do A) and then tellingthem to revert A is also a waste of effort.
18:17:44 <sgallagh> 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 <mitr> Isn't most of the effort in the coding, not in the packaging ?
18:17:47 <abadger1999> 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 <sgallagh> Sorry, not reopened but refiled
18:18:42 <notting> 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 <abadger1999> sgallagh: I'd be willing to +1 as that's more strict than what I proposed.
18:19:02 <mitr> notting, sgallagh: It did, with sgallagh's +1, but he seems to have changed his mind
18:19:05 <nirik> notting: yeah, it does.
18:19:26 <sgallagh> 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 <sgallagh> So I'm withdrawing my +1 from mitr's proposal.
18:20:05 <mitr> So, let's split this and get it away with:
18:20:19 <mitr> Proposal A: Ask them to file a Change by next week
18:20:27 <mitr> Proposal B: mass-close the filed bugs
18:20:37 * mitr is A+1, B-1
18:20:44 <sgallagh> A+1, B+1
18:20:49 <nirik> A+1, B+1
18:20:52 <abadger1999> A+1, B+1
18:20:53 * mmaslano is A +1, B -1
18:21:11 <notting> A+1, B-1
18:21:22 <mattdm> A+0, B-1
18:21:51 <pjones> I'm not seeing how either of those addresses the problem that people have been told to do the wrong thing
18:21:52 <abadger1999> 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 <mattdm> (But I think some clarification should be added to all the existing bugs.)
18:22:21 <pjones> (I could be +1 to A though, I guess)
18:22:23 <sgallagh> pjones: Closing the bugs with "This was filed in error, please disregard" would be pretty clear
18:23:14 <abadger1999> anyhow --I think we have enough to pass asking hte reporter to file his Fedora Change for next week.
18:23:21 <mattdm> +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 <mitr> #accepted: Ask the Python 3 bug filers to file a Change by next week
18:23:53 <abadger1999> If we want to discuss fesco/reporter vs fpc comments the bug, we can do that after the regular agenda items.
18:24:06 <pjones> fair enough.
18:24:16 <mitr> Proposal B is at +3-4 now
18:24:22 <mitr> So let's move on for now
18:24:28 <mitr> #topic #1177 Codify how we are going to select the working group members
18:24:30 <mitr> .fesco 1177
18:24:31 <zodbot> mitr: #1177 (Codify how we are going to select the working group members) – FESCo - https://fedorahosted.org/fesco/ticket/1177
18:24:32 <mitr> https://fedorahosted.org/fesco/ticket/1177
18:25:03 <sgallagh> 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 <mattdm> So here, we are blessed with too much of a good thing. :)
18:25:29 <mitr> sgallagh: I don't like items 2 and 3
18:25:37 <mattdm> Honestly, I was worried that we wouldn't have enough serious volunteers to fill the groups
18:25:40 <mitr> re: 2, I'd rather be upfront with that this needs to work for Red Hat
18:26:02 <notting> 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 <mitr> 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 <sgallagh> mitr: Well, the proposal still allows for a Red Hat majority, just not a super-majority.
18:26:48 <sgallagh> I.e. five out of nine members.
18:27:08 <mattdm> I'm more worried about having representation from qa, releng, marketing, ambassadors than I am about having too many red hatters
18:27:42 <notting> 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 <pjones> 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 <mitr> 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 <abadger1999> pjones: +1
18:28:27 <nirik> could we have groups self select? or is that doomed?
18:28:38 <mattdm> 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 <nirik> 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 <mattdm> 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 <mattdm> unless i missed something
18:29:51 <pjones> mattdm: I suspect we actually want to solicit self-nominations and then have /fesco/ vote.
18:29:56 <mattdm> +1 sgallagh
18:30:07 <mattdm> pjones yes, that's what we said we'd do.
18:30:10 <nirik> well, we already did solicit them no?
18:30:33 <mattdm> the question is finding a process for narrowing down the lists to a practical working-group size
18:30:39 <pjones> 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 <sgallagh> Well, one of my suggestions was to have the members of each group of volunteers range-vote for the other members.
18:30:45 <abadger1999> 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 <mitr> 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 <nirik> so, have each fesco member come up with their list, cross match and ?
18:30:53 <sgallagh> If nothing else, it would give us a sense of the group's internal recommendations.
18:31:19 <pjones> sgallagh: we can't have them vote and then take the results as recommendations.  That'll just piss people off.
18:31:21 <mitr> Self-voting within a group doesn't necessarily work - one can sign up only to have a vote
18:31:26 <mattdm> 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 <mattdm> +1 pjones
18:31:36 <mattdm> +1 mitr
18:31:39 <nirik> 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 <abadger1999> 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 <pjones> abadger1999: sgallagh: what if we worry about doing a good job instead of political fallout ;)
18:32:35 <sgallagh> 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 <nirik> it's fesco seeded, new members added by FPC vote?
18:33:17 <nirik> (I think)
18:33:31 <mattdm> 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 <pjones> nirik: I *think* that's right
18:33:37 <abadger1999> 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 <mattdm> proposal: have the FESCo member responsible for each WG select the initial voting team in the same way
18:34:30 <nirik> voting team?
18:34:36 <pjones> The more serious issue is that we need to get the people who need to be involved to actually be involved.
18:34:38 <abadger1999> mattdm: +1
18:34:39 <mattdm> people with voting rights in the working group
18:34:40 <sgallagh> nirik: The nine-member Working Group that has a vote
18:34:43 <notting> doesn't that require a fesco member repsonsible for each WG?
18:34:52 <pjones> 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 <sgallagh> notting: We stated that as a requirement originally
18:34:56 <mattdm> notting we put that in the original proposal
18:35:03 <sgallagh> That each WG would have a FESCo representative
18:35:11 <nirik> ok, who are those? ;)
18:35:19 <nirik> pjones: +1
18:35:22 <sgallagh> Perhaps we should start there
18:35:33 <mattdm> pjones they're working on qa and marketing for the desktop product?
18:35:41 <mattdm> fedora isn't just code and packages
18:35:55 <mitr> mattdm: The desktop product that won't exist because nobody was involved in creating it?
18:36:00 <pjones> mattdm: that's fine and all, but it still produces a decision making body that can't implement the decisions.
18:36:19 <notting> 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 <mmaslano> sgallagh: do you suggest we should pick WG members and then pick FESCo members from those WG?
18:36:28 <notting> (as much fun as MRDs are)
18:36:32 <mattdm> right, we definitely want _some_ coders and packagers involved
18:36:56 <sgallagh> mmaslano: Other way around. One FESCo member should be an appointee
18:36:59 <pjones> 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 <mattdm> but I don't think the upstream projects will go away regardless of what we decide. we're not _that_ powerful.
18:37:16 <sgallagh> And responsible for relaying the working status back up to FESCo as a whole
18:37:52 <nirik> 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 <mattdm> pjones there is no shortage of engineers in any of the working groups
18:38:06 <nirik> https://fedoraproject.org/wiki/Fedora.next/WG_Nominations
18:38:07 <mattdm> nirik yes we should
18:38:24 <mattdm> ^ (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 <mattdm> +1 nirik
18:38:48 <pjones> nirik: ah, that list makes that a whole lot more clear.  okay.
18:38:50 <mattdm> also i just said that a little bit ago :)
18:38:52 <pjones> nirik: not sure how I missed it ;)
18:38:53 <nirik> but anyhow. How do we pick which fesco member is contact for each wg?
18:39:09 <notting> mattdm: if you consider QA engineer, then it's nothing *but* engineers, afaict
18:39:15 <sgallagh> nirik: Well, I'd start by seeing which groups have a single FESCo member volunteer.
18:39:20 <nirik> 5 groups 9 fesco members... anyone specifically NOT want to be a contact for any wg?
18:39:21 <notting> oh, and fearless leader rbergeron
18:39:25 <jwb> notting, and ryan
18:39:36 <mattdm> +1 jwb
18:39:46 <mattdm> or +1 rlerch as the case may be :)
18:39:46 * mitr is still planning to sign up for something FWIW
18:40:06 <notting> anyway...
18:40:19 <mattdm> 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 <mitr> (I do _not_ want the fun job of deciding which of the people will have a voting right)
18:40:34 <abadger1999> mitr: ah ha!  So you're the one to get the desktop WG ;-)
18:40:36 <nirik> cloud and workstation have 0 fesco membres?
18:40:46 <nirik> all others have more than 1
18:40:47 <sgallagh> Cloud should have mattdm ...
18:40:50 <nirik> (nominated)
18:40:52 <jwb> it doesn't
18:40:57 <mattdm> nirik yes how am i not on that list?
18:40:58 <notting> he's obviously slacking
18:41:02 <mattdm> 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 <mattdm> let's go ahead and assume i'm on that list :)
18:41:41 <mattdm> we do need someone for workstation.
18:41:45 <notting> server has 2, base design 2, stacks 3 (if i read it right)
18:41:55 <sgallagh> If no one else wants that hot-potato, I'll volunteer.
18:42:10 <sgallagh> I'm at least physically local to most of the Red Hat desktop folks, so that's useful.
18:42:48 <mattdm> sgallagh that is fine with me, although I kind of thought you'd be taking point on the server
18:43:03 <mattdm> but we've got nirik on there too
18:43:13 <pjones> We should note someplace that this ads items to the "so there's a new fesco" process.
18:43:14 <notting> 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 <pjones> Since I assume if any of our representatives leave fesco, that means we're swapping out who represents fesco.
18:43:55 <nirik> yeah
18:43:57 * abadger1999 notes nirik is in both base design and server atm too.
18:43:59 <Viking-Ice> 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 <sgallagh> mattdm: Server would be my first choice. (And probably the most obvious one)
18:44:01 <mattdm> pjones maybe... could be up to the individual governence of the group as set up in the future
18:44:17 <pjones> mattdm: I think we want fesco to have a persistent voice.
18:44:29 <pjones> (also I've got to go now.  Will check up on the tickets and log later.)
18:44:54 <abadger1999> Viking-Ice: It needs to be both.
18:45:06 <mattdm> Viking-Ice red hat could but it would be a huge loss
18:45:26 <mmaslano> mattdm: stacks my first choice, also obvious.
18:45:31 <mattdm> the comment about "must work for rh" is just a statement of reality
18:45:51 <mattdm> does anyone _other_ than sgallagh want to represent desktop?
18:46:29 <Viking-Ice> seriously be honest about what you are about doing
18:46:52 <mattdm> Viking-Ice I promise you I am being entirely honest.
18:47:01 <Viking-Ice> mattdm, when you have already decided the way forward what good is the communtiy
18:47:05 <nirik> back to nottings question, I thought the goal was 'a' desktop... but perhaps that could be decided by the group too.
18:47:06 <mattdm> and if I see anyone from Red Hat not being honest I will call them out
18:47:22 <mattdm> +1 nirik
18:47:54 <abadger1999> mattdm: was that a +1 for "a desktop" or for "decided by the group" ?
18:47:59 <notting> 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 <mattdm> +1 "a desktop"
18:48:11 <abadger1999> cool.
18:48:27 * abadger1999 was thinking exactly notting's thoughts if it was self-determined.
18:48:38 <nirik> notting: true
18:48:54 <Viking-Ice> 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 <notting> 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 <Viking-Ice> just pick the bloody people that align with the already decided vision and be done with it
18:49:14 <mitr> +1 "a desktop" (but honestly not interested in the details)
18:49:54 <mattdm> Viking-Ice because that's not what's happening? we can talk more later if you want.
18:49:56 <nirik> 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 <Viking-Ice> 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 <nirik> anyhow, so we want to assign contacts for workstation and cloud now, and others pending on discussions/more nominations?
18:52:13 <mitr> 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 <abadger1999> 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 <mitr> Viking-Ice: There's really not that kind of consenuss, although there is a definite ... tendency :)
18:53:05 <Viking-Ice> 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 <mitr> 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 <Viking-Ice> mitr, it's good that it has already been discussed and probably decided as well
18:54:54 <mitr> Viking-Ice: the FESCo/board discussions have been public
18:55:01 <nirik> sgallagh: which proposal?
18:55:05 <mitr> 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 <nirik> sorry, notting: which proposal?
18:55:17 <notting> nirik: the one in the ticket
18:55:26 <nirik> ah, ok.
18:55:31 <nirik> yeah, -1 for that as well here...
18:55:52 <sgallagh> notting: Yeah, like I said at the beginning, that was only meant to spark discussion
18:56:05 <mitr> I'm worried that I'll find it easy to -1 any proposal... what can actually work?
18:56:18 <notting> mattdm: were you going to seed a call for more reps from non-packagers?
18:56:19 <nirik> 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 <mattdm> 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 <abadger1999> s/initial 9/initial/
18:56:48 <nirik> (addon: fesco approves selections)
18:56:57 <notting> nirik: conflates groups, i think. there should be a voting body > initial members to select new members
18:57:01 <mattdm> those are basically the same :)
18:57:02 <mitr> mattdm: ... 0 (I can see it working well but I can't see how I would do it)
18:57:24 <nirik> notting: ok, how about contact proposes, fesco votes on?
18:58:04 <notting> 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 <sgallagh> nirik: I like that better
18:58:31 <mitr> 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 <nirik> 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 <abadger1999> notting: depends on ow much continuity you want... which in turn, depends on what the WG ends up being for....
18:59:16 <mitr> nirik: Yes, that's better
18:59:24 <notting> abadger1999: and around and around we go...
18:59:32 <mmaslano> I guess people will pick themselves, how many people will be interesting in meetings, writing proposal and so on...
18:59:58 <abadger1999> But yeah -- the products WG's?  I think those should have more emphasis on the group.
19:00:02 <notting> i do wonder how many people volunteered out of a sense of duty. i guess we'll find out!
19:00:18 <abadger1999> Not so sure about base design and environments and stacks.
19:01:09 <jreznik> mmaslano: +1
19:01:45 <abadger1999> those seem a bit more like the FPC where having continuity and building on what came before are important.
19:01:51 <notting> 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 <mattdm> +1 notting
19:02:08 <sgallagh> notting: +1
19:02:11 <nirik> sure, +1
19:02:14 <mitr> notting: +1, close enough
19:02:20 <abadger1999> notting: +1
19:02:34 <mmaslano> notting: probably best wording +1
19:02:52 <mitr> #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 <mitr> Do we want to do the assignment now?
19:03:44 <mitr> I'd rather wait until the end of the sign-up period
19:03:54 <notting> that seems reasonable
19:04:00 <notting> (which is when?)
19:04:08 <mmaslano> yeah, we could ask more QA, docs, marketing and others to join
19:04:11 <sgallagh> mitr: I'd at least like to sort out which of us are willing to volunteer for the Workstation product.
19:04:17 <mitr> notting: Oct 11
19:04:26 <mattdm> message says at least one month from when i sent it out two weeks ago.
19:04:45 <mattdm> because I thought that like four people would sign up total for some of them, i left it open
19:04:48 <nirik> so, perhaps we figure it on the 16th meeting?
19:05:32 <mitr> Sounds good
19:05:37 <abadger1999> Okay if I add October  16th to the wiki page as the noinations cut off?
19:06:16 <nirik> abadger1999: make it the 15th?
19:06:23 <sgallagh> Do we want to address the question of having people on more than one WG?
19:06:24 <mitr> 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 <nirik> yeah... some time before meeting would be nice.
19:06:51 <abadger1999> How about "the beginning of the FESCo meeting on October 16th"
19:07:19 <mmaslano> sgallagh: I guess they will drop. Who would attend so many meetings :)
19:07:34 <mmaslano> 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 <mitr> 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 <abadger1999> notting: We'll just put you in charge of unrelated WG's :-)
19:08:48 <mitr> Proposal: End nomination period on Oct 14 0:00 UTC
19:09:15 <mmaslano> mitr: +1
19:09:30 <notting> mitr: sure, +1
19:09:38 <sgallagh> mitr: +1
19:09:44 <abadger1999> mattdm: You should send an email about the end of nominations since the original email was open-ended.
19:09:47 <nirik> ok. +1
19:09:55 <abadger1999> wfm +1
19:09:56 <mattdm> abadger1999 yeah, i will
19:09:58 <nirik> (another email would be a good reminder to people too)
19:10:06 <mitr> #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 <mitr> mattdm: do you want to send the announcement, or shall I?
19:10:37 <mattdm> mitr if you could send that announcement that would be awesome
19:10:42 <mitr> mattdm: will do
19:10:51 <mattdm> i'll send some other messages to docs and qa and so on asking about interest
19:10:56 <notting> should we work on a procedure for proposing new WGs?
19:11:35 <mitr> 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 <mitr> 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 <abadger1999> notting: let's do that after the original WG's get off the ground.
19:12:13 <notting> mitr: i think it's sort of a requirement of having a desktop/workstation/whatever product, though
19:12:17 <jwb> mostly talk to FESCo
19:12:27 <mitr> sgallagh: do you want to propose a wording to vote on now?
19:12:28 <abadger1999> it'll probably prove informative watching them bootstrap as well.
19:12:46 <sgallagh> 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 <sgallagh> It'll let us know where they think they can do the most good.
19:13:26 <mitr> 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 <sgallagh> 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 <mitr> notting: Perhaps once we have an idea how / whether spins and products interact, that question will already be answered?
19:14:44 <mitr> 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 <mattdm> +1 sgallagh
19:15:21 <abadger1999> yeah, i'm okay with that wording.
19:15:35 <notting> 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 <mitr> notting: wait for the webmin on server dicussion  (wait, did I jinx it?)
19:16:19 <nirik> single worst spec I have ever seen in my life.
19:16:27 <notting> mitr: "openlmi or linuxconf? pistols at dawn."
19:16:35 <mitr> notting: right
19:16:41 <mitr> sgallagh: hm.  Not thrilled about it, but a reasonable thing to say, +1
19:16:50 <mitr> More votes on sgallagh's wording?
19:17:24 <notting> 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 <mitr> #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 <mitr> Anything else on WG member selection?
19:18:44 <mitr> notting: Do you want to talk about the new WG procedure now, or in a separate FESCo ticket?
19:19:11 <notting> mitr: if we've got other agenda items, it can wait
19:19:22 <sgallagh> 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 <mitr> sgallagh: sorry, not me
19:19:57 <mitr> Any other volunteers?
19:20:13 <mitr> notting: noted
19:20:15 <notting> i think my name is in too many places
19:21:03 <abadger1999> dibs on notting ;-)
19:21:44 * mitr reads thas as "no volunteers", moving on
19:21:49 <mitr> #topic #1178 Fedora 21 scheduling strategy
19:21:52 <mitr> .fesco 1178
19:21:53 <zodbot> mitr: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178
19:21:54 <mitr> https://fedorahosted.org/fesco/ticket/1178
19:23:18 <mitr> jreznik's proposals:
19:23:20 <mitr> 1) continue F21 using the current process, use WG output only for F22+
19:23:22 <mitr> 2) ask for specific proposals what to delay F21 for, using the Change process
19:24:09 <mattdm> I hate to be slow, but the flock scheduling point is compelling
19:24:19 <drago01_> (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 <abadger1999> note, releng groaned very loudly at the prospect of another short cycle.
19:24:34 <notting> mattdm: when is next flock?
19:24:40 <tflink> qa isn't thrilled about the prospect, either
19:24:48 <mitr> 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 <mattdm> notting tbd, but the funding isn't there until march
19:24:52 <jreznik> well it does not have to be shorter one
19:24:54 <jwb> notting, it's up for bids right now.  no set time
19:24:59 <mattdm> and that includes buying plane tickets
19:25:09 <mattdm> if it were up to me I'd have it in january
19:25:09 <notting> mattdm: so, 'after march', ok.
19:25:12 <mattdm> in the bahamas
19:25:35 <jreznik> expect more july+
19:25:44 <notting> mitr: i think QA and releng are the things *most likely to need more engineering time*
19:25:48 <abadger1999> mattdm: or July in Fairbanks?
19:25:58 <mitr> notting: yet they didn't ask for any specific amount IIRC
19:26:10 <mmaslano> mitr: I agree, let's start to working on it
19:26:18 <mitr> 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 <mattdm> maybe we could have a Fedora Activity Day to work on qa and releng automation plans?
19:26:40 <notting> <throws on releng hat> <requests longer cycle to improve tooling to compose products cleanly> </throws off releng hat>
19:26:40 <mattdm> +1 mitr
19:26:40 <mitr> notting: Hence the proposal for assuming the current cycle, and just seeing how much slipping is necessary
19:26:42 <sgallagh> I don't think we want two shortened cycles in a row, FWIW.
19:27:02 <tflink> mitr: didn't realize that we were supposed to have submitted proposals already
19:27:12 <jreznik> sgallagh: it does not have to be shorter one...
19:27:29 <nirik> 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 <mitr> 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 <jreznik> 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 <tflink> there are only so many hours in a day - I just got started working on stuff for qa automation
19:28:35 <jreznik> 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 <tflink> which is true for everyone, I know
19:28:42 <nirik> 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 <mitr> jreznik: right; everyone has years of backlog but that alone is not automatically a reason to slow down
19:29:19 <jreznik> nirik: but then - do you want month, three, six, ten?
19:29:25 <mattdm> jreznik dgilmore also had a list of things
19:29:29 <drago01_> 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 <mattdm> which i'm sure he could flesh out if he had more time.
19:29:51 <jreznik> mattdm: that's why I say - let's try to collect it
19:29:57 <nirik> drago01_: so we should do nothing, and no bugs?
19:30:10 * nirik kids
19:30:26 <jreznik> in more formal way and we can say then - x months is what we want, not blindly guessing
19:30:37 <drago01_> nirik: no because we already have bugs ;)
19:30:37 <mattdm> is having a FAD for planning the automation and other paydown-of-tech-debt projects something we could reasonably do?
19:30:42 <mitr> 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 <nirik> I'd need to know: are we delivering our current deliverables for f21? or 'new, TBD' ones?
19:31:08 <tflink> mitr: sure, I'm not saying that we shouldn't have to make more specific proposals
19:31:24 <mitr> mattdm: Would that help?  The last day of Flock was supposed to be where these things get implemented IIRC and... didnt?
19:31:25 <tflink> saying "we need X months for ... stuff" isn't going to end well
19:31:26 <jwb> mattdm, wtf does 'paydown-of-tech-debt' mean?
19:31:38 <notting> mattdm: i would be all for that
19:31:45 <notting> mattdm: automate-all-the-things FAD
19:31:47 <tflink> jwb: for qa, actually making progress on automation
19:31:56 <nirik> if we can come up with goals specific enough for FADs sure.
19:32:00 <mitr> That is FAD for Fedora Activity Decade?
19:32:06 <mattdm> 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 <tflink> autoqa has been getting along on bandaids since ~ f17
19:32:12 <jreznik> 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 <jwb> mattdm, hella-buzzwordy.
19:33:10 <nirik> 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 <jreznik> nirik: the nice and sweet next fedora? :)
19:34:13 <jreznik> we can also put releases on hold until we define a new strategy...
19:34:32 <drago01_> jreznik: ugh
19:34:36 <tflink> jreznik: that seems a bit risky to me without a more firm deadline
19:34:42 <nirik> 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 <drago01_> jreznik: that's asking our users "go elsewhere"
19:34:47 <mitr> jreznik: That's supposed to be a threat?:)
19:35:24 <mitr> nirik: Right, there seems to be no strong case for making f21 _short_.
19:35:31 <jreznik> nirik: I'm more inclined to normal release too
19:35:48 <nirik> well, one thing that was mentioned was realignment with gnome upstream releases.
19:36:03 <mattdm> 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 <mattdm> Can we do a _regular_ f21 cycle and still make room for some automation work?
19:37:27 <nirik> 'march 2014' I guess
19:37:47 <jwb> nirik, 3.12 kernel?
19:37:52 <jwb> nov...
19:37:58 <nirik> no, gnome. ;)
19:38:04 <jwb> oh.  version collision
19:38:06 <nirik> yep.
19:38:08 <nirik> sorry
19:38:11 <drago01_> nirik: yeah end of march 2014 should be about right
19:38:12 <mattdm> 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 <tflink> 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 <tflink> s/going to/hopefully going to
19:38:46 <mattdm> and I guess it's okay for the products to more slowly diverge rather than sharply branch
19:39:15 <mitr> 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 <mmaslano> 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 <jreznik> 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 <mitr> 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 <mmaslano> let's vote on this one ^
19:42:31 <abadger1999> 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 <jreznik> abadger1999: yep
19:42:45 <nirik> I'm not sure how practical that will be.
19:43:11 * nirik ponders
19:43:14 <tflink> that sounds like a nightmare to me
19:43:33 <mattdm> tflink -- you'd still like the longer cycle?
19:43:34 <jreznik> why?
19:43:54 <jwb> is there any scenario where fedora ships 3 products that doesn't sound like a nightmare to you?
19:43:57 <tflink> jreznik: 3 times the things to test with our current processes?
19:44:00 <mitr> tflink: why?  There's already the cloud and desktop spin and the DVD image, is there even extra work?
19:44:14 <jreznik> tflink: it's exactly what we have now, just one more server image
19:44:21 <mattdm> that is the definition of extra work :)
19:44:33 <jwb> one more straw, etc
19:44:55 <mattdm> we really need to get tim et all the time and resources to improve the processes
19:45:01 <mattdm> i'm for whatever does that best
19:45:06 <tflink> jwb: there are ways to do it that don't sound like a nightmare to me
19:45:07 <mitr> jreznik: I sthat even "one more" or replacing the DVD?
19:45:22 <jwb> tflink, great!  be verbose about them and tell FESCo
19:45:32 <jwb> because THAT IS WHAT THEY ARE TRYING TO FIGURE OUT
19:46:01 <notting> i am all for launching the dvd image into the sun
19:46:09 <tflink> the biggest thing that doesn't scale is the amount of manual testing we do
19:46:17 <kalev> 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 <kalev> 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 <tflink> if we can get some/most of that automated, qa is going to scale much better to multiple products
19:46:32 <kalev> a bit shorter to make up the time lost in F20 slips + two additional weeks cut off, perhaps
19:46:48 <mitr> 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 <Viking-Ice> 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 <abadger1999> kalev: I think another schedule the same as f20 would burn out releng.
19:47:31 <jreznik> 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 <tflink> 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 <mitr> tflink: Right, that comment was more targeted on other areas...
19:48:30 <notting> kalev: i assume you mean may/nov, btw
19:48:38 <kalev> ah yes
19:48:42 <abadger1999> 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 <kalev> 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 <Viking-Ice> 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 <Viking-Ice> that would allow QA to focus on 3 or more products
19:49:58 <Viking-Ice> and probably for the working group to work out what those products are
19:50:26 <Viking-Ice> 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 <jreznik> 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 <notting> 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 <tflink> 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 <abadger1999> jreznik: well.... depends on base design... workstation could end up syncing to two upstreams (gnome and fedora-code)
19:51:57 <mitr> jreznik: non-synced releases seem like  a world of pain
19:52:42 <mattdm> 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 <jwb> tflink, sounds reasonable.  so, from a timeframe standpoint, is there an estimate of how long that would take, etc?
19:52:51 <jreznik> mattdm: +1
19:53:01 <kalev> 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 <mattdm> jreznik +1 to we'll all be old and grey by then, or +1 to that schedule
19:53:15 <notting> mattdm: i'd rather push f21 later and split that
19:53:22 <tflink> jwb: just got started working on it - have been busy putting out fires
19:53:41 <jwb> tflink, ok.  well, that's the kind of info FESCo is asking for
19:53:48 <tflink> i know
19:53:52 <abadger1999> 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 <nirik> kalev: I don't think server folks would like that... but I suppose it could be discussed.
19:54:17 <abadger1999> mattdm: Maybe we do that for f21. rather than the "perfect plan" that hte wg's come up with.
19:55:06 <notting> if we already have a plan, why do we have WGs?
19:55:11 <mattdm> 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 <tflink> 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 <mitr> Also, doing the automation and cleanups in the non-product world and changing immediately afterwards seems like a waste
19:55:29 <abadger1999> notting: I don't know -- do we have a plan?  Do we need WG's?
19:55:59 <tflink> jwb: I'm getting stuff put together but it's not going to happen today
19:56:01 <abadger1999> jreznik: seems to have an idea of how to release three products.
19:56:04 <tflink> the plan, I mean
19:56:38 <mattdm> tflink yes please!
19:56:53 <abadger1999> 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 <mitr> 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 <mattdm> 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 <abadger1999> <nod>
19:57:52 * nirik would like to get input here from dgilmore. Another week is likely good.
19:58:02 <jreznik> 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 <abadger1999> 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 <mitr> proposal: defer for a week
19:58:46 <abadger1999> I think I'm +1 to a delayed f21.  Just need to work out how long to delay for next week.
19:59:20 <notting> mitr: yes, +1
19:59:22 <jreznik> abadger1999: and what we want to achieve...
19:59:22 <mattdm> +1 mitr let's get more info
19:59:28 <nirik> +1
19:59:30 <mmaslano> +1
19:59:43 <jreznik> so that's more like my option 2) call for proposals
19:59:46 <mitr> #agreed defer for a week, pending input from tflink and dgilmore
19:59:52 <sgallagh> mitr: +1
19:59:53 <jwb> you guys are kind of boxing yourselves in here.
19:59:56 <jreznik> you could say that in the beginning :)
19:59:58 <jwb> it's not "delayed f21"
20:00:19 <jwb> if f21 is fedora.next, it cannot possibly be delayed because it's fscking NEW
20:00:26 <mattdm> jwb +1000000
20:00:32 * nirik nods.
20:00:57 <jreznik> jwb: that's the question nobody answered - will be f21 fedora.next already? :)
20:01:03 <Viking-Ice> why just wait for them?
20:01:11 <mitr> #topic #1179 Interactions of the various Products
20:01:13 <mitr> .fesco 1179
20:01:14 <zodbot> mitr: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179
20:01:15 <mitr> https://fedorahosted.org/fesco/ticket/1179
20:01:15 <abadger1999> 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 <jreznik> abadger1999: yep, see above :)))
20:01:51 <mitr> So, https://fedoraproject.org/wiki/Fedora.next/ProductInteractions is... exploring the future
20:01:58 <jwb> 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 <mitr> Do we even want to make this kind of decisions?
20:02:05 <notting> 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 <nirik> mitr: I must say I found the wiki page very confusing. ;) what are we trying to solve here?
20:02:24 <jwb> notting, sure.  whatever it takes to get over the mental hurdle
20:02:29 <jwb> but damn people
20:02:32 <mitr> 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 <nirik> ok... then lets do? :)
20:03:21 <abadger1999> notting: I like your criteria for separation ;-)
20:03:33 <notting> 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 <mmaslano> mitr: it's a good start
20:03:51 <Viking-Ice> looks like this request is a bit premature
20:03:55 <mitr> notting: the minimum, or
20:04:21 <mitr> what FESCo wants from the WGs.  Do we even want anything?
20:04:23 <jreznik> 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 <jwb> sure
20:05:24 <drago01_> mitr: fwiw imo your draft is to much focused on the cloud
20:05:45 <nirik> 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 <mattdm> 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 <mitr> 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 <sgallagh> 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 <jreznik> with constrained resources, we would require as much coordination and I really hope people will realize it :)
20:06:54 <nirik> 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 <sgallagh> nirik: I meant December and most of January, really.
20:07:25 <nirik> mitr: IMHO, they should work out these things and come to fesco if agreement can't be reached.
20:07:27 <sgallagh> 'next' was wrong
20:07:28 <mitr> 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 <drago01_> 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 <sgallagh> mitr: I'm not necesarily talking about feature-based release
20:08:05 <mitr> sgallagh: Then we can decide on a provisional schedule already
20:08:08 <kalev> 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 <sgallagh> Historically, Fedora N final freeze == Fedora N+1 kickoff
20:08:31 <sgallagh> I'm suggesting that we put a gap here where the WGs can do their jobs
20:08:33 <jreznik> kalev: but we don't do it for a few releases, we do something in between
20:08:53 <sgallagh> And then build a schedule starting from the report-in date
20:08:54 <mitr> 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 <jreznik> sgallagh: even earlier
20:10:34 <mmaslano> guys, we said defer, so what are we trying to solve now?
20:10:42 <mmaslano> does anyone another proposal?
20:11:02 <notting> proposal : we do not necessarily need to define these interactions yet
20:11:09 <nirik> +1
20:11:12 <abadger1999> notting: +1
20:11:24 <mmaslano> notting: +1
20:11:48 <mitr> notting: works for me; then I'll ask whether that means "repropose to FESCo later", "repropose to WGs" or something else
20:12:41 <notting> mitr: hm.... wait for the WGs to start checking in, see if there are obvious conflicts?
20:13:01 <mattdm> notting +1
20:13:17 <mitr> 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 <mitr> mattdm: was the +1 to notting's proposal or the later comment?
20:14:04 <mattdm> proposal
20:14:07 <mitr> #agreed we do not necessarily need to define these interactions yet (+5)
20:14:24 <mitr> #topic Next week's chair
20:14:29 <mitr> Any volunteer?
20:14:39 * nirik will very likely not be at next weeks meeting.
20:14:44 <abadger1999> mitr: I guess I don't see how the present page is going to help with the interactions.
20:15:43 <mitr> 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 <abadger1999> 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 <mmaslano> mitr: I'll take the chair if you close the meeting. Deal?
20:18:11 <sgallagh> :)
20:18:19 <abadger1999> 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 <mitr> mmaslano: works for me ... we are way over 0x80 minutes.  Objections?  Any urgent items for open floor?
20:18:32 <mitr> abadger1999: Then what does base design do?
20:18:42 <abadger1999> base design defines the base fedora platform.
20:19:05 <abadger1999> what is in the base fedora platform.  how long is a base fedora platform maintained.
20:19:07 <mitr> That doesn't say anything specific to me
20:19:31 <mitr> Seeing no urgent items and objections...
20:19:38 <mitr> #action mmaslano to chair the next meeting
20:19:42 <mitr> Thanks enveryone!
20:19:49 <mitr> #endmeeting