16:02:30 <mizmo> #startmeeting Server Working Group Weekly Meeting
16:02:30 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:30 * sgallagh is lurking while on a conference call
16:02:39 <mizmo> #topic roll call
16:02:43 <mitr> Hello
16:02:44 <mizmo> who is here :)
16:02:47 <tuanta> .fas tuanta
16:02:47 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
16:02:52 <sgallagh> I'm semi-here (on another call)
16:03:16 <nirik> morning everyone
16:03:31 <Evolution> I'm at LISA13 currently so my ability to be here is limited by hotel wireless
16:03:38 <mizmo> Viking-Ice?
16:03:45 <mizmo> davidstrauss?
16:04:08 <nirik> .hellomynameis kevin
16:04:10 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:04:17 <sgallagh> mizmo: davidstrauss is presently in Australia where it is 2am. He may not be around for the next couple meetings
16:04:22 <mizmo> ah ok
16:04:22 * nirik tries to get more people to use that for meetings. ;)
16:04:35 <sgallagh> .hellomynameis sgallagh
16:04:37 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:04:37 <mizmo> how about Viking-Ice? we kind of need him i think given the topics
16:04:55 <Viking-Ice> I'm here
16:05:01 <mizmo> okay great
16:05:01 <nirik> cool
16:05:11 <mizmo> #topic agenda
16:05:37 <mizmo> okay so here is the thread on today's agenda
16:05:38 <mizmo> #link https://lists.fedoraproject.org/pipermail/server/2013-November/000425.html
16:05:58 <mizmo> so the suggested agenda items are:
16:06:02 <mizmo> - finalizing the governance charter
16:06:16 <mizmo> - is fedora server one product?
16:06:37 <mizmo> - Viking-Ice suggested 'Pick the first server application that will make the transition to an "product"'
16:06:48 <mizmo> - I had also suggested use cases and personas but i think that depends on the 2nd item
16:06:50 <mizmo> sound good?
16:06:56 <Viking-Ice> yep
16:06:58 <mizmo> #topic Finalizing the Governance Charter
16:07:01 <tuanta> yeah
16:07:13 <mizmo> #link https://fedoraproject.org/wiki/Server/Governance_Charter
16:07:18 <nirik> so, did we work out issues on that one section on list?
16:07:24 <Viking-Ice> ubs
16:07:52 <mizmo> 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 <mizmo> but i dont think we resolved the issue of how many / which sigs to be represented by specific seats?
16:08:11 <mizmo> but im not sure
16:08:35 <nirik> 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 <mizmo> 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 <kde_tony> .hellomynameis kdetony
16:09:00 <zodbot> kde_tony: kdetony 'Anthony Mogrovejo' <tony001983@gmail.com>
16:09:06 <mitr> 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 <Viking-Ice> well if we are going to be applying prd to products we kinda need people from sig not liasons
16:09:20 <mitr> (that way re: resolved/unresolved issues)
16:09:33 <mizmo> i feel the same mitr
16:10:03 <nirik> Viking-Ice: how so?
16:10:17 <Viking-Ice> 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 <nirik> sure.
16:11:04 <Viking-Ice> 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 <mizmo> 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 <nirik> 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 <Viking-Ice> mizmo, right
16:12:20 <Viking-Ice> that's my only concern
16:13:04 <nirik> 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 <mizmo> 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 <mitr> Viking-Ice: I'm equally concerned about the development side - the 9 of us can only contribute so much work.
16:13:31 <mizmo> 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 <Viking-Ice> mitr, I'm not so sure how much of an actual development site we be involved with
16:14:35 <mitr> 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 <Viking-Ice> 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 <Viking-Ice> for their images
16:15:30 <nirik> hopefully we can do better. ;)
16:15:31 <Viking-Ice> mitr, the missing requirements speak for themselves ( like your common configuration api suggestion )
16:15:49 <Viking-Ice> nirik, we have more "products"
16:15:59 <Viking-Ice> in the long run that is
16:16:04 <nirik> Viking-Ice: yep.
16:16:04 <mizmo> 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 <mizmo> 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 <Viking-Ice> 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 <nirik> 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 <Viking-Ice> do we need fresh blood ones we have nailed the process down
16:17:39 <Viking-Ice> I dont think so
16:17:52 <mizmo> nirik, oh great point
16:17:57 <nirik> well, it could make things get set and fail to change for new stuff.
16:18:20 <mizmo> Viking-Ice, so the server wouldn't be QAed by Fedora QA?
16:18:22 <Evolution> I'm not sure about term limits, but maybe a 6 month seat vote?
16:19:15 <Viking-Ice> mizmo, nope not directly no
16:19:16 <nirik> Evolution: so revote for everyones seats every 6 months? or ?
16:19:17 <mitr> 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 <tuanta> mizmo, if QA have not got enough resources, I think we need other resources inside Server WG
16:19:43 <nirik> mitr: I share that concern...
16:19:43 <Viking-Ice> I personally dont see the need for the WG once the process is set
16:19:44 <mizmo> mitr, im in agreement with you
16:20:06 <Viking-Ice> tuanta, irrelevant with resources QA should not be doing that stuff
16:20:12 <mitr> OTOH having a 6-month election term with a 18-month production cycle would also be interesting...
16:20:19 <nirik> Viking-Ice: there's going to be likely some longer term items that can't be "set" quickly, IMHO.
16:20:24 <mizmo> 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 <Viking-Ice> and unless we alter anaconda's release cycle QA wont be handling more the one product anyway
16:20:56 <mizmo> 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 <mitr> 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 <mizmo> +1 to nirik
16:21:48 <Viking-Ice> mizmo, to be fair FPC adds unnecessary burden to community workflows
16:22:01 <mitr> nirik: +1
16:22:15 <mizmo> 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 <Viking-Ice> we can always revisit so +1
16:22:40 <tuanta> +1 too
16:23:06 <nirik> thats 5 I think.
16:23:11 <mizmo> that's enough?
16:23:22 <mizmo> okay :)
16:23:41 <mizmo> #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 <mizmo> okay now back to term limit discussion
16:23:51 <mizmo> ill change topic too
16:23:58 <mizmo> #topic Finalizing the Governance Charter: Term Limits
16:24:25 <mizmo> so it seems like we have two schools of thought / proposals thus far?
16:24:49 <mizmo> 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 <Viking-Ice> mizmo, after the process has been delivered yes
16:25:23 <mizmo> Evolution and mitr, it seems like you support term limits and potentially 6-month election terms
16:25:31 <Viking-Ice> mizmo, we are not dealing with single product
16:25:50 <Evolution> not term limits, but votes to make sure that people are still doing the right thing
16:26:02 <nirik> I think there will be ongoing work for this group for a long time...
16:26:04 <mitr> mizmo: limited terms, not limits on total time serving.  Not sure about 6 months
16:26:21 <mizmo> right, because 6 months might not work with an 18 month production cycle
16:26:24 <mizmo> as you pointed out
16:26:26 <Viking-Ice> 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 <tuanta> it
16:27:11 <Viking-Ice> far more efficient
16:27:12 <tuanta> it is also not easy to organize an election
16:27:23 <mitr> 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 <mizmo> 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 <Viking-Ice> 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 <mizmo> tuanta, what if it was an informal election in IRC between the current WG members and server community members?
16:28:40 <mizmo> 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 <nirik> mitr: also, adding new products, dropping old ones, figuring new ways to integrate them, etc
16:28:45 <Viking-Ice> mizmo, you said "our deliverable (PRD) is finished" singular not plural
16:28:49 <mizmo> we've done it over the mailing list too
16:28:52 <tuanta> mizmo: it would be a good idea
16:29:12 <mizmo> 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 <mizmo> er fair even
16:29:24 <Viking-Ice> mizmo, yeah
16:30:14 <mizmo> 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 <Viking-Ice> 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 <mitr> 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 <nirik> Viking-Ice: we are that decision making body?
16:31:00 <Viking-Ice> nirik, for the first products not all products
16:31:05 <mitr> 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 <nirik> Viking-Ice: well, for the products we decide that the Fedora Server group is going to ship sure.
16:31:39 <mizmo> 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 <Viking-Ice> 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 <mizmo> well, what specific concerns do folks have with Viking-Ice's proposal of 3-6 month confirmation of participation?
16:32:24 <Viking-Ice> nirik, as I see just the first product
16:32:31 <Viking-Ice> mean products
16:33:10 <nirik> 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 <mitr> 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 <mizmo> 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 <Viking-Ice> nirik, just the step down process to that as in he would name a successor or we advertice and choose
16:34:42 <Viking-Ice> mizmo, use the same approach as you propose we cross that bridge when we get there
16:35:03 <Viking-Ice> and if things are that dysfunctional we just ping fesco and they decide
16:35:03 <nirik> well, naming successor isn't too great... but we choose one from the active folks would be ok...
16:35:13 <mizmo> 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 <Viking-Ice> again FESCO
16:35:41 <Viking-Ice> or CWG
16:35:43 <mizmo> is FESCo open to this level of management of the working groups?
16:35:50 <mizmo> I don't think the CWG really exists anymore Viking-Ice :(
16:35:54 <nirik> dunno, they might be I suppose.
16:36:14 <tuanta> CWG exists, I am sure
16:36:16 <nirik> they are committed to choosing a liasion to fesco from each group...
16:36:20 <mizmo> well, that could be a workable resolution i guess
16:36:29 <Viking-Ice> 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 <mizmo> 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 <mizmo> Viking-Ice, do you have ideas on how to account for this in your proposal?
16:37:37 <Viking-Ice> mizmo, look at fesco same people for the last decate more or less
16:37:55 <Viking-Ice> fresh ideas killed instantly by the few fresh members that make it there so..
16:38:19 <nirik> 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 <Viking-Ice> how randomly would that be chosen?
16:39:06 <nirik> Viking-Ice: like redesigning things with 3 new products and revamping everything about how we do releases? ;)
16:39:24 <nirik> random number from 0 - 9 ?
16:39:26 <mizmo> Viking-Ice, bzflag tournament
16:39:30 <nirik> ha.
16:39:38 <mizmo> but that wouldn't be random, i suck at it
16:39:43 <Viking-Ice> nirik, that process could be applied to 3 new products while the other already released products remain the same
16:40:07 <nirik> Viking-Ice: I'm just providing a counter example for your 'all fresh ideas are killed instantly'
16:40:17 <Viking-Ice> but as I see it the entire server community should be the one that select products ones the process is ready
16:40:54 <nirik> 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 <Viking-Ice> that's how you would ensure fresh ideas and participation ( as in by limiting the server wg direct involvement )
16:41:11 <mizmo> nirik, on a serious note, we could just ask for people to volunteer to step down
16:41:13 <Viking-Ice> I think the governess is ready enough
16:41:16 <mizmo> rather than randomization
16:41:41 <mizmo> 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 <mizmo> 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 <mitr> nirik: There's at least one other group with such a proposal already
16:43:55 <nirik> 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 <mitr> As much as I hate delaying administrativia, perhaps we should delay the turnover part to have more conversations about the lifetime?
16:44:17 <mitr> 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 <Viking-Ice> 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 <Viking-Ice> chooses to step down I mean
16:45:09 <nirik> Viking-Ice: I can be +1 to that... and we can revisit if we need a better turnover setup.
16:45:18 <Viking-Ice> yep that can always be done
16:45:28 <Evolution> same
16:46:22 <tuanta> It is fine enough at this time. I think. So +1 for this
16:46:27 <mizmo> 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 <nirik> we could even say: will revisit in 6 months?
16:47:02 <mizmo> i'd prefer that actually
16:47:09 <Viking-Ice> <sigh>
16:47:13 <mizmo> +1 to revisit in 6 months
16:47:24 <tuanta> +1 nirik
16:47:27 <Viking-Ice> -1 to revisit let's just get this over with
16:47:31 <mitr> Note that the two are effectively equivalent :)
16:47:40 <mizmo> mitr, yes but revisit is more neutral :)
16:48:06 <nirik> well, I was thinking both... we do what Viking-Ice proposed now, but make a note to revisit it in 6months.
16:48:09 <Viking-Ice> mitr, one is delay handling this the other one is not
16:48:14 <nirik> (not as a formal part of the gov doc)
16:48:37 <nirik> doesn't matter, lets just pass the proposal from Viking-Ice now?
16:48:38 <Viking-Ice> nirik, I took it as you wanted to postpone the gov stuff for 6 months
16:48:47 <mitr> Assuming you see the two as equivalent, I think we're at +5
16:48:53 <nirik> no, that wasn't what I meant.
16:49:01 <nirik> sorry if I was unclear there. :0
16:49:09 <mizmo> i'll +1 to vote to get this over with and move on :)
16:49:11 <mitr> Viking-Ice: We always have the option to revisit, or to revisit and not make a change.
16:49:18 <mizmo> +1 to 'both' i mean
16:49:19 <Viking-Ice> I would assume we would always revisit the process at confirmation time
16:49:28 <nirik> right, so with that change the gov doc is ready for fesco? anything else on it?
16:49:35 <mitr> I think I'll +1 to both as well so that we move on...
16:49:56 <mizmo> looks like we have 4, any takers to +1 to both so we have 5
16:50:07 <Viking-Ice> I obviously +1 to both ( since I made the assumption it would naturally occuring )
16:50:09 <mizmo> Evolution? tuanta?
16:50:12 <mitr> 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 <tuanta> +1 already
16:50:42 <mizmo> mitr, i think we'd said 5 was quorum initially
16:50:49 <mizmo> mitr, whether or not everyone is present
16:50:51 <nirik> mitr: +5 I assumed... or if we use 'lazy consensus' no -1's? ;)
16:51:42 <Viking-Ice> no votes from sgallagh and davidstrauss ?
16:51:49 <mizmo> #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 <mitr> 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 <mitr> ... not what the dictionary ...
16:52:24 <mizmo> mitr, "the number of members of a group or organization required to be present to transact business legally, usually a majority. "
16:52:33 <mizmo> ohh i see
16:52:43 <mizmo> you're saying it's people not votes
16:52:44 <tuanta> Viking-Ice, davidstrauss could not be attend I think. It is almost 300am at his side now
16:52:58 <Viking-Ice> ah
16:52:59 <mitr> mizmo: yes.
16:53:43 <mizmo> heh thats an interesting quandry
16:53:45 <mitr> 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 <mizmo> my preference is +5 just because that's the majority of the group in total
16:54:18 <mizmo> does anybody have issues with requiring +5?
16:54:31 <Viking-Ice> well my take was as nirik put it "+5 I assumed... or if we use 'lazy consensus' no -1's? ;)"
16:54:33 <sgallagh> I'm tied up in another meeting. I'll read the backlog in a few minutes when it ends.
16:54:37 <nirik> I also prefer +5, but we should try and just reach consensus most of the time and not do formal voting
16:54:46 <sgallagh> 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 <tuanta> yes
16:55:34 <Evolution> yes
16:55:39 <Evolution> sorry. hotel wireless is killing me
16:55:51 <mizmo> tuanta, Evolution - yes to +5 being the requirement?
16:55:58 <Evolution> yes.
16:56:00 <tuanta> +5 is fine
16:56:31 <mizmo> #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 <sgallagh> Can we get the current proposal we're voting on restated for me?
16:56:40 <mizmo> sgallagh, ^^ :)
16:57:13 <sgallagh> mizmo: +1
16:57:16 <mitr> mizmo: s/Quorum/number of votes to pass/ , just because I can't resist being a pain
16:58:10 <mizmo> #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 <mizmo> :)
16:58:28 <mitr> thanks
16:58:47 <mizmo> okay i guess we don't have time for other agenda items
16:59:06 <Viking-Ice> you must be joking
16:59:15 <mizmo> 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 <Viking-Ice> I would say so
16:59:40 <nirik> sure, edit and submit to fesco as far as I am concerned.
16:59:49 <Viking-Ice> and add it to the wiki page
16:59:52 <mitr> yes
16:59:58 <mizmo> okay
17:00:03 <nirik> 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 <mizmo> #action mizmo to take agreed points and edit the governance charter
17:00:17 <mizmo> i can go up to 1 hour longer if folks want to move to #fedora-server
17:00:33 <Viking-Ice> I think we need to iron out the remaining issues so we can move past them and forward
17:00:51 <mitr> I can stay longer as well
17:01:04 <Viking-Ice> is there a meeting now ?'
17:01:08 <nirik> mizmo: we could stay here? or is there a meeting after us?
17:01:11 <mizmo> 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 <sgallagh> This room is not scheduled at this time if we want to continue
17:01:16 <Viking-Ice> great
17:01:17 <mizmo> oh okay we can stay here then
17:01:23 <mizmo> sgallagh, is your meeting over? are you free?
17:01:23 <Viking-Ice> we got meetbot here not in server
17:01:29 <sgallagh> I am available now
17:01:32 <tuanta> we should stay here
17:01:45 <nirik> Evolution: you still with us too?
17:02:04 <mizmo> tuanta, can you stay a bit longer?
17:02:22 <tuanta> sure, I will stay
17:02:30 <sgallagh> I picked -meeting-1 specifically because it's not booked afterwards :)
17:02:39 <mizmo> #agreed We'll stay and work through more items on the agenda
17:02:46 <nirik> cool.
17:02:50 * sgallagh tries to read through the backlog quickly.
17:02:59 <mizmo> okay so the next agenda item is "is fedora server one product?"
17:03:04 <mizmo> #topic Is Fedora Server One Product?
17:03:21 <mitr> Hopefully this is more a difference in wording than in the idea
17:03:27 <mizmo> Yes, I think it's one product. Okay Viking-Ice, fire away :)
17:03:37 <mizmo> mitr, yeh i think maybe it is just a wording confusion
17:03:53 <Viking-Ice> mizmo, obviously not and what has been more or less established on the list already that it is not
17:04:01 <nirik> well, I think it depends on what you mean by 'product' I guess.
17:04:01 <Viking-Ice> mizmo, so tell me why you do think so
17:04:37 <mizmo> 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 <mizmo> think about live install vs DVD, think about all the arches we support, think about the spins, think about the products
17:05:14 <mizmo> 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 <mizmo> for us to blow server into multiple products is going to add to the confusion
17:05:27 <Viking-Ice> 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 <mizmo> Viking-Ice, i can't follow, can you restate that?
17:05:42 <nirik> 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 <mizmo> nirik, i wouldn't consider those a product no. they are different configurations for the same product.
17:06:14 <mitr> 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 <Viking-Ice> nirik, if it has gone through the transitioning process ( which I say is prd ) then yes
17:06:38 <mizmo> +1 to mitr
17:06:44 <Viking-Ice> or in other word once *we* have produced something it's an product
17:07:11 <nirik> so, it sure sounds like a terminology thing to me. ;)
17:07:21 <sgallagh> mitr: +1
17:07:25 <Viking-Ice> 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 <tuanta> I think: just different meanings of what a product is
17:08:10 <nirik> tuanta: +1
17:08:23 <mizmo> 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 <nirik> have we started a wiki page for our PRD yet?
17:08:52 <mizmo> Viking-Ice, I mean, absolutely, each role needs to be defined, but i think a PRD for each role is overkill
17:08:55 <mitr> 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 <sgallagh> 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 <mizmo> nirik, we have a blank starter one, lemme grab the link
17:09:04 <Viking-Ice> nirik,cant until we decide multiple products or a single product
17:09:18 <mizmo> #link https://fedoraproject.org/wiki/Server/Product_Requirements_Document
17:09:23 <nirik> thx
17:09:24 <Viking-Ice> mizmo, is stuck with the as I see incorrect cannot be apply three definition
17:09:41 <Viking-Ice> of the wg's
17:09:49 <mizmo> Viking-Ice, i'm not following, i'm sorry :(
17:09:56 <sgallagh> Viking-Ice: Sorry, can you please rephrase that?
17:09:56 <mitr> 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 <Viking-Ice> 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 <mizmo> Viking-Ice, the base os is the platform, not the product
17:10:34 <Viking-Ice> mitr, how are you going to acheve that install everything always?
17:10:36 <mitr> 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 <sgallagh> 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 <Viking-Ice> 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 <mitr> 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 <mitr> Viking-Ice: why?
17:11:44 <nirik> I think a lot of things are going to have to be longer term... 'multi role' 'CM stuff' at least
17:11:52 <mizmo> what are other working groups calling what they are working on. do they have roles vs products issues
17:12:17 <mitr> mizmo: I think the other groups don't have the equivalent of an "1-click mail server" use case
17:12:51 <nirik> mitr: not sure.
17:13:24 <Viking-Ice> 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 <nirik> sorry, that was for mizmo. pesky tab
17:13:34 <tuanta> mitr: there are some different desktops (Gnome, KDE, XFCE, etc.) in Workstation WG. it is also equivalent, I think
17:14:19 <mizmo> so let me do a quick review of where we're at right now,
17:14:25 <Viking-Ice> 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 <mizmo> - we seem to have confusion about products vs. roles
17:14:57 <mizmo> - 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 <Viking-Ice> I see products as single or multiple server application which an roles could be applied upon
17:15:43 <Viking-Ice> mizmo, right they will share kernel, booting, basic libraries, choice of configuration/management/...
17:15:50 <mizmo> - 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 <nirik> if we allow multi role, we are going to have quite a combitorial QA doom.
17:16:14 <mizmo> - each server could have multiple roles at the same time (email and ldap serveR)
17:16:35 <Viking-Ice> mizmo, there is no such thing as support in Fedora and people should really stop saying that instead use "best effort"
17:16:50 <Viking-Ice> nirik, no more then we have already
17:16:55 <Viking-Ice> ( qa doom that is )
17:17:05 <sgallagh> mizmo: +1
17:17:08 <mizmo> 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 <mitr> 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 <nirik> sure it would be... unless we don't test anything as much as we don't test it now.
17:17:19 <mizmo> Viking-Ice, the docs aren't combinatorial
17:17:29 <nirik> also, we can't easily do multi with kickstarts...
17:17:57 <mizmo> nirik, well we could.... depending on how the roles are defined
17:17:58 <nirik> mizmo: might say 'featured' or something?
17:18:00 <Viking-Ice> 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 <mizmo> nirik, using comps groups for example
17:18:17 <mitr> 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 <Viking-Ice> nirik, more easially with ks than anything else
17:18:24 <nirik> mizmo: possiblly.
17:18:49 <Viking-Ice> compsp groups are a mess and need to be reworked from ground up
17:19:02 <mitr> Viking-Ice: Same as we now host printing and virtualization test days while having a single Fedora for both
17:19:03 <sgallagh> Can I take a step back here and try to center us on the question we're trying to answer?
17:19:09 <mizmo> 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 <nirik> 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 <sgallagh> What exactly differs in our mission based on how we define roles vs products?
17:19:52 <nirik> sgallagh: I guess multiple PRD's vs 1?
17:20:04 <Viking-Ice> mizmo,  application stack is like freeipa which is made up of a combination of separated applications
17:20:32 <sgallagh> 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 <Viking-Ice> lapp/lamp would be another two etc
17:20:43 <nirik> or LAMP server or openstack server or mail server (which might have postfix, spamassassin, etc)
17:20:57 <sgallagh> I think we may be putting the cart before the horse here
17:21:10 <Viking-Ice> 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 <Viking-Ice> trying to apply a prd to the entire group is nonces
17:21:36 <mizmo> PRD per application is overkill +1 nirik
17:21:52 <sgallagh> Viking-Ice: If you're going to speak in absolutes, please provide supporting evidence :)
17:21:58 <mizmo> 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 <sgallagh> Yeah, I'm inclined to agree on "overkill"
17:22:09 <mizmo> Viking-Ice, the PRD for each of those applications is the responsibility of upstream, not us.
17:22:22 <mizmo> Viking-Ice, the upstream FreeIPA team, for example, is responsible for the FreeIPA PRD
17:22:42 <mizmo> 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 <mitr> mizmo: I disagree with that, modification and integration of upstreams should be in our scope as well
17:23:18 <nirik> is there some kind of template for what is in a PRD?
17:23:20 <sgallagh> 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 <Viking-Ice> mizmo, upstreams are now responsable for what we are doing here downstream with us
17:23:27 <mitr> 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 <sgallagh> nirik: There are many, but we can define our own
17:23:32 <mizmo> mitr, modification and integration is fine, but a full PRD for the application i think is out-of-scope.
17:24:04 <Viking-Ice> mitr, I dont think we should apply an prd to the common stuff
17:24:26 <mizmo> isn't there a separate WG for application stacks? or am i dreaming
17:24:27 <Viking-Ice> we are not going to dictate monitoring on servers it's ( let alone with CIM bemoath )
17:24:38 <nirik> 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 <mitr> mizmo: That's "application runtime environments", not "FreeIPAs"
17:24:52 <mizmo> mitr, ah okay thank you
17:24:53 <sgallagh> mizmo: There's a WG for how stacks are put together, not the stacks themselves
17:24:58 <Viking-Ice> 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 <mitr> 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 <mizmo> Viking-Ice, we could do without the accusations
17:25:45 <Viking-Ice> mitr, not following how that is relevant
17:26:01 * nirik has no idea where that came from.
17:26:19 <Viking-Ice> as I see it you would install two optiomized products that server for a spesific role on those servers
17:26:22 <nirik> mitr: it increases testing needs, but might be doable depending on how we do it.
17:26:52 <kde_tony> Viking-Ice: +1
17:27:06 <nirik> 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 <sgallagh> 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 <Viking-Ice> nirik, -1 that's not what prd's are for
17:27:35 <mizmo> nirik +1
17:27:39 <nirik> Viking-Ice: ok, then what are they for?
17:27:59 <Viking-Ice> 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 <Viking-Ice> "the server community is not a product"
17:28:38 <Viking-Ice> "fedora server is not a product"
17:28:39 <nirik> ok, and how is the 'roles' we intend to produce, test and distribute not part of our product?
17:28:50 <Viking-Ice> "Fedora freeipa server" is a product
17:29:10 <sgallagh> Viking-Ice: Fedora Server is a product in the same way that Microsoft Windows Server 2012 is a product.
17:29:12 <mizmo> 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 <Viking-Ice> nirik, I would say our roles are filesystem,databases,web servers, etc
17:29:50 <sgallagh> mizmo: +1 (that was our original intent as far as I understand it)
17:30:07 <nirik> 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 <Viking-Ice> nirik, yes hence I said we needed to do 3 or more products so we could identify where they would overlap
17:30:49 <nirik> Viking-Ice: I disagree. our roles are specific... not just 'web servers'
17:31:05 <Viking-Ice> nirik, explain
17:31:10 <nirik> or perhaps I am misunderstanding what you were saying there.
17:31:15 <mizmo> 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 <sgallagh> I suspect that we maybe just chose the wrong term by calling this document a "PRD".
17:31:39 <mizmo> how about 'Fedora Server Feature Requirements List'
17:31:52 <Viking-Ice> we can call it fedora common server infrastructure
17:31:58 <mizmo> another term "Functional Requirements"
17:31:59 <nirik> possible 'roles': "LAMP Server with httpd, mariadb, php, $foo php applicaion, $bar php application"
17:32:13 <Viking-Ice> nirik, I call that application stack
17:32:35 <mizmo> 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 <mizmo> is that fair?
17:33:05 <Viking-Ice> mizmo, I would make a product out of wordpress or drupal as an application stack
17:33:13 <Viking-Ice> ready deployable solution
17:33:17 <mizmo> why don't we just avoid using the word product
17:33:23 <nirik> sure, but we are going to commit to producing, testing and distributing specific application stacks.
17:33:30 <mizmo> what would we call 'Fedora Server' if we were avoiding the word 'product'
17:34:03 <mitr> mizmo: Operating System?
17:34:15 <mizmo> mitr, sure let's call it OS
17:34:16 <mizmo> okay
17:34:27 <mizmo> so for the Fedora Server OS, we need to put together a functional requirements document
17:34:34 <tuanta> mitr: OS is just a kind of product
17:34:36 <mizmo> which is essentially a list of the things Fedora Server OS needs to do
17:34:41 <mitr> 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 <mizmo> Fedora Server Platform?
17:34:57 <mizmo> is 'platform' an okay word?
17:35:01 <Viking-Ice> I would say so
17:35:12 <mitr> platform doesn't mean much
17:35:13 <Viking-Ice> it would install the common bits
17:35:20 <mizmo> mitr, that's okay, as long as we get away from the word 'product' since it seems to cause problems
17:35:24 <mitr> 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 <mizmo> 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 <tuanta> "Platform" word could be conflicted with BaseOS Platform, no?
17:36:02 <mizmo> not sure, let's just run with it for now?
17:36:19 <mizmo> Viking-Ice, are you okay with putting together a single functional requirements document for the Fedora Server Platform?
17:36:27 <nirik> or just "Fedora Server" and "Featured Roles" ? man, english is anoying sometimes. ;)
17:36:36 <mizmo> Viking-Ice, that document can include all of the application stacks and roles of interest
17:36:53 <tuanta> +1 nirik. rally annoying ;)
17:37:02 <mizmo> nirik, in a sense it's a form architecture astronauting we're engaging in here I think
17:37:13 <nirik> yeah
17:37:24 <sgallagh> Yeah, I think we're lost in the terminology and that's confusing the concepts
17:37:41 <mizmo> 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 <Viking-Ice> 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 <nirik> 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 <mizmo> nirik, i think we all agree, vocabulary hangups aside
17:38:21 <sgallagh> nirik: Can we make that a formal proposal?
17:38:31 <sgallagh> Because that's something I'd like to see nailed down at least.
17:38:38 <sgallagh> Regardless of how we write the document(s)
17:38:41 <Viking-Ice> nirik, installation method is not what matters here or makes it shine it's the application that does
17:38:44 <nirik> sure, hopefully we can figure out terminology
17:38:46 <sgallagh> I'd like us to agree that this is the visible goal
17:39:15 <nirik> Viking-Ice: sure, but I want to share as much as possible between application stacks...
17:39:41 <Viking-Ice> not to much as in montoring application for example
17:39:51 <Viking-Ice> would not be bart of that base
17:39:55 <nirik> 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 <Viking-Ice> mean part
17:40:05 <Viking-Ice> nirik, yes
17:40:06 <nirik> agreed.
17:40:08 <mizmo> nirik +1
17:40:45 <tuanta> +1 nirik. that makes sense.
17:40:47 <kde_tony> nirik: +1
17:40:56 <sgallagh> nirik: +1
17:41:23 <Viking-Ice> which makes it"
17:41:23 <Viking-Ice> "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 <nirik> 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 <mitr> 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 <nirik> Viking-Ice: +1
17:41:46 <mizmo> mitr +1
17:41:50 <Viking-Ice> mitr, so far snmp works just fine
17:42:01 <mitr> Viking-Ice: Good, so let's get it set up and integrated :)
17:42:08 <sgallagh> nirik: I think that's what I proposed half an hour ago :)
17:42:16 <nirik> 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 <mitr> nirik: yes
17:43:04 <sgallagh> nirik: Yes and no: if we make that a goal, I can direct the OpenLMI team to focus on it.
17:43:04 <nirik> so where are we here?
17:43:08 <mitr> 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 <Viking-Ice> 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 <mizmo> 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 <mizmo> which is... a mission statement / header for the PRD potentially?
17:43:26 <sgallagh> I have a certain amount of resources that I can direct here (which is a nice change from Fedora's history)
17:43:27 <Viking-Ice> yes
17:43:33 <nirik> sure.
17:43:39 <nirik> sgallagh: excellent.
17:43:48 <Viking-Ice> mizmo, not for the prd
17:43:53 <Viking-Ice> ;)
17:43:57 <Viking-Ice> mission statement sure+
17:44:04 <mizmo> Viking-Ice, why not for the prd
17:44:06 <nirik> perhaps we could setup a section in the wiki page for: short term goals, longer term goals? and add ideas?
17:44:28 <mizmo> yeh that sounds good nirik, i can do that now
17:44:29 <Viking-Ice> mizmo, let's not start that dance all over again
17:44:38 <Viking-Ice> ;)
17:44:47 <nirik> mizmo: perhaps call it 'ideas container' or something...
17:44:51 <mizmo> Viking-Ice, i'm completely dumbfounded but have no problem not going into it
17:45:20 <nirik> so, did we get to any conclusion on /topic? or should we move on, did we have another item on agenda?
17:45:21 <Viking-Ice> mizmo, I'll see if I can apply prd to it
17:45:35 <Viking-Ice> but I doubt it will work
17:45:40 <mizmo> #action mizmo to set up short term / long term goals document on wiki
17:45:49 <sgallagh> 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 <mizmo> #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 <Viking-Ice> what was that first-tier stuff again
17:47:02 <Viking-Ice> was that matt's rings to rule them stuff
17:47:34 <mitr> 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 <Viking-Ice> mitr, agreed
17:47:46 <sgallagh> Viking-Ice: No, as discussed on the mailing list
17:47:59 * nirik shudders at ftp
17:48:03 <sgallagh> Basically the set of things we're saying "This is well-integrated and easy to set up"
17:48:07 <mitr> Viking-Ice: == "featured application stack"
17:48:17 <sgallagh> mitr: Thanks, exactly
17:48:28 <Viking-Ice> we should be able to have produced 1,2 preferable 3 single server application products by then
17:48:41 <mizmo> no using the word 'product'! bad word!
17:48:46 <sgallagh> mitr: Yes, one or two simple services would be good too
17:49:14 <mizmo> +1 to sgallagh's proposal
17:49:19 <mizmo> +1 to mitr's suggestion
17:49:35 <nirik> 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 <Viking-Ice> mizmo, well bind for example is not an  "application stacks" it's an application
17:49:58 <sgallagh> nirik: We don't necessarily need to have made that decision yet
17:50:25 <nirik> 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 <Viking-Ice> I would like to have one product to start working on
17:50:45 <Viking-Ice> does iscsi count as a "file server"
17:50:50 <sgallagh> Defining how things get promoted there is more in line with this goal (as I see it)
17:50:50 <sgallagh> Selecting the ones to start on is the obvious next step
17:51:01 <nirik> but what does 'work on' mean? requirements? kickstart? comps group? ansible playbook? raw qcow2 image?
17:51:08 <sgallagh> Viking-Ice: Probably a good idea to pick a "reference implementation"
17:51:24 <mizmo> nirik, i think it would be requirements right? kickstart / comps group / playbook i think are too implementation specific
17:51:37 <nirik> I would think so...
17:51:41 <nirik> at this point
17:51:46 <sgallagh> 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 <Viking-Ice> nirik, installable on hw/vm/container as an single or multiple times would be a requirement
17:52:02 <Viking-Ice> sgallagh, to big
17:52:06 <Viking-Ice> as I have said before
17:52:33 <mitr> 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 <Viking-Ice> 389ds ( standalone ) samba ( standalone ) etc then the freeipa glue on top of that
17:52:52 <Viking-Ice> why not eucalyptus
17:53:00 <Viking-Ice> if we want popular cloud stack
17:53:01 <nirik> 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 <Viking-Ice> to deal with
17:53:49 <mizmo> 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 <Viking-Ice> nirik, not really these application will simply install on  Fedora Server is  common base platform
17:54:04 <Viking-Ice> s/is//'
17:54:12 <sgallagh> 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 <nirik> mizmo: sure, but I don't understand how to do that in this case.
17:54:31 <sgallagh> I think it would be less effort to integrate the FreeIPA stack into our product than 389ds
17:54:37 <nirik> ok, how can I installed "Fedora Server" to work on my application stack?
17:54:43 <sgallagh> And gets us a larger piece of the pie in the process
17:54:46 <Viking-Ice> sgallagh, how so
17:55:01 * mizmo turns into a pumpkin in 6 minutes
17:55:14 <nirik> until we nail down more specifics I don't see how we can 'work on' these specific cases. ;)
17:55:21 <Viking-Ice> 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 <mizmo> i like to talk about these things in terms of people and environments
17:55:52 <mizmo> so why would i want to instlal a free ipa server
17:55:56 <mizmo> what is the human environment around me
17:56:03 <Viking-Ice> authentication
17:56:08 <Viking-Ice> in mixed environement
17:56:13 <sgallagh> Viking-Ice: Let's table this for next meeting.
17:56:13 <sgallagh> I think we're off in the weed.s
17:56:42 <mizmo> e.g. who is the user installing this
17:57:14 <mizmo> 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 <Viking-Ice> 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 <mizmo> which parts of that install / configuration / testing / production process are general to other roles/application stacks
17:58:16 <Viking-Ice> I can as an administrator install all the components that make up freeipa and maintain them separately for example
17:58:23 <sgallagh> 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 <sgallagh> As I said, let's table this for now.
17:59:28 <mizmo> +!
17:59:29 <mizmo> +1
17:59:35 <sgallagh> Did we agree on the general target I proposed? I didn't see many responses
17:59:41 <Viking-Ice> 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 <mizmo> sgallagh, i +1 it
17:59:50 <sgallagh> 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 <sgallagh> +1 to myself
18:00:20 <tuanta> sgallagh: +1
18:00:23 <nirik> sure, +1
18:00:29 <Viking-Ice> +1
18:00:40 <mizmo> #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 <mitr> sgallagh: ... "requirements for an application stack to be promosted to featured status" to be consistent?
18:00:45 <mitr> +1 otherwise
18:01:17 <mitr> (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 <Viking-Ice> makes sense
18:01:24 <kde_tony> +1
18:01:27 <sgallagh> mitr: Yes, sorry. I should have updated that with the follow-up discussion
18:02:02 <mizmo> #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 <sgallagh> I count +6 from voting members
18:02:57 <sgallagh> Thank you mizmo for running the meeting today. Thank you everyone for such... spirited discussion.
18:03:06 <mizmo> hehe
18:03:10 <mizmo> np
18:03:12 <mizmo> #endmeeting