16:02:30 #startmeeting Server Working Group Weekly Meeting 16:02:30 Meeting started Tue Nov 5 16:02:30 2013 UTC. The chair is mizmo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:30 * sgallagh is lurking while on a conference call 16:02:39 #topic roll call 16:02:43 Hello 16:02:44 who is here :) 16:02:47 .fas tuanta 16:02:47 tuanta: tuanta 'Truong Anh Tuan' 16:02:52 I'm semi-here (on another call) 16:03:16 morning everyone 16:03:31 I'm at LISA13 currently so my ability to be here is limited by hotel wireless 16:03:38 Viking-Ice? 16:03:45 davidstrauss? 16:04:08 .hellomynameis kevin 16:04:10 nirik: kevin 'Kevin Fenzi' 16:04:17 mizmo: davidstrauss is presently in Australia where it is 2am. He may not be around for the next couple meetings 16:04:22 ah ok 16:04:22 * nirik tries to get more people to use that for meetings. ;) 16:04:35 .hellomynameis sgallagh 16:04:37 sgallagh: sgallagh 'Stephen Gallagher' 16:04:37 how about Viking-Ice? we kind of need him i think given the topics 16:04:55 I'm here 16:05:01 okay great 16:05:01 cool 16:05:11 #topic agenda 16:05:37 okay so here is the thread on today's agenda 16:05:38 #link https://lists.fedoraproject.org/pipermail/server/2013-November/000425.html 16:05:58 so the suggested agenda items are: 16:06:02 - finalizing the governance charter 16:06:16 - is fedora server one product? 16:06:37 - Viking-Ice suggested 'Pick the first server application that will make the transition to an "product"' 16:06:48 - I had also suggested use cases and personas but i think that depends on the 2nd item 16:06:50 sound good? 16:06:56 yep 16:06:58 #topic Finalizing the Governance Charter 16:07:01 yeah 16:07:13 #link https://fedoraproject.org/wiki/Server/Governance_Charter 16:07:18 so, did we work out issues on that one section on list? 16:07:24 ubs 16:07:52 nirik, so if I understand correctly - i may be wrong though - we resolved the issue of requiring some specific type of experience or pre-reqs to 'prove' a sufficient background in working with servers 16:08:09 but i dont think we resolved the issue of how many / which sigs to be represented by specific seats? 16:08:11 but im not sure 16:08:35 yeah, so we amend that section to say that when someone leaves their replacement is appointed from the pool of active folks in the group? 16:08:37 there seemed to be a lot of concern about having chairs represent specific sigs/ other teams in fedora last meeting, i didn't see that resolved on list 16:08:59 .hellomynameis kdetony 16:09:00 kde_tony: kdetony 'Anthony Mogrovejo' 16:09:06 Seems to me that way as well. I'd still prefer not having reserved seats; we can set up liasons when/as much as necessary 16:09:20 well if we are going to be applying prd to products we kinda need people from sig not liasons 16:09:20 (that way re: resolved/unresolved issues) 16:09:33 i feel the same mitr 16:10:03 Viking-Ice: how so? 16:10:17 nirik, have you looked at the construct of prd's ? 16:10:41 * nirik agrees that involvement from many parts of the project is vital, but not sure that each group needs a voting seat... 16:10:58 sure. 16:11:04 the difference I see between liasons and reserved seat is that the seat apply responsability the liasons is "best effort" getting things done 16:12:04 Viking-Ice, so you are worried if the seats are just liasions with the other groups and not members of the other groups, that the work we need those other groups to do won't necessarily get done 16:12:06 The difference I see is that some groups may not want the time/involvement that a voting seat would be... they just want to know/help where it affects their main focus 16:12:14 mizmo, right 16:12:20 that's my only concern 16:13:04 if someone was wanting to be involved to the level of a voting seat (and meetings and active on list, etc) then they are a active part of the workgroup and could be given a voting seat. 16:13:08 Viking-Ice, would you consider maybe dropping the seat<=>sig association and as an alternative we could talk about how we handle things when we are relying on another group and the work isn't happening? 16:13:24 Viking-Ice: I'm equally concerned about the development side - the 9 of us can only contribute so much work. 16:13:31 Viking-Ice, whether or not work gets done that is needed to get done and handling that seems like a separate governance issue doesn't it 16:13:55 mitr, I'm not so sure how much of an actual development site we be involved with 16:14:35 Viking-Ice: Exactly; the success of the WG is in any case strongly dependent on persuading other people that the vision is worthwhile 16:14:42 mizmo, I'm fine with dropping that requirement but note this that the cloud community they themselves could not deliver enough QA for alpha 16:14:51 for their images 16:15:30 hopefully we can do better. ;) 16:15:31 mitr, the missing requirements speak for themselves ( like your common configuration api suggestion ) 16:15:49 nirik, we have more "products" 16:15:59 in the long run that is 16:16:04 Viking-Ice: yep. 16:16:04 Viking-Ice, like design and usability, QA is one of those things where there isn't enough time / resources to do right usually :( 16:16:46 Viking-Ice, do you have other ideas besides having group-specific seats to try to help the problem of things getting done? 16:16:58 mizmo, with my QA hat on QA should only focus on the core/baseOS and the installer the rest be left to the relevant sub community and most likely it will head that way with the working groups 16:17:07 one more item on the gov document to bring up: currently we have it so turnover only happens if someone steps down from a voting seat. Do we want any term limits or other ways to keep a flow of fresh blood into the voting group? 16:17:36 do we need fresh blood ones we have nailed the process down 16:17:39 I dont think so 16:17:52 nirik, oh great point 16:17:57 well, it could make things get set and fail to change for new stuff. 16:18:20 Viking-Ice, so the server wouldn't be QAed by Fedora QA? 16:18:22 I'm not sure about term limits, but maybe a 6 month seat vote? 16:19:15 mizmo, nope not directly no 16:19:16 Evolution: so revote for everyones seats every 6 months? or ? 16:19:17 I'll reiterate that I don't think having indefinite terms is healthy, although this seems to be a minority opinion among the WGs 16:19:42 mizmo, if QA have not got enough resources, I think we need other resources inside Server WG 16:19:43 mitr: I share that concern... 16:19:43 I personally dont see the need for the WG once the process is set 16:19:44 mitr, im in agreement with you 16:20:06 tuanta, irrelevant with resources QA should not be doing that stuff 16:20:12 OTOH having a 6-month election term with a 18-month production cycle would also be interesting... 16:20:19 Viking-Ice: there's going to be likely some longer term items that can't be "set" quickly, IMHO. 16:20:24 so should we keep talking about the membership / seats per group issue, or are we resolved and we'll drop the group membership requirement and talk about term limits? 16:20:53 and unless we alter anaconda's release cycle QA wont be handling more the one product anyway 16:20:56 Viking-Ice, to be fair the fedora packaging committee still exists and meets regularly right? and their initial policies etc. were long ago worked out 16:20:58 mizmo: (thanks for keeping us working in order) 16:21:17 * nirik is +1 to dropping the group mappings section thing, possibly with a note that we would love involvement from any parts of the project. 16:21:26 +1 to nirik 16:21:48 mizmo, to be fair FPC adds unnecessary burden to community workflows 16:22:01 nirik: +1 16:22:15 anyone else in support of dropping group mappings, with a note saying we'd love involvement from any parts of the project? 16:22:34 we can always revisit so +1 16:22:40 +1 too 16:23:06 thats 5 I think. 16:23:11 that's enough? 16:23:22 okay :) 16:23:41 #agreed In the governance charter, we will drop group mappings, with a note saying we'd love involvement from any parts of the project. 16:23:49 okay now back to term limit discussion 16:23:51 ill change topic too 16:23:58 #topic Finalizing the Governance Charter: Term Limits 16:24:25 so it seems like we have two schools of thought / proposals thus far? 16:24:49 Viking-Ice, you support not having term limits / votes because you believe the group should dissolve after our deliverable (PRD) is finished? 16:25:19 mizmo, after the process has been delivered yes 16:25:23 Evolution and mitr, it seems like you support term limits and potentially 6-month election terms 16:25:31 mizmo, we are not dealing with single product 16:25:50 not term limits, but votes to make sure that people are still doing the right thing 16:26:02 I think there will be ongoing work for this group for a long time... 16:26:04 mizmo: limited terms, not limits on total time serving. Not sure about 6 months 16:26:21 right, because 6 months might not work with an 18 month production cycle 16:26:24 as you pointed out 16:26:26 no election it would be better to simply have members confirm the continues participation in the server WG every 3 or 6 months 16:26:52 it 16:27:11 far more efficient 16:27:12 it is also not easy to organize an election 16:27:23 Viking-Ice: I'd almost say that the actual work _starts_ after the PRD, although the nature of it will change (coordination, prioritization of the "next service", choosing software used to implement the PRD) 16:27:51 Viking-Ice, how do you see 'not dealing with a single product' indicating that the working group needs to dissolve after the PRD/process are defined? 16:28:08 mitr, true but you dont need a WG for that strictly speaking other then to follow the tasks listed in the PRD through 16:28:26 tuanta, what if it was an informal election in IRC between the current WG members and server community members? 16:28:40 tuanta, e.g., on the fedora design team we've had elections informally like this and it's worked pretty well and efficiently 16:28:44 mitr: also, adding new products, dropping old ones, figuring new ways to integrate them, etc 16:28:45 mizmo, you said "our deliverable (PRD) is finished" singular not plural 16:28:49 we've done it over the mailing list too 16:28:52 mizmo: it would be a good idea 16:29:12 Viking-Ice, I think we disagree on whether or not there is a single or multiple PRDs so how about i try to say PRD(s) from now on? :) fiar? 16:29:16 er fair even 16:29:24 mizmo, yeah 16:30:14 tuanta, okay so maybe when we say there should be votes for the WG membership, we're not implicitly saying Fedora-wide and we're not implicitly saying using the Fedora election app 16:30:16 nirik, which product get's choisen or dropped is left up for the entire server community to decide ( with the exception of the first three or so maybe to get the process nailed down ) 16:30:24 Viking-Ice: I don't think people just following PRD can work. E.g. choosing between puppet/ansible/$many_other_alternatives needs to and up with a definite decision. 16:30:43 Viking-Ice: we are that decision making body? 16:31:00 nirik, for the first products not all products 16:31:05 mizmo: I'm not tied to the Fedora election app, but (from the outside) it seems that it's easier to use that app than to manually count votes, and the confidentiality is a significant benefit 16:31:32 Viking-Ice: well, for the products we decide that the Fedora Server group is going to ship sure. 16:31:39 mitr, yeh i agree. limiting voting population and using the fedora election app is a great option 16:31:47 * nirik would really prefer to avoid the elections app personally. 16:31:49 seriously no need to vote that's unnecessary burden just have people confirm their continuing participation on a meeting every 3 or 6 months 16:32:23 well, what specific concerns do folks have with Viking-Ice's proposal of 3-6 month confirmation of participation? 16:32:24 nirik, as I see just the first product 16:32:31 mean products 16:33:10 mizmo / Viking-Ice: so that would be every 6 months the members of the group say that they still wish to be involved, or would like to step down? or is there more to it? 16:33:11 mizmo: The WG confirming itself is not an effective mechanism for replacing a dysfunctional WG. (I know we are all perfect and this is purely theoretical :) ) 16:33:51 Viking-Ice, so what do you say to the concern that if we got out of whack / dysfunctional, your proposal of periodic confirmation wouldn't work? 16:33:57 nirik, just the step down process to that as in he would name a successor or we advertice and choose 16:34:42 mizmo, use the same approach as you propose we cross that bridge when we get there 16:35:03 and if things are that dysfunctional we just ping fesco and they decide 16:35:03 well, naming successor isn't too great... but we choose one from the active folks would be ok... 16:35:13 Viking-Ice, my concern with that, is that if we've gotten to the point where we're dysfunctional, we might not be able to cross the bridge without people getting pushed off the bridge along the way... :) 16:35:23 again FESCO 16:35:41 or CWG 16:35:43 is FESCo open to this level of management of the working groups? 16:35:50 I don't think the CWG really exists anymore Viking-Ice :( 16:35:54 dunno, they might be I suppose. 16:36:14 CWG exists, I am sure 16:36:16 they are committed to choosing a liasion to fesco from each group... 16:36:20 well, that could be a workable resolution i guess 16:36:29 mizmo, I would think so they reserved the authority to step in WG's so yes I would say it works in both ways 16:37:07 Viking-Ice, I have a separate concern with your proposal about periodic membership confirmation. I'm worried about stagnation - usually the energy of new members coming on board regularly helps jump start people's enthusiasm at the regular intervals of election. it doesn't seem like this would be guaranteed in your proposal. 16:37:31 Viking-Ice, do you have ideas on how to account for this in your proposal? 16:37:37 mizmo, look at fesco same people for the last decate more or less 16:37:55 fresh ideas killed instantly by the few fresh members that make it there so.. 16:38:19 off the wall idea: every 6 months we randomly choose 3 members to replace (would also need at least 3 more active folks in the group to replace them with) 16:38:47 how randomly would that be chosen? 16:39:06 Viking-Ice: like redesigning things with 3 new products and revamping everything about how we do releases? ;) 16:39:24 random number from 0 - 9 ? 16:39:26 Viking-Ice, bzflag tournament 16:39:30 ha. 16:39:38 but that wouldn't be random, i suck at it 16:39:43 nirik, that process could be applied to 3 new products while the other already released products remain the same 16:40:07 Viking-Ice: I'm just providing a counter example for your 'all fresh ideas are killed instantly' 16:40:17 but as I see it the entire server community should be the one that select products ones the process is ready 16:40:54 so, perhaps we punt this to the list again for next week? we have 10 days left for the deadline on governance. 16:40:59 that's how you would ensure fresh ideas and participation ( as in by limiting the server wg direct involvement ) 16:41:11 nirik, on a serious note, we could just ask for people to volunteer to step down 16:41:13 I think the governess is ready enough 16:41:16 rather than randomization 16:41:41 Viking-Ice, i don't know that we're all in agreement though, although the member refresh issue seems to be the last one before we can approve the governance 16:42:11 Viking-Ice, but if you believe the group will dissolve relatively short-term anyway, does the voting proposal make a difference to you? 16:42:14 * nirik isn't sure fesco will like the possible no turnover part, but we could submit it to them and see what they say I suppose. 16:42:44 nirik: There's at least one other group with such a proposal already 16:43:55 I'm not coming up with too many great ideas there... and it might depend on: a) how long we exist, b) how many non voting active people their are in 6 months, c) if we need more fresh voting members or if as Viking-Ice notes the active people in the community would be enough for that. 16:44:15 As much as I hate delaying administrativia, perhaps we should delay the turnover part to have more conversations about the lifetime? 16:44:17 Actually... _if_ we are agreed that we should have some kind of turnover mechanism, then delaying might make sense; if we don't have an enforced turnover, then let's just close it now. 16:44:40 so proposal "periodic membership confirmation every 6 months on a weekly meeting at that time with the individuals chosen from the active folks within the server community by the active server wg if an member of the server wg choose to step down" 16:44:57 chooses to step down I mean 16:45:09 Viking-Ice: I can be +1 to that... and we can revisit if we need a better turnover setup. 16:45:18 yep that can always be done 16:45:28 same 16:46:22 It is fine enough at this time. I think. So +1 for this 16:46:27 i do think we need a turnover mechanism, but i agree with nirik that it's kind of hard to know how to set that up without seeing how active the community membership is and how long we intend to exist 16:46:56 we could even say: will revisit in 6 months? 16:47:02 i'd prefer that actually 16:47:09 16:47:13 +1 to revisit in 6 months 16:47:24 +1 nirik 16:47:27 -1 to revisit let's just get this over with 16:47:31 Note that the two are effectively equivalent :) 16:47:40 mitr, yes but revisit is more neutral :) 16:48:06 well, I was thinking both... we do what Viking-Ice proposed now, but make a note to revisit it in 6months. 16:48:09 mitr, one is delay handling this the other one is not 16:48:14 (not as a formal part of the gov doc) 16:48:37 doesn't matter, lets just pass the proposal from Viking-Ice now? 16:48:38 nirik, I took it as you wanted to postpone the gov stuff for 6 months 16:48:47 Assuming you see the two as equivalent, I think we're at +5 16:48:53 no, that wasn't what I meant. 16:49:01 sorry if I was unclear there. :0 16:49:09 i'll +1 to vote to get this over with and move on :) 16:49:11 Viking-Ice: We always have the option to revisit, or to revisit and not make a change. 16:49:18 +1 to 'both' i mean 16:49:19 I would assume we would always revisit the process at confirmation time 16:49:28 right, so with that change the gov doc is ready for fesco? anything else on it? 16:49:35 I think I'll +1 to both as well so that we move on... 16:49:56 looks like we have 4, any takers to +1 to both so we have 5 16:50:07 I obviously +1 to both ( since I made the assumption it would naturally occuring ) 16:50:09 Evolution? tuanta? 16:50:12 One more thing - is voting required to have 5 +1 votes, or 5 voting memberes and a majority (i.e. 3 votes in the worst case)? 16:50:23 +1 already 16:50:42 mitr, i think we'd said 5 was quorum initially 16:50:49 mitr, whether or not everyone is present 16:50:51 mitr: +5 I assumed... or if we use 'lazy consensus' no -1's? ;) 16:51:42 no votes from sgallagh and davidstrauss ? 16:51:49 #agreed We'll add a section to the governance charter setting 6-month membership confirmation periods, but we will also revisit that decision in 6 months time based on the community activity, how long we intend to exist, etc. 16:51:58 I prefer requiring +5 votes as well, but that's not the dictionary tells me "quorum" means and Jóhann's proposal says "quorum" 16:52:07 ... not what the dictionary ... 16:52:24 mitr, "the number of members of a group or organization required to be present to transact business legally, usually a majority. " 16:52:33 ohh i see 16:52:43 you're saying it's people not votes 16:52:44 Viking-Ice, davidstrauss could not be attend I think. It is almost 300am at his side now 16:52:58 ah 16:52:59 mizmo: yes. 16:53:43 heh thats an interesting quandry 16:53:45 Arguably +3 is more consistent with the "lazy consensus" model, but then I don't like that one very much, hence my preference for +5 - but decide as you like, just make it extraordinarily clear. 16:54:02 my preference is +5 just because that's the majority of the group in total 16:54:18 does anybody have issues with requiring +5? 16:54:31 well my take was as nirik put it "+5 I assumed... or if we use 'lazy consensus' no -1's? ;)" 16:54:33 I'm tied up in another meeting. I'll read the backlog in a few minutes when it ends. 16:54:37 I also prefer +5, but we should try and just reach consensus most of the time and not do formal voting 16:54:46 Sorry; this is a one-time high-urgency conflict. 16:55:01 * nirik notes we have 5min left to the top of the hour 16:55:22 yes 16:55:34 yes 16:55:39 sorry. hotel wireless is killing me 16:55:51 tuanta, Evolution - yes to +5 being the requirement? 16:55:58 yes. 16:56:00 +5 is fine 16:56:31 #agreed 'Quorum' for our purposes is at least 5 '+1' votes, and is not proportional to the number of members attending the meeting where the vote takes place. 16:56:35 Can we get the current proposal we're voting on restated for me? 16:56:40 sgallagh, ^^ :) 16:57:13 mizmo: +1 16:57:16 mizmo: s/Quorum/number of votes to pass/ , just because I can't resist being a pain 16:58:10 #agreed (revision) The number of votes required to pass a vote is at least 5 '+1' votes, and is not proportional to the number of members attending the meeting where the vote takes place. 16:58:13 :) 16:58:28 thanks 16:58:47 okay i guess we don't have time for other agenda items 16:59:06 you must be joking 16:59:15 but, do we consider the governance charter finalized at this point? I can make the edits based on what we agreed on today? 16:59:38 I would say so 16:59:40 sure, edit and submit to fesco as far as I am concerned. 16:59:49 and add it to the wiki page 16:59:52 yes 16:59:58 okay 17:00:03 I could go longer if we want to keep going, but if others need to leave we could just move to list/other channel 17:00:08 #action mizmo to take agreed points and edit the governance charter 17:00:17 i can go up to 1 hour longer if folks want to move to #fedora-server 17:00:33 I think we need to iron out the remaining issues so we can move past them and forward 17:00:51 I can stay longer as well 17:01:04 is there a meeting now ?' 17:01:08 mizmo: we could stay here? or is there a meeting after us? 17:01:11 we have 4 people who can stay, i guess we need one more to make decisions if we come to a vote? 17:01:11 This room is not scheduled at this time if we want to continue 17:01:16 great 17:01:17 oh okay we can stay here then 17:01:23 sgallagh, is your meeting over? are you free? 17:01:23 we got meetbot here not in server 17:01:29 I am available now 17:01:32 we should stay here 17:01:45 Evolution: you still with us too? 17:02:04 tuanta, can you stay a bit longer? 17:02:22 sure, I will stay 17:02:30 I picked -meeting-1 specifically because it's not booked afterwards :) 17:02:39 #agreed We'll stay and work through more items on the agenda 17:02:46 cool. 17:02:50 * sgallagh tries to read through the backlog quickly. 17:02:59 okay so the next agenda item is "is fedora server one product?" 17:03:04 #topic Is Fedora Server One Product? 17:03:21 Hopefully this is more a difference in wording than in the idea 17:03:27 Yes, I think it's one product. Okay Viking-Ice, fire away :) 17:03:37 mitr, yeh i think maybe it is just a wording confusion 17:03:53 mizmo, obviously not and what has been more or less established on the list already that it is not 17:04:01 well, I think it depends on what you mean by 'product' I guess. 17:04:01 mizmo, so tell me why you do think so 17:04:37 Viking-Ice, I can tell you quite lucidly why I think so. If Fedora as a whole is to have three products, we're kind of bursting at the limit of what potential end-users are going to be able to handle 17:04:54 think about live install vs DVD, think about all the arches we support, think about the spins, think about the products 17:05:14 that's a huge combinatoric mess, and it's going to make newcomers to Fedora pretty befuddled as to what fedora actually is or what they need 17:05:25 for us to blow server into multiple products is going to add to the confusion 17:05:27 mizmo, I'm aware people can choose and actually from a neural scientist standpoint has already done so before they can even point at it 17:05:42 Viking-Ice, i can't follow, can you restate that? 17:05:42 taking it from the deliverables angle, it sounded like people might like kickstarts + a netinstall iso... so we could produce N kickstarts for use with a netinstall... is each of those a 'product' ? 17:06:03 nirik, i wouldn't consider those a product no. they are different configurations for the same product. 17:06:14 Viking-Ice: I think the common infrastructure (kernel, booting, basic libraries, choice of configuration/management/...) framework needs to be uniform for all deployments. There may be specific separate "single-click" ways to install a specific role (corporate LDAP / mail / Java application server, whatever), but those are all "roles" of a single product to me. 17:06:26 nirik, if it has gone through the transitioning process ( which I say is prd ) then yes 17:06:38 +1 to mitr 17:06:44 or in other word once *we* have produced something it's an product 17:07:11 so, it sure sounds like a terminology thing to me. ;) 17:07:21 mitr: +1 17:07:25 mitr, I would call that common infrastructure between prd's but I even doubt that it would be applicable to all of them 17:08:03 I think: just different meanings of what a product is 17:08:10 tuanta: +1 17:08:23 Viking-Ice, i would call that a bullet point on the prd, 'Product must be able to deployed in accordance with a defined list of roles.' 17:08:44 have we started a wiki page for our PRD yet? 17:08:52 Viking-Ice, I mean, absolutely, each role needs to be defined, but i think a PRD for each role is overkill 17:08:55 Viking-Ice: When I said "needs" to be the same, I did mean "needs" - we will be manpower-constrained even for the new things that we need to do, reinventing the same functionality for different kinds of servers is a waste we can't afford 17:08:58 To my mind, the Fedora Server as a product is a well-defined set of solutions that we have vetted for people to use. These solutions can be divided into "roles". 17:09:01 nirik, we have a blank starter one, lemme grab the link 17:09:04 nirik,cant until we decide multiple products or a single product 17:09:18 #link https://fedoraproject.org/wiki/Server/Product_Requirements_Document 17:09:23 thx 17:09:24 mizmo, is stuck with the as I see incorrect cannot be apply three definition 17:09:41 of the wg's 17:09:49 Viking-Ice, i'm not following, i'm sorry :( 17:09:56 Viking-Ice: Sorry, can you please rephrase that? 17:09:56 Viking-Ice: I agree it'll kind of strange if we announce Fedora Server 1.0 !!! Implements all of .... 2 TCP protocols! but the overall direction should be of a single product with multiple roles 17:10:04 only one the base OS can be labeled a product 17:10:08 * nirik largely doesn't care. call them 'roles' or 'products' does it matter in the end? 17:10:25 Viking-Ice, the base os is the platform, not the product 17:10:34 mitr, how are you going to acheve that install everything always? 17:10:36 Viking-Ice: Or perhaps to take it from a different view, even if we have a nice pre-packaged LDAP and mail solution, I should be able to install a _single_ physical server that serves both, shouldn't I? 17:10:45 From my perspective, the duty of the Product would be to set the definition of how something gets promoted into a "supported" role in that Product. 17:11:35 mitr, we need to be able to handle this on per product bases as in ldap as one product and a mail server as another 17:11:35 Viking-Ice: installation is an implementation detail at this level of discussion I'd say. I kind of like having a "single big installation medium", but a minimal netiso that allows installing the various roles would work just as well. 17:11:44 Viking-Ice: why? 17:11:44 I think a lot of things are going to have to be longer term... 'multi role' 'CM stuff' at least 17:11:52 what are other working groups calling what they are working on. do they have roles vs products issues 17:12:17 mizmo: I think the other groups don't have the equivalent of an "1-click mail server" use case 17:12:51 mitr: not sure. 17:13:24 mitr, they workstation working group has multiple and I suspect it's going to blow over due to it's gnome-ism and the DE community's away with it 17:13:26 sorry, that was for mizmo. pesky tab 17:13:34 mitr: there are some different desktops (Gnome, KDE, XFCE, etc.) in Workstation WG. it is also equivalent, I think 17:14:19 so let me do a quick review of where we're at right now, 17:14:25 the cloud depends on our mutual definition of what is cloud and what is server and the enviroment and baseos dont have 1 multiple apps so to speak 17:14:27 - we seem to have confusion about products vs. roles 17:14:57 - i *think* we all agree whether or not they are roles or products they will share kernel, booting, basic libraries, choice of configuration/management/... 17:15:04 I see products as single or multiple server application which an roles could be applied upon 17:15:43 mizmo, right they will share kernel, booting, basic libraries, choice of configuration/management/... 17:15:50 - we'll make technology choices about what is the single supported way to do something (e.g., mailserver) but won't preclude users from installing alternatives, just with less support 17:16:13 if we allow multi role, we are going to have quite a combitorial QA doom. 17:16:14 - each server could have multiple roles at the same time (email and ldap serveR) 17:16:35 mizmo, there is no such thing as support in Fedora and people should really stop saying that instead use "best effort" 17:16:50 nirik, no more then we have already 17:16:55 ( qa doom that is ) 17:17:05 mizmo: +1 17:17:08 Viking-Ice, there is such a thing as support in terms of, what does the documentation recommend? what is the default assumed configuration? etc 17:17:11 nirik: I don't think it's really different from having two or more applications installed at the same time - as long as they don't talk to each other. 17:17:16 sure it would be... unless we don't test anything as much as we don't test it now. 17:17:19 Viking-Ice, the docs aren't combinatorial 17:17:29 also, we can't easily do multi with kickstarts... 17:17:57 nirik, well we could.... depending on how the roles are defined 17:17:58 mizmo: might say 'featured' or something? 17:18:00 nirik, but dealing with this as an single application or applicaton stack per product will allow us to host test days with that or those combined products 17:18:04 nirik, using comps groups for example 17:18:17 kickstarts are a modifiable concept :) Anyway, I really proposed this as a way to tell the difference between a single server / multiple servers 17:18:20 nirik, more easially with ks than anything else 17:18:24 mizmo: possiblly. 17:18:49 compsp groups are a mess and need to be reworked from ground up 17:19:02 Viking-Ice: Same as we now host printing and virtualization test days while having a single Fedora for both 17:19:03 Can I take a step back here and try to center us on the question we're trying to answer? 17:19:09 Viking-Ice, when you say single application stack per product, can you give a concrete example so i can better understand your meaning, since at this point the word 'product' doesn't have meaning for me anymore? 17:19:13 Viking-Ice: well, if we have a set of 'featured' deliverables that are our product we can work on testing them... it's a lower scope problem than testing all 30000 fedora packages all the time. 17:19:31 What exactly differs in our mission based on how we define roles vs products? 17:19:52 sgallagh: I guess multiple PRD's vs 1? 17:20:04 mizmo, application stack is like freeipa which is made up of a combination of separated applications 17:20:32 Could we agree to work on separate chapters of the same PRD for now, with the option to split them up later if it becomes obviously necessary? 17:20:43 lapp/lamp would be another two etc 17:20:43 or LAMP server or openstack server or mail server (which might have postfix, spamassassin, etc) 17:20:57 I think we may be putting the cart before the horse here 17:21:10 prd per application is the only thing that will work 17:21:27 * nirik thinks prd per application is overkill, but perhaps thats me 17:21:30 trying to apply a prd to the entire group is nonces 17:21:36 PRD per application is overkill +1 nirik 17:21:52 Viking-Ice: If you're going to speak in absolutes, please provide supporting evidence :) 17:21:58 Viking-Ice, let me tell you why I think PRD per application is overkill, and you let me know what you think - 17:22:05 Yeah, I'm inclined to agree on "overkill" 17:22:09 Viking-Ice, the PRD for each of those applications is the responsibility of upstream, not us. 17:22:22 Viking-Ice, the upstream FreeIPA team, for example, is responsible for the FreeIPA PRD 17:22:42 Viking-Ice, we are only responsible for the PRD of the platform on which applications and stacks like that are meant to be deployed on 17:23:07 mizmo: I disagree with that, modification and integration of upstreams should be in our scope as well 17:23:18 is there some kind of template for what is in a PRD? 17:23:20 I don't agree with that 100%. I think we should be able to modify those packages to fit with our goals 17:23:21 mizmo, upstreams are now responsable for what we are doing here downstream with us 17:23:27 Viking-Ice: I agree we will need a PRD for the individual app stacks, to make sure it's integrated correctly and the like, but they are all unified by the shared base, config management, monitoring and the like, and _that's_ one basis of the server PRD; the other being a list of app stacks we want/need 17:23:31 nirik: There are many, but we can define our own 17:23:32 mitr, modification and integration is fine, but a full PRD for the application i think is out-of-scope. 17:24:04 mitr, I dont think we should apply an prd to the common stuff 17:24:26 isn't there a separate WG for application stacks? or am i dreaming 17:24:27 we are not going to dictate monitoring on servers it's ( let alone with CIM bemoath ) 17:24:38 I would want a fair bit of information for a 'role' or whatever we want to call them... before commiting to producing, testing and delivering it. 17:24:45 mizmo: That's "application runtime environments", not "FreeIPAs" 17:24:52 mitr, ah okay thank you 17:24:53 mizmo: There's a WG for how stacks are put together, not the stacks themselves 17:24:58 the purpose of this server working group is not to just push RH products through the door and if that is your explist intent then count me out 17:25:03 Viking-Ice: ... so, to return earlier, I'm really unwilling to back down from being able to install a single machine that serves two roles simultaneously (without resolving to virt) 17:25:35 Viking-Ice, we could do without the accusations 17:25:45 mitr, not following how that is relevant 17:26:01 * nirik has no idea where that came from. 17:26:19 as I see it you would install two optiomized products that server for a spesific role on those servers 17:26:22 mitr: it increases testing needs, but might be doable depending on how we do it. 17:26:52 Viking-Ice: +1 17:27:06 proposal: make a single server PRD that includes what information we need from 'roles' and includes the initial set of them we intend to deliver. 17:27:18 Or we could simply assert that the expected operation of Fedora Server is single-purpose and that we don't "support" multiple roles (but allow it) 17:27:26 nirik, -1 that's not what prd's are for 17:27:35 nirik +1 17:27:39 Viking-Ice: ok, then what are they for? 17:27:59 defining the transition process from an marketing idea to a product 17:28:04 * nirik is confused, really the PRD is for fesco to tell them what we are making right? 17:28:22 "the server community is not a product" 17:28:38 "fedora server is not a product" 17:28:39 ok, and how is the 'roles' we intend to produce, test and distribute not part of our product? 17:28:50 "Fedora freeipa server" is a product 17:29:10 Viking-Ice: Fedora Server is a product in the same way that Microsoft Windows Server 2012 is a product. 17:29:12 i'm pretty sure the point of the PRD is to define the problems a product solves, and in this specific case to let FESCo know what specific problems we feel need to be solved in the server space 17:29:19 nirik, I would say our roles are filesystem,databases,web servers, etc 17:29:50 mizmo: +1 (that was our original intent as far as I understand it) 17:30:07 Viking-Ice: ok, well, I guess I don't care if we make a bunch of PRD's instead of one, but I suspect a lot of it would overlap, no? 17:30:36 nirik, yes hence I said we needed to do 3 or more products so we could identify where they would overlap 17:30:49 Viking-Ice: I disagree. our roles are specific... not just 'web servers' 17:31:05 nirik, explain 17:31:10 or perhaps I am misunderstanding what you were saying there. 17:31:15 i think it might be a good idea to give very specific examples since we seem to be struggling without a common verbiage here 17:31:15 I suspect that we maybe just chose the wrong term by calling this document a "PRD". 17:31:39 how about 'Fedora Server Feature Requirements List' 17:31:52 we can call it fedora common server infrastructure 17:31:58 another term "Functional Requirements" 17:31:59 possible 'roles': "LAMP Server with httpd, mariadb, php, $foo php applicaion, $bar php application" 17:32:13 nirik, I call that application stack 17:32:35 Viking-Ice, and you want to make a product of each application stack so would you also call nirik's example a product? 17:32:39 is that fair? 17:33:05 mizmo, I would make a product out of wordpress or drupal as an application stack 17:33:13 ready deployable solution 17:33:17 why don't we just avoid using the word product 17:33:23 sure, but we are going to commit to producing, testing and distributing specific application stacks. 17:33:30 what would we call 'Fedora Server' if we were avoiding the word 'product' 17:34:03 mizmo: Operating System? 17:34:15 mitr, sure let's call it OS 17:34:16 okay 17:34:27 so for the Fedora Server OS, we need to put together a functional requirements document 17:34:34 mitr: OS is just a kind of product 17:34:36 which is essentially a list of the things Fedora Server OS needs to do 17:34:41 mizmo: I'm not entirely happy with an OS - because it kind of implies that all applications are equal, which I don't think they are 17:34:52 Fedora Server Platform? 17:34:57 is 'platform' an okay word? 17:35:01 I would say so 17:35:12 platform doesn't mean much 17:35:13 it would install the common bits 17:35:20 mitr, that's okay, as long as we get away from the word 'product' since it seems to cause problems 17:35:24 tuanta: Yes, and I see Viking-Ice's point that an application stack can be a "product" (in particular, one can buy such a thing) 17:35:39 and it causes problems other than the ones we're having here today, 'product' can have a connotation 'something for sale' but we aren't selling this 17:35:48 "Platform" word could be conflicted with BaseOS Platform, no? 17:36:02 not sure, let's just run with it for now? 17:36:19 Viking-Ice, are you okay with putting together a single functional requirements document for the Fedora Server Platform? 17:36:27 or just "Fedora Server" and "Featured Roles" ? man, english is anoying sometimes. ;) 17:36:36 Viking-Ice, that document can include all of the application stacks and roles of interest 17:36:53 +1 nirik. rally annoying ;) 17:37:02 nirik, in a sense it's a form architecture astronauting we're engaging in here I think 17:37:13 yeah 17:37:24 Yeah, I think we're lost in the terminology and that's confusing the concepts 17:37:41 it's more a Fedora {Server Platform} than {Fedora Server} Platform. it's a server platform for running interesting server stuff on top of 17:37:51 mizmo, single functional requirements document for the Fedora Server Platform is one thing but dont think we can apply the application stack or roles of interest to it ( yet ) 17:37:58 I don't care what we end up calling things. I want a common base thing (netinstall iso, whatever) and some 'featured application stacks' or whatever that we commit to putting together from our collection and making shine. 17:38:11 nirik, i think we all agree, vocabulary hangups aside 17:38:21 nirik: Can we make that a formal proposal? 17:38:31 Because that's something I'd like to see nailed down at least. 17:38:38 Regardless of how we write the document(s) 17:38:41 nirik, installation method is not what matters here or makes it shine it's the application that does 17:38:44 sure, hopefully we can figure out terminology 17:38:46 I'd like us to agree that this is the visible goal 17:39:15 Viking-Ice: sure, but I want to share as much as possible between application stacks... 17:39:41 not to much as in montoring application for example 17:39:51 would not be bart of that base 17:39:55 common base platform with 'featured application stacks' built on top of it. We commit to produce, test and distribute these application stacks. 17:39:56 mean part 17:40:05 nirik, yes 17:40:06 agreed. 17:40:08 nirik +1 17:40:45 +1 nirik. that makes sense. 17:40:47 nirik: +1 17:40:56 nirik: +1 17:41:23 which makes it" 17:41:23 "Fedora Server WG where we discover produ"ct solutions that work well for our users, our administrators, our developers and our project." 17:41:33 thinking about it, we will need a way to promote/add new applications, so perhaps the requirements doc could just explain how that happens and the applications could be seperate. whatever works tho. 17:41:34 Viking-Ice: I'd say that ensuring that all featured roles can be monitored uniformly and with zero manual setup should very much be an option for the Server Platform design (not sure about actually requiring that, but it should be on the table for discussion) 17:41:44 Viking-Ice: +1 17:41:46 mitr +1 17:41:50 mitr, so far snmp works just fine 17:42:01 Viking-Ice: Good, so let's get it set up and integrated :) 17:42:08 nirik: I think that's what I proposed half an hour ago :) 17:42:16 mitr: I think investigating that could be a good longer term goal... I think we shouldn't try and do that in the first set of deliverables. ;) 17:42:25 nirik: yes 17:43:04 nirik: Yes and no: if we make that a goal, I can direct the OpenLMI team to focus on it. 17:43:04 so where are we here? 17:43:08 nirik: I agree with all the words in the proposal, so +1 in that sense; still would like a more explicit mention of shared packaging universe / parallel installability and the like 17:43:09 mitr, per snmp conf snipped with application/application stack and out of the box snmp setup for the "OS" itself ( cpu/memory/disk ) 17:43:15 I think we're agreed on "common base platform with 'featured application stacks' built on top of it. We commit to produce, test and distribute these application stacks." 17:43:26 which is... a mission statement / header for the PRD potentially? 17:43:26 I have a certain amount of resources that I can direct here (which is a nice change from Fedora's history) 17:43:27 yes 17:43:33 sure. 17:43:39 sgallagh: excellent. 17:43:48 mizmo, not for the prd 17:43:53 ;) 17:43:57 mission statement sure+ 17:44:04 Viking-Ice, why not for the prd 17:44:06 perhaps we could setup a section in the wiki page for: short term goals, longer term goals? and add ideas? 17:44:28 yeh that sounds good nirik, i can do that now 17:44:29 mizmo, let's not start that dance all over again 17:44:38 ;) 17:44:47 mizmo: perhaps call it 'ideas container' or something... 17:44:51 Viking-Ice, i'm completely dumbfounded but have no problem not going into it 17:45:20 so, did we get to any conclusion on /topic? or should we move on, did we have another item on agenda? 17:45:21 mizmo, I'll see if I can apply prd to it 17:45:35 but I doubt it will work 17:45:40 #action mizmo to set up short term / long term goals document on wiki 17:45:49 Proposal: our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to first-tier inclusion. 17:45:51 #agreed Fedora Sevrer is a common base platform with 'featured application stacks' built on top of it. We commit to produce, test and distribute these application stacks. 17:46:52 what was that first-tier stuff again 17:47:02 was that matt's rings to rule them stuff 17:47:34 sgallagh: I think I'd like to have at least one or two simple services (ftp? ntp?) fairly well-scoped as well, if only as a reality check. 17:47:44 mitr, agreed 17:47:46 Viking-Ice: No, as discussed on the mailing list 17:47:59 * nirik shudders at ftp 17:48:03 Basically the set of things we're saying "This is well-integrated and easy to set up" 17:48:07 Viking-Ice: == "featured application stack" 17:48:17 mitr: Thanks, exactly 17:48:28 we should be able to have produced 1,2 preferable 3 single server application products by then 17:48:41 no using the word 'product'! bad word! 17:48:46 mitr: Yes, one or two simple services would be good too 17:49:14 +1 to sgallagh's proposal 17:49:19 +1 to mitr's suggestion 17:49:35 I think it might be good (on the list proibibly) for everyone to list out the application stacks they think we should work on, or that they are eager to work on, and we narrow down to a subset of those for the january timeframe? 17:49:43 mizmo, well bind for example is not an "application stacks" it's an application 17:49:58 nirik: We don't necessarily need to have made that decision yet 17:50:25 I suppose not, but we also can't really work on things yet until we know in more detail how we are going to install/setup/ship them, no? 17:50:29 I would like to have one product to start working on 17:50:45 does iscsi count as a "file server" 17:50:50 Defining how things get promoted there is more in line with this goal (as I see it) 17:50:50 Selecting the ones to start on is the obvious next step 17:51:01 but what does 'work on' mean? requirements? kickstart? comps group? ansible playbook? raw qcow2 image? 17:51:08 Viking-Ice: Probably a good idea to pick a "reference implementation" 17:51:24 nirik, i think it would be requirements right? kickstart / comps group / playbook i think are too implementation specific 17:51:37 I would think so... 17:51:41 at this point 17:51:46 I'd be in favor of starting with a FreeIPA Domain Controller, personally. That's something we can build on (focus on integrating other apps with it, for example) 17:51:53 * sgallagh also has connections there :) 17:51:54 nirik, installable on hw/vm/container as an single or multiple times would be a requirement 17:52:02 sgallagh, to big 17:52:06 as I have said before 17:52:33 sgallagh, Viking-Ice: That's kind of big, but it has the unique advantage of allowing us to have a shipping Featured Application without having to solve the identity problem first. 17:52:36 389ds ( standalone ) samba ( standalone ) etc then the freeipa glue on top of that 17:52:52 why not eucalyptus 17:53:00 if we want popular cloud stack 17:53:01 I have no objections to working on the requirements for application stacks... wiki page? but I am not sure specifics will help right now, don't we want a general doc before we try and make some specific thing? 17:53:02 to deal with 17:53:49 nirik, sometimes taking one specific thing and extrapolating general principles from it can be helpful, that's how i like to do things sometimes i guess 17:53:57 nirik, not really these application will simply install on Fedora Server is common base platform 17:54:04 s/is//' 17:54:12 Viking-Ice: Mostly because FreeIPA already has a simplified interface and a powerful API for managing it, while the components it's comprised of do not 17:54:21 mizmo: sure, but I don't understand how to do that in this case. 17:54:31 I think it would be less effort to integrate the FreeIPA stack into our product than 389ds 17:54:37 ok, how can I installed "Fedora Server" to work on my application stack? 17:54:43 And gets us a larger piece of the pie in the process 17:54:46 sgallagh, how so 17:55:01 * mizmo turns into a pumpkin in 6 minutes 17:55:14 until we nail down more specifics I don't see how we can 'work on' these specific cases. ;) 17:55:21 mean we want best out of the box experience for 389ds we need to test that stuff as well as an standalone ( which freeipa will benefit having ready ) 17:55:47 i like to talk about these things in terms of people and environments 17:55:52 so why would i want to instlal a free ipa server 17:55:56 what is the human environment around me 17:56:03 authentication 17:56:08 in mixed environement 17:56:13 Viking-Ice: Let's table this for next meeting. 17:56:13 I think we're off in the weed.s 17:56:42 e.g. who is the user installing this 17:57:14 what problem are they trying to solve, what tasks do they have to complete along the way of installing and configuring and getting freeipa working 17:57:22 freeipa is black box solution so the answer to that is the administrators that prefer one solution trying to be it all 17:57:31 which parts of that install / configuration / testing / production process are general to other roles/application stacks 17:58:16 I can as an administrator install all the components that make up freeipa and maintain them separately for example 17:58:23 Viking-Ice: It's hardly a "black box". Its purpose is to join all the common needs of an identity-management system with sensible defaults so admins need not understand all the nitty-gritty. 17:59:22 As I said, let's table this for now. 17:59:28 +! 17:59:29 +1 17:59:35 Did we agree on the general target I proposed? I didn't see many responses 17:59:41 sgallagh, it is you cannot have the freeipa management on a central server while having he 389ds on one kerberos on another etc 17:59:49 sgallagh, i +1 it 17:59:50 Proposal: our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to first-tier inclusion. 18:00:07 +1 to myself 18:00:20 sgallagh: +1 18:00:23 sure, +1 18:00:29 +1 18:00:40 #agreed Our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to first-tier inclusion. 18:00:41 sgallagh: ... "requirements for an application stack to be promosted to featured status" to be consistent? 18:00:45 +1 otherwise 18:01:17 (a few months later we might want to look at all the terminology we have accumulated and rename it all to simplify; won't happen I expect) 18:01:19 makes sense 18:01:24 +1 18:01:27 mitr: Yes, sorry. I should have updated that with the follow-up discussion 18:02:02 #agreed (revised) Our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to featured status. 18:02:02 I count +6 from voting members 18:02:57 Thank you mizmo for running the meeting today. Thank you everyone for such... spirited discussion. 18:03:06 hehe 18:03:10 np 18:03:12 #endmeeting