meetingminutes November 2013

meetingminutes@lists.fedoraproject.org

18 participants
44 discussions

Minutes from today's (11-13-2013) cloud WG meeting
by Sam Kottler 13 Nov '13

13 Nov '13

Thanks everyone who was able to make it to the meeting today! For those who weren't able to make it, here are few important links: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeting… Here's a summary of the meeting (link to the HTML version above): ========================================== #fedora-meeting-1: Cloud WG weekly meeting ========================================== Meeting started by samkottler at 17:00:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeting… . Meeting summary --------------- * rollcall (samkottler, 17:02:00) * agenda items (samkottler, 17:05:55) * A few tools need to get packaged for GCE support, primarily gcutil and image_bundle. All of them are free software and on GitHub. (gholms, 17:07:58) * ACTION: samkottler to figure out what's needed in koji to get images built there (samkottler, 17:09:44) * LINK: http://lists.debian.org/debian-cloud/2013/10/msg00004.html (mattdm, 17:12:43) * hguemar is looking to package gcutil and image_bundle (number80, 17:14:13) * LINK: https://code.google.com/p/google-compute-engine-tools/ (gholms, 17:15:18) * LINK: https://github.com/GoogleCloudPlatform/compute-image-packages (samkottler, 17:18:18) * ACTION: mattdm to kick of thread re google scripts vs cloud-init (mattdm, 17:23:49) * governance document review before submission to FESCo (samkottler, 17:25:10) * ACCEPTED: add wording to charter about commiting to membership every 6 months like server wg (+6) (mattdm, 17:40:58) * ACCEPTED: governance charter as of https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627 ratified (mattdm, 17:44:39) * open floor (mattdm, 17:45:35) * we need to figure out our interaction with the server wg and how we define what we're doing (mattdm, 17:53:35) Meeting ended at 17:57:01 UTC. Action Items ------------ * samkottler to figure out what's needed in koji to get images built there * mattdm to kick of thread re google scripts vs cloud-init Action Items, by person ----------------------- * mattdm * mattdm to kick of thread re google scripts vs cloud-init * samkottler * samkottler to figure out what's needed in koji to get images built there * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mattdm (92) * frankieonuonga (77) * samkottler (51) * mrunge (38) * number80 (21) * gholms (16) * nirik (8) * zodbot (5) * croberts (3) * geppetto (2) * dgilmore (1) * rbergeron (0) 17:00:31 <samkottler> #startmeeting Cloud WG weekly meeting 17:00:31 <zodbot> Meeting started Wed Nov 13 17:00:31 2013 UTC. The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:49 <samkottler> #chair frankieonuonga mrunge mattdm rbergeron number80 geppetto 17:00:49 <zodbot> Current chairs: frankieonuonga geppetto mattdm mrunge number80 rbergeron samkottler 17:01:11 <samkottler> anyone I missed? 17:02:00 <samkottler> #topic rollcall 17:02:05 * frankieonuonga is here 17:02:18 * mrunge is here 17:02:19 * gholms takes a seat in the bleachers 17:02:52 * samkottler waits for a few more people to show up 17:03:28 * frankieonuonga suggests three min 17:03:29 <mrunge> imho red_trela said, he didn't had time for this meeting 17:04:16 <mattdm> hi all 17:04:22 <samkottler> hey mattdm! 17:04:25 <mrunge> hey 17:04:28 <number80> hi 17:04:30 <mattdm> sorry I am in a seriously split brain state :) 17:04:39 <gholms> mattdm: Isn't that the norm these days? :P 17:05:01 <mattdm> gholms apparently. :) 17:05:14 <mattdm> I'd take some time off to collect myself but that would just make the problem worse. 17:05:18 <mattdm> so here we are. :) 17:05:23 <samkottler> I have to head into a read-only state at 12:30 17:05:30 <samkottler> mattdm: are you okay with taking over at 12:30? 17:05:32 <mattdm> okay let's go then. :) 17:05:36 <mattdm> samkottler yep 17:05:39 <frankieonuonga> lets play 17:05:40 <samkottler> mattdm: thanks 17:05:45 <frankieonuonga> welcome guys 17:05:51 <frankieonuonga> i mean welcome folks 17:05:55 <samkottler> #topic agenda items 17:06:01 <samkottler> so GCE 17:06:15 <samkottler> I've been talking with the GCE people this past week and have good news 17:06:22 <mattdm> cool 17:06:26 <frankieonuonga> amazing . 17:06:34 <frankieonuonga> whats up ? 17:06:35 <samkottler> there are a few tools that need to get packaged, but all of them are free software and are on github 17:06:39 <mrunge> what is GCE ? 17:06:44 <samkottler> mrunge: google compute 17:06:48 <gholms> Google compute engine 17:06:55 <mrunge> ah, thanks, I see. 17:06:56 <mattdm> Google Compute Engine. A public cloud provider 17:06:56 <number80> samkottler: list them 17:07:19 <frankieonuonga> cool. 17:07:41 <frankieonuonga> samkottler: packaging should be easy 17:07:42 <samkottler> gcutil and image_bundler are the main two 17:07:48 <frankieonuonga> and at least they are open source 17:07:53 <samkottler> s/image_bundler/image_bundle 17:07:58 <gholms> #info A few tools need to get packaged for GCE support, primarily gcutil and image_bundle. All of them are free software and on GitHub. 17:08:20 <mattdm> I looked at the "what does the image need to look like" instructions 17:08:32 <mattdm> it seems like we are mostly in good shape already 17:09:20 <samkottler> I also spoke with dgilmore about how to get images built in koji and we will likely need to work with mikem to write a plugin to handle it 17:09:31 <mattdm> samkottler what format do the images need to be in? 17:09:44 <samkottler> #action samkottler to figure out what's needed in koji to get images built there 17:09:53 <frankieonuonga> samkottler and dgilmore please loop me into it 17:10:03 <frankieonuonga> that is what is needed for koji 17:10:16 <mattdm> samkottler I think they just want a raw disk file, actually. we already make that 17:10:19 <samkottler> frankieonuonga: absolutely, if you want to take charge on that item feel free :) 17:10:20 <frankieonuonga> this should go in line with rel-eng tasks right ? 17:10:30 <samkottler> mattdm: right, but do we need koji to upload it 17:10:39 <frankieonuonga> ok. 17:10:46 <mattdm> samkottler right now dennis uploads the ec2 images by hand 17:10:46 <samkottler> or do we just handle that externally? 17:10:49 <mattdm> koji doesn't do any uploading 17:11:01 <mattdm> we have the start of a separate uploader service for ec2 17:11:18 <mattdm> but it needs polish and finish. (the stuff andrew worked on last summer) 17:12:20 <samkottler> does someone want to take ownership of creating gcutil and image_bundle packages? 17:12:29 <samkottler> I can do a review for them, but I'm pretty swamped this week 17:12:40 <mattdm> we also maybe should look at GCE cloud-init integration 17:12:43 <mattdm> http://lists.debian.org/debian-cloud/2013/10/msg00004.html 17:12:45 <mattdm> gholms ^ 17:12:47 <frankieonuonga> I can take that 17:12:50 <frankieonuonga> not a problem 17:13:02 <frankieonuonga> how soon are they required ? 17:13:22 <mattdm> frankieonuonga it would be pretty nice to have this with F20 17:13:27 <mattdm> so soon :) 17:13:31 <samkottler> frankieonuonga: the sooner the better at this point 17:13:38 <samkottler> yeah, I'd love to get the tools into f20 17:14:04 <frankieonuonga> :-) ok. will look into it and mail you guys tomorrow..but i think i would like to be done by sat 17:14:10 * gholms attempts to find those tools on github 17:14:13 <number80> #info hguemar is looking to package gcutil and image_bundle 17:14:23 <dgilmore> samkottler: we need something out of koji that can run on a releng box and do the uploading 17:14:28 <number80> gcutil is on google code 17:14:41 <samkottler> number80: frankieonuonga already volunteered 17:14:45 <samkottler> you two wanna work together on that? 17:14:59 <samkottler> number80: yeah, I just sent searching again for it, too, and google code is the place 17:15:08 <samkottler> the google folks told me github, not sure why 17:15:18 <gholms> https://code.google.com/p/google-compute-engine-tools/ 17:15:24 <number80> https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/i… 17:15:35 <number80> i found image_bundle, quite well hidden 17:15:46 <mattdm> number80, gholms, samkottler -- looks like debian is going with the cloud-init integration for running *in* the image 17:16:07 <gholms> mattdm: That's the idea, yeah. Do you happen to know if they bothered to ask upstream as well? 17:16:24 <number80> samkottler: ok, i already started with gcutil last week but i'm fine with leaving image_bundle 17:16:26 <number80> #undo 17:16:26 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x128aebd0> 17:16:28 <mattdm> gholms they said that they would but it might take some time. not sure what that's all about 17:16:45 <samkottler> #link https://code.google.com/p/google-compute-engine-tools/ 17:16:49 <frankieonuonga> samkottler: sure we can work on it together with hguemar 17:16:56 <gholms> samkottler: I already posted that one. ;) 17:17:03 <number80> yup 17:17:15 <samkottler> gholms: without hash-link :) 17:17:37 <gholms> samkottler: meetbot has picked up messages that start with links since 2010. 17:17:44 <samkottler> #undo 17:17:44 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x15360710> 17:17:52 <samkottler> gholms: still fresh at this - thanks :) 17:18:05 <gholms> No worries. I'm happy to help. ;) 17:18:18 <samkottler> https://github.com/GoogleCloudPlatform/compute-image-packages 17:18:53 <gholms> I'm a little concerned by that google code page's source browser not actually containing any code, but I guess that's the best we're likely to get. 17:20:26 <samkottler> gholms: yeah, I noticed that too, not really sure what the deal is with it 17:20:30 <samkottler> I can ask the google folks 17:21:01 <samkottler> anyone else got stuff to add before we move on? 17:21:20 * gholms hopes all the bundled libs for gcutil are easy to split out 17:21:27 <mattdm> At some point we will have to decide if we want to configure the instance with cloud-init or google-startup-scripts 17:21:45 <frankieonuonga> mattdm: yeah you are right 17:21:49 <frankieonuonga> i totally agree. 17:22:12 <mattdm> but having them all available seems like a good start :) 17:22:12 <gholms> mattdm: Is the "one image for everything" idea still important? 17:22:12 <samkottler> I don't really like cloud-init all that much, but it's a known beast 17:22:20 <mattdm> samkottler +1 17:22:41 <gholms> cloud-init is kind of annoying, but on the bright side it's portable. 17:22:41 <samkottler> gholms: it is right now, that's a topic for another meeting 17:22:46 <frankieonuonga> can we lay down all pros and cons on email then decide 17:22:52 * gholms nods 17:22:53 <mattdm> +1 to take to email 17:23:00 <frankieonuonga> +1 17:23:12 <samkottler> who wants to kick off that thread? 17:23:49 <mattdm> #action mattdm to kick of thread re google scripts vs cloud-init 17:23:52 <mattdm> me 17:23:52 <number80> +1 17:23:58 <mrunge> +1 17:24:01 <samkottler> thanks mattdm 17:24:45 <samkottler> can we move on to the governance doc? 17:24:56 <number80> yes 17:25:10 <samkottler> #topic governance document review before submission to FESCo 17:25:25 <samkottler> mattdm: this will run longer than 5 minutes, so do you want to take over? 17:25:36 <mattdm> sure 17:25:56 <mattdm> although, um, I think the state of it is "mattdm said he would make some changes and isn't really done doing everything he said he would do" 17:26:06 * nirik has something for open floor if someone can ping me when it gets to that. ;) 17:26:28 * frankieonuonga will ping nirik 17:26:29 <mattdm> also, I think we should take a look at the docs from other groups and regularize language where we can 17:26:40 <number80> just to notice that there were no changes for 2 weeks 17:26:48 <frankieonuonga> is this the PRD? 17:26:50 <mattdm> so my proposal is for me to actually do those things and bring it back next week 17:26:56 <mattdm> frankieonuonga no, governance doc 17:27:01 <number80> frankieonuonga: nope: https://fedoraproject.org/wiki/Cloud/Governance 17:27:01 <mattdm> number80 see above :) 17:27:02 <samkottler> mattdm: isn't it due tomorrow? 17:27:08 <frankieonuonga> I see. 17:27:15 <mattdm> gah. lookit the time. 17:27:31 <mattdm> okay so. new plan. :) 17:27:38 <gholms> Heh 17:28:02 <frankieonuonga> we might need to finlize this thing like now..in terms of pressing issues to be discussed . 17:28:05 <mattdm> I edited the document with the basic changes we agreed to last time. 17:28:15 * samkottler has to go mostly offline now 17:28:20 <mattdm> samkottler kk 17:28:57 <frankieonuonga> so what is basically expected in this doc that is not there 17:29:03 <mrunge> is there anything missing in that document? 17:29:07 <frankieonuonga> are there any issues that need clarification ? 17:29:48 <mattdm> one of the issues in the other documents is quorum 17:30:06 <frankieonuonga> mattdm: kindly expound 17:30:17 <mattdm> eh wait we covered that too 17:30:34 <frankieonuonga> oh yeahâ€¦two meetings ago 17:30:37 <frankieonuonga> that we did . 17:30:37 <number80> a quorum of 5 should be ok 17:30:55 <frankieonuonga> we just need to access that log and do what we agreed 17:30:56 <mattdm> okay, so the other thing is that the server wg has a bit about "Each voting member of the working group will confirm their continued membership every six months." 17:30:59 <mattdm> do we want that? 17:31:13 <frankieonuonga> we had talked about this right 17:31:21 <frankieonuonga> we agreed for now..no way. 17:31:34 <frankieonuonga> reasoning behind it was it is a short time to get things going 17:31:43 <frankieonuonga> especially in a field that is still fresh 17:31:57 <mattdm> frankieonuonga I think this was just a way for making sure everyone involved was still active 17:32:04 <mattdm> not a need for a revote 17:32:07 <number80> that's neat though i'd prefer people resigning by themselves 17:32:11 <mrunge> I don't see any issue with refreshing 17:32:27 <number80> the same 17:32:33 <frankieonuonga> wasnt this voted on in that meeting. 17:32:53 <mattdm> frankieonuonga yeah I just wanted to know if we wanted to add their idea 17:32:54 <frankieonuonga> sorry but I feel we might be having the same conversation again 17:33:03 <mrunge> I agree, when anyone can foresee, he has no time to work in the group, I'd expect him/her to resign 17:33:12 <mattdm> okay, so, sounds like we want to leave it as is. 17:33:34 * frankieonuonga nods 17:33:40 <mattdm> do we want to approve it as it is? 17:33:57 <mattdm> do we actually have quorum to do so? 17:33:57 <frankieonuonga> yes. 17:34:01 <mrunge> so, it's and appointment for lifetime? 17:34:10 <mrunge> s/and/an/ 17:34:13 <frankieonuonga> i think we need that until we are good to go.. 17:34:25 <frankieonuonga> or at least until things are of the ground 17:34:26 <mattdm> mrunge we assume there will be enough natural turnover 17:34:44 <mattdm> other groups went the same way 17:34:45 <number80> mrunge: until you're unable to serve like FPC 17:34:50 <mrunge> mattdm, if we can guarantee that 17:35:00 * croberts croberts is here running late 17:35:12 <mattdm> mrunge what, by making sure we burn everyone out? :) 17:35:18 * frankieonuonga waving at croberts 17:35:29 * mrunge likes fresh ideas from fresh people from time to time 17:35:50 <frankieonuonga> i think if we change ideas too soon when starting we will end up failing 17:35:54 <frankieonuonga> sorry to insist on this 17:36:04 <frankieonuonga> but this was discussed in length earlier 17:36:07 <frankieonuonga> with so many reasons 17:36:10 <samkottler> I'm lurking so I think we have quorum 17:36:15 <mrunge> and refreshing is something like refreshing commitment 17:36:55 <mattdm> mrunge okay, so, like the server wg wording? appointments stay until you step down, but you do need to say you still want to be involved? 17:37:05 <mattdm> I'm okay with either adding that or leaving it open as it is now. 17:37:27 <mattdm> "able and willing", with no hard-coded definition of what that means 17:37:30 <mrunge> mattdm, yes, I like that. that's more encouraging 17:37:54 <mrunge> ...encouraging people to do something, 17:38:22 <mrunge> we might want to change that, e.g time-span, if refreshing just becomes tedious 17:38:33 <mattdm> okay, so: proposal: add wording like server wg's about members confirming their membership every six months 17:38:39 <mattdm> +1 to my own proposal 17:38:45 <frankieonuonga> +1 17:38:49 <geppetto> +1 17:38:49 <mrunge> +1 for that 17:39:10 <number80> +1 17:39:15 <samkottler> +1 17:39:38 <croberts> +1 17:40:00 <mattdm> croberts wait that confuses my counting :) 17:40:11 <mrunge> heh 17:40:27 <mattdm> but anyway 17:40:28 <croberts> :P 17:40:53 <frankieonuonga> :-) 17:40:58 <mattdm> #accepted add wording to charter about commiting to membership every 6 months like server wg (+6) 17:41:06 <mattdm> anything else anyone wants to raise? 17:41:28 <mattdm> i went ahead and did that :) 17:41:52 <mattdm> so: proposal: accept governance charter as https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627 17:42:07 <mattdm> +1 to myself, again 17:42:08 <frankieonuonga> is there any missing content 17:42:19 <frankieonuonga> maybe something to be included ? 17:42:21 <frankieonuonga> i am not sure 17:42:26 <frankieonuonga> that is why i am asking 17:42:46 <mattdm> frankieonuonga Maybe. I like simple. We can always add additional rules / bylaws if needed 17:43:17 <samkottler> remember that we can always amend stuff 17:43:18 <mrunge> do we want to keep the list of members in that document? 17:43:27 <geppetto> mattdm: +1 â€¦ seems simple enough. 17:43:29 <frankieonuonga> ok . sounds fine. I know nothing about this ..so I will just agree 17:43:44 <mrunge> ... if members change, that document needs to be reviewed again... 17:43:45 <mattdm> mrunge I think so, because it's important for that to be easily findable. 17:43:46 <samkottler> mattdm: +1 17:43:57 <frankieonuonga> +1 17:44:04 <number80> mattdm: +1 17:44:05 <mrunge> ok. +1 tjem 17:44:09 <mrunge> then 17:44:15 <mattdm> mrunge i think it's implied that that section can change to match reality 17:44:23 <mattdm> okay so that's 6 17:44:39 <mattdm> #accepted governance charter as of https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627 ratified 17:44:40 <mrunge> I'd expect that kind of information somewhere, mattdm 17:44:53 <mrunge> (members etc.) 17:45:16 * mattdm notes that when the fedora board changed this year, it took 6 months for the list to get updated. :) 17:45:30 <mattdm> okay, so, fesco meeting soon so let's move on. 17:45:35 <mattdm> #topic open floor 17:45:42 <mattdm> nirik? 17:45:47 <frankieonuonga> let me get nirik 17:45:47 <mrunge> yes 17:45:57 <nirik> Just something to ponder on/bring up: 17:46:31 <nirik> how do you folks see the interaction between the server wg and cloud wg? do you want us to handle the server end and you just do images? or you do both? or ? 17:46:57 <nirik> for example, an openstack server is something we might want to make a server role... 17:47:09 <mrunge> well.... 17:47:24 <frankieonuonga> I have a diff opinion 17:47:26 <nirik> I don't know that we need an answer right now, but something to think about? 17:47:26 <mattdm> nirik I think that that's what we're thinking, yes. 17:47:39 <mattdm> nirik looks like we don't have consensus :) 17:47:56 <frankieonuonga> we may need someone on both ends 17:48:00 <mattdm> i think we might provide images for compute hosts in openstack 17:48:06 <frankieonuonga> cause one can not exist without the other 17:48:25 <mrunge> frankieonuonga, no. a server could live without a cloud image 17:48:28 <frankieonuonga> I think that we also need top look at all other platforms 17:48:54 <frankieonuonga> to look i mean 17:49:00 <frankieonuonga> a server could do that 17:49:07 <mrunge> my initial thought saw the cloud wg as wg to provide infrastructure to host cloud images 17:49:20 <number80> nirik: the server WG is quite central due to the various usage, i think that cloud WG will serve as a stakeholder for cloud hosting and we will probably participate to the making and testing 17:49:21 <frankieonuonga> but a server can also exist without having open stack. 17:49:23 <mrunge> and everything in that image will be filled by server wg 17:49:31 <frankieonuonga> there are too many variables 17:50:00 <nirik> right, it's interaction on many levels. ;) 17:50:25 <mattdm> mrunge The Fedora Cloud SIG has traditionally been focused on making Amazon images... in your model there's nothing for us to do. :) 17:50:29 <nirik> there's the bare metal side/server, and then inside cloud instances there could be many servers that people want to run 17:51:08 <frankieonuonga> I think this is something we need to look into for sur e 17:51:10 <frankieonuonga> sure i mean 17:51:20 <mrunge> mattdm, oh yes, there is. but I agreed to shut up ;-) 17:51:27 <mattdm> mrunge lol :) 17:51:43 <mattdm> nirik does that answer your question? heh. 17:51:48 <frankieonuonga> mrunge: dont shut up 17:52:04 <mrunge> frankieonuonga, let's discuss that at a different time 17:52:06 <frankieonuonga> I think this is a healthy conversation 17:52:11 <mattdm> +1 :) 17:52:19 <frankieonuonga> I think we should kick it of on email 17:52:23 <number80> +1 17:52:35 <nirik> yeah, just wanted to start everyone thinking about it. 17:52:44 <frankieonuonga> thanks nirik 17:52:52 <mattdm> frankieonuonga i think this is the 'ZOMG WHAT ARE WE BUILDING?!' thread from last week? 17:53:03 <mattdm> but another thread with a more specific title wouldn't hurt :) 17:53:14 <mattdm> frankieonuonga or mrunge you want to do that? 17:53:25 <mrunge> and I guess, there was an earlier thread as well 17:53:35 <mattdm> #info we need to figure out our interaction with the server wg and how we define what we're doing 17:53:41 <mrunge> mattdm, I can do that 17:53:41 <frankieonuonga> I have already taken a taskâ€¦I dont want to seem like i am hogging 17:53:54 <mattdm> cool mrunge go for it :) 17:53:56 * frankieonuonga thankful that mrunge has taken that 17:54:15 <mrunge> as if my plate wasn't already full enough 17:54:30 <mattdm> I hear you. :) 17:54:35 <mrunge> no, will do that 17:54:35 <frankieonuonga> no offence 17:54:41 <mattdm> okay, so other topics :) 17:54:45 <mattdm> if any. 17:54:46 <frankieonuonga> which reminds me..what happen to that google thing we were to sign for non disclosure or something like that ? 17:54:56 <mattdm> frankieonuonga ping samkottler on that? 17:55:06 <samkottler> frankieonuonga: email me and I'll have them reach out 17:55:06 <frankieonuonga> ok will do 17:55:13 <frankieonuonga> will do 17:55:39 <mrunge> why should there be an nda? it's under ASL, right? 17:55:55 <mrunge> but confirming is better 17:56:57 <mattdm> okay, so I'm going to end the meeting because I need to grab food quick before fesco starts. 17:57:01 <mattdm> #endmeeting

1 0

Abassadors Latam Meeting Logs / Registro de la reunion de embajadores de Latam 2013-11-13
by alejandro perez 13 Nov '13

13 Nov '13

Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fedora_ambassado… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fedora_ambassado… Log: http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fedora_ambassado…

1 0

Summary/Minutes from today's FESCo Meeting (2013-11-13)
by Kevin Fenzi 13 Nov '13

13 Nov '13

=================================== #fedora-meeting: FESCO (2013-11-13) =================================== Meeting started by nirik at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fesco.2013-11-13… . Meeting summary --------------- * init process (nirik, 18:00:02) * #1195 WG autonomy (nirik, 18:03:20) * LINK: https://fedorahosted.org/fesco/ticket/1195 (nirik, 18:03:20) * AGREED: The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed. We expect this will becoming more clear over time. (+8,0,0) (nirik, 18:37:31) * #1196 Set deadline for PRDs (nirik, 18:51:18) * LINK: https://fedorahosted.org/fesco/ticket/1196 (nirik, 18:51:18) * AGREED: 2014-01-13 deadline for working groups to provide product requirement documents to fesco. (+8,0,0) (nirik, 18:59:15) * #1198 Possible changes to Fedora EOL bug procedure (nirik, 18:59:23) * LINK: https://fedorahosted.org/fesco/ticket/1198 (nirik, 18:59:23) * AGREED: defer a week and get more input from bz team. (+8,0,0) (nirik, 19:18:01) * #1199 Ratify Base Working Group governance charter (nirik, 19:18:26) * LINK: https://fedorahosted.org/fesco/ticket/1199 (nirik, 19:18:27) * AGREED: Charter is approved (+7,0,0) (nirik, 19:28:34) * LINK: https://fedoraproject.org/wiki/Cloud/Governance (mattdm, 19:28:55) * #1200 Environments and Stacks WG Governance Document (nirik, 19:28:57) * LINK: https://fedorahosted.org/fesco/ticket/1200 (nirik, 19:28:57) * AGREED: Charter is approved (+7,0,0) (nirik, 19:31:25) * Cloud working group charter (nirik, 19:31:43) * LINK: https://fedoraproject.org/wiki/Cloud/Governance (nirik, 19:31:47) * AGREED: Charter is approved (+7,0,0) (nirik, 19:32:56) * Next weeks Chair (nirik, 19:36:34) * ACTION: sgallagh to chair next week (nirik, 19:37:30) * Open Floor (nirik, 19:37:38) * AGREED: please do not use the official epel branch names if you're not intending to build for epel itself (+7,0,0) (nirik, 19:50:56) Meeting ended at 19:52:59 UTC. Action Items ------------ * sgallagh to chair next week Action Items, by person ----------------------- * sgallagh * sgallagh to chair next week * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (167) * abadger1999 (78) * mattdm (54) * sgallagh (50) * pjones (50) * jwb (46) * notting (39) * jreznik (33) * t8m (27) * pknirsch (20) * mmaslano (19) * dgilmore (19) * mitr (11) * zodbot (10) * w4r3d (3) * tflink (2) * drago01 (1) * ajax (1) -- 18:00:02 <nirik> #startmeeting FESCO (2013-11-13) 18:00:02 <zodbot> Meeting started Wed Nov 13 18:00:02 2013 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 <nirik> #meetingname fesco 18:00:02 <nirik> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:02 <nirik> #topic init process 18:00:02 <zodbot> The meeting name has been set to 'fesco' 18:00:02 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:06 <t8m> hello 18:00:16 * notting is here 18:00:17 <mmaslano> hi 18:00:25 * abadger1999 is here 18:00:26 <sgallagh> .hellomynameis sgallagh 18:00:27 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh(a)redhat.com> 18:01:08 <nirik> morning everyone. 18:01:32 <mitr> Hello 18:02:01 * sgallagh is juggling a number of fires today, so please forgive me if my responses are intermittent 18:02:25 <pjones> yo 18:02:37 <nirik> mattdm: you around? 18:03:02 <nirik> ok, lets go ahead and dive in. 18:03:20 <nirik> #topic #1195 WG autonomy 18:03:20 <nirik> .fesco 1195 18:03:20 <nirik> https://fedorahosted.org/fesco/ticket/1195 18:03:22 <zodbot> nirik: #1195 (WG autonomy) – FESCo - https://fedorahosted.org/fesco/ticket/1195 18:03:24 <nirik> jwb: you around? 18:03:27 <jwb> i am 18:03:38 <sgallagh> nirik: mattdm will be around, he just mentioned disappearing to locate food first 18:03:53 <nirik> fair enough. 18:04:21 * mattdm has food 18:04:41 <pjones> is it soup? 18:04:43 <jwb> are we waiting on me? 18:04:59 <nirik> ok, so I agree with abadger1999 here... this is a difficult thing to write up 18:05:12 <nirik> jwb: no, just wanted you around since you filed the ticket and can add to the discussion? ;) 18:05:20 <jwb> ok 18:05:49 <notting> i do not know that we have a clear enough view where we can define what powers are reserved and what powers are delegated to the states^Wworking groups 18:06:21 <nirik> yeah, it's all kinda still squishy 18:06:38 <nirik> the two areas noted tho have already come up... 3rd party repos and release cycles. 18:06:42 <sgallagh> Proposal: FESCo always has the right to recover any powers it grants to the WGs at need. 18:06:51 <mattdm> pjones it is reheated pad thai 18:06:52 <abadger1999> yeah -- I hope that it might be possible to define in the future but for now it seems more like case-by-case 18:07:04 <pjones> Well, we have representatives in the groups - maybe we can make it their responsibility to raise it on both sides if they think there's a concern, regarding specific issues. 18:07:10 <nirik> sgallagh: I was assuming that was already the case? 18:07:12 <mattdm> I agree with what Toshio said in the ticket 18:07:17 <pjones> i.e. do we actually have to solve this problem for all cases? 18:07:39 <t8m> sgallagh, OK, I think this is implied, however I think we need a mechanism that diverging decisions are escalated or at least announced 18:07:45 <mmaslano> abadger1999: it's not clear to me how draw the line (as you put it) 18:07:48 <jwb> sgallagh, that proposal seems like something you'd do after you actually grant powers to the WGs 18:08:39 <jwb> the specific case taht prompted the broader issue is having packages in the products taht provide .repo files for repositories other than fedora repos. 18:08:43 <sgallagh> jwb: I disagree. After granting powers, deciding that you can take them back would be disingenuous 18:09:01 <pjones> sgallagh: we already have that ability 18:09:04 <mitr> pjones: I think it would be good if we were able to set expectations so that there are few surprises. I'm not sure it's possible. 18:09:07 <pjones> and no, it woudln't. that's absurd. 18:09:16 <jwb> sgallagh, my point was, your proposal isn't really solving the problem. 18:09:19 <nirik> proposal: encourage working groups/liasions to bring to fesco any cases where they plan to diverge significantly from current shared resources or philosophy 18:09:23 <nirik> (ok, that might be to useless0 18:09:25 <notting> jwb: technically, if you say "isn't available in fedora and isn't proprietary", chrome does not fit. 18:09:38 <sgallagh> jwb: Fair enough, I just don't want us locked into any decisions we make today 18:09:40 <jwb> notting, it was the example i was given. is chromium a better example? 18:09:45 <notting> jwb: yes 18:09:48 <jwb> well then assume that 18:09:50 <abadger1999> We could definitely decide on the two specific cases that we know about so far. 18:09:57 <jwb> or assume rpmfusion-free 18:10:04 <pjones> abadger1999: true 18:10:09 <notting> jwb: *bonghits* 18:10:16 <jwb> or assume $some_repo_you_guys_define_as_acceptable 18:10:28 <nirik> so, what are those exact examples? 18:10:41 <dgilmore> we really need to have fesco layout release schedules and lifecycles 18:10:48 <notting> nirik: i think without defining 'shared resources or philosophy', it leaves it rather vague 18:10:56 <nirik> notting: yeah, it does. ;( 18:11:02 <sgallagh> How about distributing RPMs for COPR repos? 18:11:08 <pjones> dgilmore: that's really not what we're talking about right now at all. 18:11:11 <sgallagh> That's a more clear example, I think 18:11:13 <nirik> jwb: can you provide the specific repo cases you were seeing? 18:11:25 <abadger1999> pjones: well, that was the other specific example I was thinking of. 18:11:56 <sgallagh> abadger1999: What was? 18:11:57 <abadger1999> "Can the products define their own separate release schedules and lifecycles" 18:11:57 <pjones> oh, well, okay. 18:12:03 <dgilmore> pjones: its something that cant be up to the Working Groups to decide. but sure 18:12:04 <nirik> dgilmore: thats the next case after this repo one. ;) 18:12:05 <jwb> nirik, chromium is about as acceptable of an example as i can come up with. the general idea is "repo files not fedora" 18:12:11 <dgilmore> nirik: cheers 18:12:29 <pjones> dgilmore: nevermind, I hadn't realized that's where abadger1999 was actually going, thought you were just bringing that up randomly since there was no context. 18:12:30 <jwb> nirik, so if there are limits around what "not fedora" means and we need explicit approval for each repo, fine 18:12:32 <nirik> jwb: but what about them? can we ship them in fedora rpms? can we enable them by default? can we ship them but not enable them? 18:12:41 <dgilmore> pjones: sorry. 18:12:47 <jwb> nirik, can the products enable them by default i believe 18:13:13 <jwb> or point users to them 18:13:16 <nirik> I'd say: no. But they could offer them to the user to accept? 18:13:17 <mattdm> jwb this actually may be a question for _legal_ 18:13:36 <jwb> mattdm, this specific one, sure. the broader question of what autonomy the WGs have isn't 18:14:07 * nirik nods. 18:14:08 <jwb> and if we can't settle on a general method of operation, then we have problems 18:15:05 <jwb> so if FESCo's proposal is "the liaison is responsible for bringing any unclear decisions to fesco"... well that's what we can do but it isn't particularly clear. 18:15:05 <notting> nirik: well, we already have policies on packaging of third-party repo files. so that would be a matter of saying 'these still apply' 18:15:09 <abadger1999> I know it's a departure from precedent but I lean towards allowing enabling by default but retaining fairly tight control over what repos are allowed. 18:15:12 <nirik> so, in this case should we forumate some questions for legal? or? 18:15:34 <jwb> notting, sure. that's why i brought up the question. we have policies saying we don't do it. the draft PRD for Workstation hints at wanting to do it. discuss. 18:15:39 <mattdm> jwb Yeah but this one may not be a good test case for establishing the general 18:15:42 <nirik> notting: right, which is "do not" 18:15:51 <pjones> abadger1999: I really do as well, if only because it affects users' choice of which product they actually want 18:15:52 <jwb> mattdm, so discuss the general without an example. 18:15:53 <notting> nirik: it's "only in %docdir", actually 18:15:54 <mmaslano> jwb: what if we (fesco) just review list of approved decision and decide only about those, which are questionable? 18:16:03 <nirik> notting: ok. 18:16:03 <sgallagh> May I suggest that we're diving into a specific example that should probably have its own FESCo ticket? 18:16:05 <dgilmore> jwb: i guess they bring a proposal to FESCo saying please change this policy 18:16:07 <jwb> mmaslano, possible. 18:16:12 <jwb> dgilmore, consider it brought. 18:16:18 <sgallagh> That we can think on and discuss next week. 18:16:41 <t8m> sgallagh, +1, let's try to at least somehow solve the general problem first 18:16:44 <nirik> abadger1999: so, perhaps 'repos that only contain free software' ? or some other critera? 18:17:25 <dgilmore> pretty sure i was part of FESCo when it was decided to ban them, because someone decided mainting the package in Fedora was too hard, so they pushed an update that basically replaced the package with and enabled .repo file pointing to their external upstream repo 18:17:26 <sgallagh> nirik, abadger1999: Can we please just address this separately from the general question? 18:17:43 <nirik> dgilmore: yep. I recall that as well. 18:17:50 <notting> jwb: hm, "workgroups have autonomy over their content set, over anything that can be resonably considered 'default configuration', and over the implementation of services not provided by the TBD base layer. anything that refers to general fedora policies should be brought for reconsideration in terms of the product split. release cycles & lifetime is all TBD anyway." 18:17:52 <abadger1999> sgallagh: we can but... I don't think we can address the general question with a definite answer. 18:17:57 <jwb> dgilmore, and yet, now we have coprs. designed to do that explicitly ;) 18:18:04 <jwb> LOLOLOLOLOLOL ;) 18:18:15 <sgallagh> abadger1999: Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. 18:18:48 <jwb> sgallagh, again, i'm fine with that but you need to be aware that it's nebulous and possibly error prone 18:18:51 <dgilmore> jwb: sure. things change, maybe its time we changed the policy, adding soem restrictions on what can be in .repo files, but thats likelylegals call on hats okay 18:18:54 <dgilmore> whats 18:19:01 <mattdm> In general, Working Groups should have autonomy over decisions which are "self contained". These decisions do need to stay in line with Fedora's overall guiding principles. When decisions have impact beyond that Working Group (impact on other WGs or on existing Fedora subprojects like rel-eng, qa, design, etc.), FESCo will mediate and ultimately make decisions if need be. 18:19:02 <sgallagh> jwb: More so than a blanket statement about autonomy? 18:19:05 <abadger1999> sgallagh: with the caveat that once we have decided on a few (for some definition of few) we might be able to address the general question. 18:19:05 <mmaslano> sgallagh: +1 I don't see how can we specify boundaries 18:19:29 <sgallagh> abadger1999: I think sensible boundaries may start to appear as we go forward, yes. 18:19:41 <drago01> mattdm: "design" ? 18:19:41 <sgallagh> But let's not derail this meeting thinking up such cases. 18:19:47 <jwb> sgallagh, not moreso, just differently. it means the WG has to read FESCo's mind on what is questionable, instead of FESCo reviewing decisions. 18:19:57 <mattdm> drago01 https://fedoraproject.org/wiki/Design 18:20:26 <abadger1999> liasons should err on the side of caution -- bring to fesco things that are controversial, may have been in conflict with past policy, or represent new directions for fedora. 18:20:55 <t8m> abadger1999, +1 18:20:57 <abadger1999> over time we'll figure out areas where fesco does not have to be involved in future decisions of that sort. 18:21:14 <pjones> I've got an idea. Why don't we leave this as an open question to be discussed occasionally, with everybody keeping an open eye towards the fact that we might eventually have to actually say something about it while they go about their WG work ;) 18:21:39 <sgallagh> pjones: I think you just rephrased my proposal there, so +1 18:21:44 <nirik> pjones: +1, sure. 18:21:47 <abadger1999> pjones: that works for me. 18:21:50 <abadger1999> +1 18:21:52 <pjones> (There, I've invented the FESCo Select Committee On Whether WGs Have Gone Too Damn Far ;) 18:21:52 <mitr> jwb: We've had an example of how expecting FESCo to notice the problematic changes without the change initiator explicitly trying to communicate doesn't work, just las week 18:22:06 <mattdm> jwb does that address your concerns well enough at this point? 18:22:13 <notting> pjones: i'm not sure that *solves* the issue, but it may be reasonable 18:22:25 <pjones> notting: it wasn't intended as a solution, no. 18:22:34 <jwb> mitr, "failing to notice" is exactly what will continue to happen if the WG doesn't think they're decision is controversial 18:22:39 <nirik> mitr: hopefully our liasions will help? 18:22:40 <sgallagh> mitr: How is that relevant? If the WG liason doesn't communicate a controversial chagne to us, it doesn't change anything 18:23:09 <sgallagh> Perhaps we should make that a clear part of the liason job-description? 18:23:17 <t8m> sgallagh, definitely 18:23:20 <nirik> well, it's always going to come down to judgement... 18:23:22 <abadger1999> Note that controversial needs to mean, not just controversial within the WG but within Fedora as a whole, with a knowledge of past history as well. 18:23:38 <mitr> sgallagh: I think therefore that "reading FESCo's mind" is something we actually have to expect and ask, even though it sounds ... kind of difficult 18:23:44 <nirik> unless we say: "all working group decisions must be ratified by fesco" which is insane micromanaging doom. 18:23:45 <pjones> the simple fact of the matter is that if FESCo isn't /paying attention/ to what the WGs do, this whole thing is *going* to fail. 18:24:01 <pjones> and I use that phrase as opposed to "looking over the shoulder" or "backseat driving" on purpose. 18:24:14 <pjones> (or, you know, pick your euphemism) 18:24:14 <jwb> nirik, there's a middle ground 18:24:26 <t8m> which means the FESCO liason role is pretty critical one 18:24:34 <abadger1999> pjones: <nod> Which is kinda why we included the fesco liasons I think... of course with the liasons not actually being on fesco in all cases, it makes things a little bit different. 18:24:40 <notting> alternately: "if a WG is intending to do something against current stated Fedora policies, please raise" 18:24:45 <pjones> t8m: yes. but it also means that WGs and FESCo both need to be keeping that in mind as they go about their business. 18:25:04 <dgilmore> pjones: completely agree, im taking the approach that I have to actively monitor what WG's are doing so i can stay on top of what deliverables will be and if we work out ho to deliver them 18:25:23 <nirik> jwb: sure. agreed, but that middle ground will be a judgement call... either on the liasion's part or fesco or whoever thinks it needs to be discussed by fesco 18:25:53 <nirik> notting: I could agree to that too. 18:25:53 * sgallagh is glad there are three FESCo members on the Server WG. Nothing is likely to sneak by unnoticed there... 18:26:31 <pjones> sgallagh: or that makes it the worst one for that ;) 18:27:23 <abadger1999> notting: although that's not a complete description of the problems that should be raised... there's actually very few things fesco has officially called policy... 18:27:32 <nirik> so, where are we? enough votes to leave this open and continue to look at? enough votes to accept any of the other proposals? new proposal? 18:27:59 <notting> abadger1999: packaging policies, forbidden items, etc. 18:28:08 <notting> update guidelines... there's a lot of things. 18:28:16 <mmaslano> nirik: probably not enough votes, let's vote once again on sgallagh proposal 18:28:35 <t8m> mmaslano, which one? 18:28:59 <abadger1999> notting: But equally, reboot to install updates, one dep solver, backwards compat focus... 18:29:04 <sgallagh> Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. abadger1999's addition: once we have decided on a few (for some definition of few) we might be able to address the general question 18:29:16 <mmaslano> Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. 18:29:30 <mmaslano> sgallagh: yeah, this one +1 18:29:36 <sgallagh> +1 18:29:48 <nirik> +1 sgallagh (I assume that means keeping the ticket open and trying to address it as we move forward more) 18:29:55 <t8m> sgallagh, +1 18:29:56 <sgallagh> nirik: Yes 18:30:05 <notting> i'm leery b/c this doesn't give much guidance on the type of questions to bring. doesn't seem like enough of an answer 18:30:21 <nirik> notting: counter? 18:30:34 <jwb> notting, that's my concern 18:30:36 <abadger1999> <nod> I think we've said a lot of things in this meeting about type of questions to bring... but they aren't reflected in the Proposal. 18:30:54 <notting> nirik: "Specific cases should include anything related to differences from existing Fedora policies or guidelines." 18:31:25 <abadger1999> and also existing practice. 18:31:41 <pjones> yeah, I think "existing practice" is actually the big (and quite vague) on there 18:31:45 <abadger1999> which is the hardest part to nail down. 18:31:49 <abadger1999> <nod> 18:31:56 <pjones> because obviously there will be a big change to existing practice by /having/ the WGs 18:32:04 <sgallagh> At some point, no matter what, this will be a judgement call by the liasons. 18:32:13 <jwb> why you work this out, it's clear you want me to open a ticket specifically for the repo question right? 18:32:20 <sgallagh> Why don't we assume we can trust them to do their jobs properly until proven otherwise? 18:32:20 <pjones> sgallagh: not by the liasons. By the WGs and by FESCo. 18:32:23 <notting> jwb: yes 18:32:26 <abadger1999> jwb: yes please. 18:32:30 * jwb goes to open a ticket 18:32:31 <nirik> yep. please do 18:32:46 <notting> could add "Autonomy over things already decreed as allowed by spins to change can be assumed." 18:33:07 <pjones> sgallagh: the job of the liason is to make sure the WGs and FESCo are communicating appropriately. That includes bringing issues like this up, but mostly it's making sure we're all informed enough to see them coming. 18:33:12 <abadger1999> notting: +1 18:33:52 <nirik> notting: so, what does that give us for full proposal? 18:34:09 <sgallagh> pjones: I agree. I think that's the point I was trying to make, but just putting a certain measure of responsibility on the liason 18:34:19 <sgallagh> nirik: Spaghetti? 18:34:25 <pjones> it's the opposite of what you said, though. 18:34:26 <nirik> yummy. ;) 18:34:46 <notting> "The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed." 18:34:58 <sgallagh> notting: +1 18:34:59 <notting> "We expect that this will become more clear over time." 18:35:14 <nirik> so, this implies closing ticket? 18:35:20 <mattdm> notting +1 18:35:30 <abadger1999> notting: +1 18:35:39 <mmaslano> notting: +1 18:35:45 * abadger1999 doesn't care if we close the ticket or have it as a standing item. 18:35:49 <nirik> sure, +1 18:35:58 <pjones> I think a standing item may still be better, but +1 18:36:06 <abadger1999> It could be like open floor. 18:36:06 <mattdm> I would like to add (maybe just informally) that we don't necessary plan to *block* change, but we just want to _talk about it_. 18:36:20 <t8m> notting, +1 18:36:24 <mitr> notting: +1 18:36:28 <pjones> mattdm: I'd have thought you'd have learned that people read that the same way ;) 18:36:37 <abadger1999> mattdm: well.... I think it all depends on the change and also as the time frame we talk about. 18:36:55 <abadger1999> So at this point... I think it's still case-by-case. 18:36:56 <mattdm> pjones *sigh* 18:37:02 <notting> erm, then "We expect that this separation will become more clear over time, and policies and practices will change over time." 18:37:27 <mattdm> abadger1999 right obviously not all changes are rubber stamped. But we aren't anti progress, or else we wouldn't be doing _any_ of thise. 18:37:31 <nirik> #agreed The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed. We expect this will becoming more clear over time. (+8,0,0) 18:37:32 <abadger1999> notting: +1 18:37:43 <nirik> you want me to amed? its already really long. ;) 18:38:08 * pjones thinks that's good enough. 18:38:14 <nirik> move on? 18:38:27 <sgallagh> please 18:38:38 <nirik> jwb was filing ticket for the repo thing... do we want also another ticket for release cycle? 18:38:56 <dgilmore> nirik: I think its something that needs to be made clear 18:39:02 <abadger1999> nirik: yep. Should we ping pknirsch to do that? 18:39:06 <dgilmore> nirik: so from my perspective please 18:39:18 * pknirsch is lurking! 18:39:21 <pknirsch> whatup! 18:39:25 <nirik> sure. I don't care who does it, but we should ask for input from all the working groups on it. 18:39:45 <nirik> I know there's been talk of different release cycle in the server wg... 18:40:02 <dgilmore> nirik: well if we dont have a consistent release cycle for all products we lead to insanity and confusion 18:40:15 <nirik> dgilmore: +1 from me on that. 18:40:32 <mattdm> release cycle is clearly something that affects us all. 18:40:37 <pknirsch> mhm 18:40:47 <dgilmore> yep, which falls to FESCo to set 18:40:50 <nirik> pknirsch: can you file a fesco ticket about release cycles and needs for the various groups and if it should be the same for all, etc? 18:40:52 <abadger1999> Ah -- also related to the previous proposal... we should make sure to specifically alert all the fesco liasons about the decision and to read the fesco discussion. 18:40:56 <nirik> or I guess I could do it? 18:41:10 <t8m> abadger1999, +1 18:41:20 <nirik> abadger1999: good idea. Would someone be willing to send them all email about it? ;) 18:41:35 <abadger1999> nirik: yep, I'll take that on. 18:41:40 <nirik> and note the release cycle ticket too perhaps? 18:41:47 <ajax> "consistent" and "uniform across products" aren't necessarily the same thing. 18:41:57 <pknirsch> nirik: i can if you want to, or abadger1999 :) 18:42:34 <abadger1999> ajax: <nod> Although I think we probably want uniform across products for at least a few releases while we get our footing. 18:42:34 <pknirsch> at the end of the day though should we mandate a release cycle for all products? also future ones? 18:42:43 <pjones> I don't think they need to all be /the same/ release cycle. I do think they all need to be a part of the same broader plan. 18:42:50 <pknirsch> i mean, if some product decides to only do rolling releases? 18:42:56 <mattdm> pjones +1 broader plan! 18:43:01 <abadger1999> Creating three (or four depending on what base design decides their scope is) is going to be hard enough. 18:43:03 <pknirsch> what that then be shut down? 18:43:26 <pjones> pknirsch: I think "no rolling releases" fits well within "Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices." 18:43:27 <abadger1999> *three or four products 18:43:28 <pknirsch> s/what/would/ 18:43:39 <pjones> pknirsch: i.e. that's not an option right now without more discussion on it specifically 18:43:46 * pknirsch nods 18:44:04 <nirik> pknirsch: hard to say without more details, but that is less of a bad case in my mind than 'product 1 wants to release 6 times a year' 'product 2 wants to release 3 times' etc 18:44:16 <pknirsch> nirik: right 18:44:32 <dgilmore> they need to be on the same release cycle 18:44:33 <pknirsch> as base would have to do lots of releases then 18:44:41 <pknirsch> dgilmore: right 18:44:50 <dgilmore> released on the same day, eol on the same day 18:45:09 <pknirsch> well, one product could decided to eol one release later? 18:45:13 <pknirsch> maybe? 18:45:19 <nirik> anyhow, would someone be willing to file this ticket? I don't know we can/should discuss this without more input right now. 18:45:20 <dgilmore> but doing things like cloud update images monthly should be allowed 18:45:30 <pknirsch> good point 18:45:33 <dgilmore> pknirsch: no eol needs to be the same 18:45:41 <mattdm> even the update images (which I'm all for!) would be nice in broader context. 18:45:57 <pknirsch> dgilmore: hm, thats going to be really tricky though. there will be no possibility for long time releases then 18:45:57 <tflink> if the different products are on different timelines, qa processes like blocker bugs may also need to be changed 18:46:19 <dgilmore> pknirsch: there is, just that all products get it 18:46:21 <pknirsch> dgilmore: but i understand your point 18:46:33 * nirik can file that. ;) 18:46:34 <nirik> Shall we move on ? 18:46:35 <mitr> Let's give this more time - at least in server WG we are not nearly agreed on what we want, perhaps some of the options will be eliminated before this even gets to FESCo 18:46:47 <pjones> mitr: +1 18:46:56 <nirik> mitr: yes, I'll file a ticket and we can collect input. 18:47:03 <abadger1999> nirik: yes please -- we need to discuss this but we probably should do it next week after people have a chance to write ideas into the ticket. 18:47:11 <nirik> or you are saying 'wait to file the ticket even' ? 18:47:33 <pjones> Bludgeoning "it must be this way" policy down is not the way, and we shouldn't do it. What we should do is let people consider what would be best, and then try to arrive at a sensible master plan for the whole thing that includes as much of that as possible. 18:47:50 <nirik> ok, then: 18:48:31 <pjones> s/people/WGs/ 18:48:38 <t8m> pjones, +1 18:48:50 <mattdm> pjones +1 18:48:52 <nirik> I guess I can see starting to collect ideas now, or waiting. 18:49:54 <nirik> proposal: file fesco ticket to collect ideas on lifecycle and release cadence 18:50:10 <abadger1999> I think that timeframe and allocating new resources would be the big things 18:50:50 <nirik> very much so. 18:51:01 * pknirsch nods a lot 18:51:05 * nirik listens to crickets. ok, I'll file and move on then. 18:51:06 <abadger1999> ie: we don't say you can never do that but rather, you can't do that for the next release and you need to talk to X, Y, Z about what human resourcs you need to bring to the table to make it happen. 18:51:18 <nirik> #topic #1196 Set deadline for PRDs 18:51:18 <nirik> .fesco 1196 18:51:18 <nirik> https://fedorahosted.org/fesco/ticket/1196 18:51:19 <zodbot> nirik: #1196 (Set deadline for PRDs) – FESCo - https://fedorahosted.org/fesco/ticket/1196 18:51:29 <nirik> I'm fine with the poposed date in there. 18:52:04 * pjones too 18:52:06 <jwb> um 18:52:13 <t8m> +1 to the proposed date 18:52:15 <pjones> that's two months from today 18:52:17 <jwb> yeah, so it would have been nice to be CC'd on this ticket 18:52:31 <jwb> <- not in fesco. don't get ticket email by default. 18:52:34 <abadger1999> fesco meetings are on wed... maybe tuesday would be a more practical deadline :-) 18:52:53 <nirik> jwb: possibly all liasions would have been good to cc. 18:52:54 <pjones> abadger1999: I think the idea is to give us each a full day to read it 18:52:55 <abadger1999> but yeah, +1 for that week. 18:53:02 * nirik wonders if we should make an alias. ;) 18:53:08 <pjones> abadger1999: which I can certainly get behind. 18:53:11 <pjones> nirik: probably, yes 18:53:15 <abadger1999> or just cc all liasons on all fesco tickets? 18:53:23 <abadger1999> (like the fpc point of contacts) 18:53:30 <t8m> nirik, what about just adding all liaisons to the fesco alias 18:53:49 <t8m> nirik, being there does not give them the power to vote on FESCo :) 18:54:01 <nirik> t8m: it's a list... 18:54:16 <t8m> s/alias/list 18:54:19 <t8m> then 18:54:21 <nirik> abadger1999: we could, we can add anyone to bcc to fesco tickets on trac 18:54:23 <abadger1999> is there a separate fesco list and alias? 18:54:30 <nirik> no alias. it's a lsit. 18:54:36 * abadger1999 sees that answer jsut before he asks it 18:54:55 <nirik> jwb / pknirsch: would you like to get cc'ed on all fesco tickets? or is that too much noise? 18:55:03 <pknirsch> nirik: please do! 18:55:05 <abadger1999> I don't know -- previous fesco's set it up to be private to fesco. 18:55:06 <jwb> i'm fine with it 18:55:25 <abadger1999> so yeah, I'm more +1 to the CC plan. 18:55:38 <t8m> I'd say that FESCo liaison should have most of FESCo member privileges except the voting :) 18:56:01 <nirik> ok, can do. 18:56:02 * abadger1999 really needs to include more context in his messages so people know what he's +1 to and what he's not :-) 18:56:05 <sgallagh> t8m: Isn't voting the *only* privilege? 18:56:07 <notting> and i can't imagine someone would be in a position to be a liason and not be comfortable with excessive amounts of e-mail 18:56:07 <nirik> ok, back to this ticket... shall we vote? or ? 18:56:22 <notting> nirik: yup, that's a date. +1 18:56:25 <abadger1999> +1 18:56:34 <mattdm> +1 18:56:41 <notting> (i.e., it's arbitrary, but it's a defined arbitrary and therefore better than before) 18:56:43 <t8m> sgallagh, well if you do not count receiving more mail as privilege ;) ;) 18:56:44 <sgallagh> nirik: We're voting on the Monday I suggested? 18:56:58 <sgallagh> the 13th? 18:56:59 <mmaslano> +1 to CC 18:57:02 <sgallagh> If so, +1 18:57:36 <abadger1999> sgallagh: correct.. except for mmaslano who's apparently voting on dding liasons to the trac CC :-) 18:58:11 <nirik> so, thats +7? 18:58:17 <nirik> (so far) 18:58:32 <mitr> +1 on the date 18:59:15 <nirik> #agreed 2014-01-13 deadline for working groups to provide product requirement documents to fesco. (+8,0,0) 18:59:23 <nirik> #topic #1198 Possible changes to Fedora EOL bug procedure 18:59:23 <nirik> .fesco 1198 18:59:23 <nirik> https://fedorahosted.org/fesco/ticket/1198 18:59:26 <zodbot> nirik: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198 19:00:08 * jreznik is here to answer question, summary in the ticket 19:00:20 <mattdm> yeah, so I was shocked when I learned it worked this way. 19:00:22 <sgallagh> mattdm: Want to phrase this as a soundbite we can vote on? 19:00:24 <nirik> so, whats the proposed change? 19:01:22 <jreznik> the remaining question is what to do with that reopen issue 19:01:37 <jreznik> otherwise we already do it in the way mattdm proposed 19:01:40 <mattdm> a) leave bugs in needinfo state until the _next_ product as closed b) close as INSUFFICIENT_DATA instead of WONTFIX and c) change the message asking people to either file a new bug or ping an ombudsman of some sort (a role we don't have but I think we should) 19:01:43 <nirik> I'm very - on leaving things open in needinfo personally.. 19:02:00 <jreznik> nirik: for how long? 19:02:06 <mattdm> nirik are you okay with a _longer_ needinfo? 19:02:07 <abadger1999> jreznik: just one clarification -- anyone in the fedora packager group can reopen correct? 19:02:09 <nirik> no. 19:02:16 <notting> only filer can? 19:02:18 <nirik> say you have a f18 bug... 19:02:23 <notting> or no one, b/c we close the product? 19:02:25 <mattdm> notting filer _cannot_ 19:02:28 <mattdm> notting right. 19:02:40 <mattdm> actually, except I can. possibly all packagers can. 19:02:42 <nirik> you provide a patch or detailed info on how to fix it. 19:02:46 <mattdm> but regular users can't. 19:02:46 <jwb> fwiw, the kernel team uses a needinfo period of 2 weeks, then clsoe with insufficient_Data 19:02:54 <nirik> but the maintainer does not get to it. f18 goes eol. 19:02:56 <jwb> regardless of release standpoint 19:03:07 <nirik> the needinfo is wrong there. There's no info needed. It will never get fixed in f18 19:03:15 <mattdm> jwb that's not a big issue because people can reopen. it only becomes a big issue once the whole _release_ is closed. 19:03:23 <jreznik> for c) initially there was "clone a bug" but I think that was jwb who asked me to change that, we wasn't aware of that reopen issue 19:03:32 <mattdm> nirik info is "is this still an issue?" 19:03:47 <nirik> and you clear that and it's a open f18 bug. 19:03:47 <mattdm> cloning is kind of terrible in bugzilla 19:03:49 <jwb> cloning a bug is horrible. please don't do that 19:03:51 <jreznik> nirik: but it could be fixed in next version 19:04:16 <t8m> hmm what about automatically changing the product to next fedora and putting in needinfo and closing if still in needinfo this fedora is closed 19:04:17 <jreznik> jwb: well, c) proposed by mattdm is now - file a new bug 19:04:18 <mattdm> nirik -- i'm okay with forcing an update of the version if we can do that. 19:04:45 <mattdm> jreznik but to be clear I only think that's okay if we give people a longer window. 19:04:52 <nirik> t8m: hard to sort out... and confusing for maintainers that it's not right version 19:05:20 <nirik> mattdm: right, i don't know if thats possible, but I would be ok with that... if you reopen, it forces it against rawhide or last stable or something. 19:05:22 <mattdm> "My bug was closed and Fedora doesn't care about me" is in the top ten things I hear from people when asking for feedback on their experience with us. 19:05:37 <notting> you can't repoen while changing release? or we don't give you an interstitial that allows that? 19:05:49 <jreznik> mattdm: that's the problem - we can't fix all bugs... never, ever... 19:06:17 <sgallagh> I have to run for today, sorry. 19:06:28 <jreznik> and I think it's better to admit we're not able to fix it over letting it open indefinitely and waiting for miracles 19:06:35 <mattdm> notting right now, the users have no option to do either. 19:06:38 <abadger1999> mattdm: note -- this wouldn't change it really... the real problem is that no maintainer is looking at that set of bugs. 19:06:50 <nirik> notting: not sure. I think it won't let non fedorabugs/priv people reopen and change version... or it doesn't make clear you have to do that and won't let it happen until you do 19:07:24 <jreznik> nirik: so the question is if we can grant these privs and how sane it is to grant this privs 19:07:34 <mattdm> I think having a "bug ombudsman" role is really what we need. I'm not volunteering for that (I might have, about 8 years ago...) 19:07:47 <nirik> I don't know... bugzilla folks haven't answered the bug mattdm opened yet. ;) 19:07:50 <jreznik> mattdm: what's bug ombudsman? 19:08:00 <jwb> chief triager. 19:08:03 <jreznik> nirik: so I'll try to check with them 19:08:19 <nirik> bugzapper? :) 19:08:26 <jreznik> jwb: it's sad we don't have triagers anymore but I understand nobody wants to do it... 19:08:33 <mattdm> I hear the point about more honest / real problem / lots of bugs / etc., but it really is leaving a bad taste in users' mouths 19:08:36 <jwb> i do it all day long and i don't want to do it. 19:09:24 <abadger1999> mattdm: I mean -- leaving hte bug open with no comments for multiple releases is still going to leave a bad taste in users' mouths. 19:09:32 <jreznik> mattdm: trust me, I'd be more than happy to close 0 unfixed bugs over 9000... 19:09:34 <nirik> I agree it can be improved... I'm just not clear on what we can do to improve it yet. 19:09:44 <jreznik> abadger1999: yep 19:09:55 <mattdm> abadger1999 yeah, but closing it with no opportunity to respond is like a poke in the eyes on top of that. 19:09:57 <jreznik> it also helps maintainers to clear a bit theirs backlog 19:10:08 <jreznik> mattdm: and we're trying to solve this problem 19:10:09 <nirik> I'm against mattdm's a and b... I think a bug triager/ombudsmen would be great, but not sure who will do it. ;) 19:10:47 <jreznik> mattdm: it was mistake, we weren't aware of this rebase/reopen issue at that time, it's there just one release 19:11:02 <mattdm> jreznik I'm told that it has been the case for several years. 19:11:03 <jreznik> and I'll be more than happy to fix it 19:11:07 <mattdm> I it's hard to test that. 19:11:10 <nirik> proposal: defer a week and ask bz folks for any technical help they can give us and if any folks want to try and be ombudsmen. 19:11:17 <jreznik> mattdm: no, previously we said "clone a bug" and it worked 19:11:37 <mattdm> ah I see. before _that_, was said "reopen", and _that_ worked. 19:12:02 <nirik> right... first break was old versions getting closed to new bugs 19:12:03 <jreznik> but kernel guys were unhappy about clones, kde guys... 19:12:09 <mattdm> When I started this whole mass-closing of bugs at Fedora Core 2 or whenever, I actually added myself to the CC of each one. 19:12:15 <mattdm> and handled any complaints. 19:12:16 <nirik> then cloning fixed that, then it broke with telling people reopen 19:12:28 <jreznik> nirik: yep 19:12:30 <notting> i agree we should advise something that works 19:12:32 <mattdm> But in order for someone to do that now, I think it would be a full-time job. 19:12:34 <nirik> I read thru all the ones I get. 19:12:47 <jreznik> mattdm: it would be more that full time job 19:12:57 <nirik> and if anyone replies to them I'm happy to reopen. I think it's happened once or twice 19:13:06 <jreznik> I try to take a look at least on a few bugs I'm closing but 9000 is 9000 19:13:17 <abadger1999> notting: +1 19:13:21 <notting> *a* proposal could be to lengthen the period before closing, and change the message back to clone 19:13:28 <jreznik> so change the wording? 19:13:31 <notting> if people don't want clones, i'm fine with waiting for bz team ideas 19:13:52 <abadger1999> maybe change wording to "clone or reopen if you're a fedora packager" 19:14:21 <mattdm> jreznik you don't have to look at every one, but it would be good if there were an opportunity for users to get help without feeling abandoned. 19:14:23 <nirik> well, comments still work for users after the version closes? or no? 19:14:26 <jreznik> notting: I'm not sure about that longer period... if one month is not enough, half year would not be enough neither... people react on the warning and eol, in between not many bugs are updated 19:14:37 <jreznik> nirik: yes 19:14:52 <notting> jreznik: i can let that go 19:14:57 <mitr> mattdm: That's almost equivalent to "it would be good if bugs got fixed" - true, but we haven't even started thinking how to do that 19:15:03 <abadger1999> if bz team can provide a fix that's even better but I wouldn't want to keep the wrong advice while waiting :-) 19:15:03 <nirik> then we could add "or comment on this bug to have the maintainer reopen it for you" but that only works if the maintainer or a cc'ed person is looking 19:15:08 <abadger1999> nirik: uhh.... 19:15:10 <notting> but i think we should definitely either change the wording so it gives the users an option that works, or fix the reopening 19:15:11 <jreznik> mattdm: it's fedora - you have to be active to get stuff done sometimes... 19:15:32 <abadger1999> nirik: yeah -- I think many of htese bugs are being closed in the first place because the maintainer isn't actively watching and dealing with the bug. 19:15:35 <nirik> well, we just need to decide wording in the next month or so right? 19:15:36 <jreznik> notting: yep, I'm sad the change caused this issue 19:16:03 <notting> i'm ok with leaving it for a week to get bz maintainer input 19:16:06 <abadger1999> so depending on them to reopen is... less than optimal. 19:16:07 <jreznik> maybe encourage people to try to talk to maintaner? 19:16:21 <abadger1999> notting: +1 19:16:35 <t8m> abadger1999, +1 19:16:35 * nirik is ok with that too. Hopefully they can help us. 19:17:01 <mmaslano> notting: +1 19:17:03 <nirik> mattdm: ok with you? 19:17:03 <t8m> notting, +1 19:17:09 <abadger1999> <nod> and if not we can change the wording next week. 19:17:15 <jreznik> abadger1999: yep 19:17:20 <pjones> notting: +1 19:17:33 <mattdm> nirik Yeah, I can wait. My main concern is making sure users don't feel like their involvement results in a slap in the face. 19:18:01 <nirik> #agreed defer a week and get more input from bz team. (+8,0,0) 19:18:11 <nirik> mattdm: sure, I agree we should make it better for sure. 19:18:26 <nirik> #topic #1199 Ratify Base Working Group governance charter 19:18:26 <nirik> .fesco 1199 19:18:27 <nirik> https://fedorahosted.org/fesco/ticket/1199 19:18:28 <zodbot> nirik: #1199 (Ratify Base Working Group governance charter) – FESCo - https://fedorahosted.org/fesco/ticket/1199 19:18:51 <w4r3d> Hola alguien habla español? 19:18:59 <nirik> note: according to the working groups doc, we should be asking the board to approve these, but I think thats silly and we should do it and ask the board to yell if they have a problem. ;) 19:19:19 <pjones> w4r3d: nyet 19:19:20 <mmaslano> I want to ask hear if everyone is fine that WGs do no vote about their members 19:19:42 <mmaslano> only Env and Stacks agreed on election after year of service 19:19:43 <mattdm> nirik yes, that came basically from https://fedoraproject.org/wiki/Defining_projects, which says "Only the Fedora Project Board announces new Fedora projects." 19:19:53 <mitr> nirik: the Board is supposed to approve the PRDs, not the charters 19:20:42 <w4r3d> Hola tengo una duda 19:21:01 <dgilmore> w4r3d: No esta un reunión 19:21:22 <tflink> w4r3d: https://fedoraproject.org/wiki/Communicating_and_getting_help?rd=Communicat… for irc channels with more spanish speakers 19:21:23 <nirik> mattdm: yeah, I think thats historical and shouldn't matter anymore, but the Board could disagree I guess. 19:21:35 <w4r3d> gracias 19:21:46 <mattdm> nirik yeah. I'm good with let's-approve-them-here-and-send-em-on-for-ack 19:22:09 <nirik> mmaslano: I'm ok with no voting. I'm a little worried that there might be not enough new blood/turnover, but perhaps we can address that when we see it... 19:22:40 <mmaslano> nirik: exactly my point 19:22:45 <mmaslano> how would we do it? 19:23:01 <t8m> mmaslano, I'd prefer if the WG's memebers were voted on but I can live with the governance charters as they are and see and correct if bad things happen latter 19:23:01 <jwb> you pay attention, and you step in as the overseeing body 19:23:11 <nirik> on the other hand voting is bad because we want people who know the area/are technical, and voting is popularity. 19:23:51 <abadger1999> I've been a little surprised at how the WG's have decided to optimize for consistency with the past but... not sure I would meddle. 19:23:53 * jreznik still thinks WG are evolution of SIGs with stamp and can't imagine SIG members would be voted 19:24:26 <mattdm> FESCo elections (and this goes back to the autonomy discussion) are the democratic check on all of this. 19:24:28 <abadger1999> jreznik: heh -- but in a SIG, there wouldn't be a voting member vs non-voting member distinction. 19:24:35 <t8m> nirik, you could say that about FESCo member voting as well 19:24:42 <nirik> t8m: yep. indeed. 19:25:05 <jreznik> abadger1999: actually we tried FKDESCo once in KDE SIG :) with voting members preselected 19:25:43 <nirik> so, +1 from me for the base charter. when/if we see issues with elections/no elections we can step in. 19:25:57 <t8m> +1 agree with nirik 19:25:58 <mmaslano> ok, so I'm +1 for Base WG charter 19:25:59 <notting> i'm +1 to the charter as well. but i can abstain, as i'm on it 19:26:05 <abadger1999> +1 as well 19:26:28 <mitr> jwb: "this doesn't sound quite right but I can't put my finger on it", "there have been more flamewars than usual", "people seem to be leaving"... it's not at all obvious when to step in 19:27:02 <pknirsch> isn't that what the liasions are for though? 19:27:10 <mattdm> +1 to charter 19:27:12 <notting> mitr: well, we did that due to those and other reasosn in the creation of the committees, so...? 19:27:17 <mattdm> and +1 to pknirsch 19:27:20 <notting> (maybe i missed the point of what you said) 19:27:35 <jwb> mitr, *shrug*. FESCo created the WGs. FESCo is the overseer. you get to figure it out 19:27:41 <nirik> any other votes? 19:27:49 <pjones> nirik: I'm +1 to it 19:27:59 <jwb> NOTE: Acting on behalf of the board, i closed board ticket 168 which was opened for Board approval of charters 19:28:07 <jwb> so please just approve the charters 19:28:12 <jwb> and then send the PRDs up 19:28:15 <mattdm> okay awesome. 19:28:17 * jwb points this out to sgallagh 19:28:18 <abadger1999> jwb: Thanks 19:28:34 <pjones> jwb: sgallagh left already, so you may want to point it out individually later 19:28:34 <nirik> #agreed Charter is approved (+7,0,0) 19:28:39 <nirik> thanks jwb 19:28:46 <jwb> pjones, he opened the ticket, so i'm guessing he'll see it 19:28:48 <nirik> there was one further ticket that came in... 19:28:54 <mattdm> so, just at the meeting prior to this one cloud wg approved charter 19:28:55 <mattdm> https://fedoraproject.org/wiki/Cloud/Governance 19:28:57 <nirik> #topic #1200 Environments and Stacks WG Governance Document 19:28:57 <nirik> .fesco 1200 19:28:57 <nirik> https://fedorahosted.org/fesco/ticket/1200 19:28:58 <zodbot> nirik: #1200 (Environments and Stacks WG Governance Document) – FESCo - https://fedorahosted.org/fesco/ticket/1200 19:29:08 <nirik> mattdm: sorry... 19:29:10 <mattdm> (oops, do that first) 19:29:16 <nirik> mattdm: yeah, lets do that one next 19:29:21 <mmaslano> abadger1999: well written 19:29:50 <t8m> +1 at least we'll see whether voting on members or not is better or not 19:29:51 <abadger1999> thanks. Of course, there was lots of other contributors to it ;-) 19:29:52 <nirik> +1 here (again, unsure how voting will work out, but hey) 19:29:54 <mattdm> +1 19:29:59 <mmaslano> +1 19:30:02 <abadger1999> +1 19:30:28 <notting> +1 19:30:56 <pjones> +1 19:31:25 <nirik> #agreed Charter is approved (+7,0,0) 19:31:31 <abadger1999> elections for voting members and the way we handle abstentions are the two main ways this differs from the other charters. 19:31:43 <nirik> #topic Cloud working group charter 19:31:47 <nirik> https://fedoraproject.org/wiki/Cloud/Governance 19:32:01 <mattdm> this is substantially the same as the server one 19:32:07 <pjones> +1 19:32:09 <nirik> sure, +1 19:32:11 <mattdm> +1 19:32:14 <notting> +1 19:32:16 <mmaslano> +1 19:32:29 <abadger1999> +1 19:32:31 <t8m> +1 19:32:56 <nirik> #agreed Charter is approved (+7,0,0) 19:33:35 <nirik> so, we are missing workstation? 19:34:23 <nirik> or wait. 19:35:46 * sgallagh returns 19:36:05 <nirik> yeah, we didn't approve workstation yet right? 19:36:34 <nirik> #topic Next weeks Chair 19:36:38 <nirik> who wants it? 19:36:40 <sgallagh> I haven't done it in a while 19:37:21 <nirik> it's so much fun! 19:37:30 <nirik> #action sgallagh to chair next week 19:37:38 <nirik> #topic Open Floor 19:37:56 <nirik> so the deadline for gov docs is the 15th? do we want to vote on workstation in ticket? or ? 19:38:24 <abadger1999> I don't think there's a hurry to approve -- it was just a deadline for submission. 19:38:32 * nirik notes its very similar to others. ;) 19:38:54 <nirik> ok, any items for open floor? 19:39:08 <sgallagh> Let's vote in tickets and add it to the meeting next week if there are any concerns 19:39:25 <sgallagh> I have one, but it might be more for FPC. 19:39:51 <sgallagh> Ive heard from the RDO folks that they're using the Koji buildsystem to build a EL 6 version of RDO 19:40:15 <sgallagh> This includes dependencies that are replacing copies in RHEL 6, but they aren't pushing these to the EPEL repo. 19:40:27 <sgallagh> They're instead just using Koji and creating a repo of their own. 19:40:29 <nirik> ok, just using private branches/scratch builds? 19:40:45 <sgallagh> It wasn't clear if this was a spirit-of-the-law violation to me. 19:41:34 <pjones> I'm not sure why we care? 19:41:41 <sgallagh> nirik: They originally were using the el6 branch, but I did notice that after our conversation, python-memcached moved to el6-havana 19:41:41 <nirik> well, we allow scratch builds for anything thats free enough to be in fedora, so this seems like it would be ok to me... but possibly copr would be a better place down the road? 19:41:51 <pjones> nirik: exactly 19:41:52 <sgallagh> Yeah, I recommended COPR as well 19:41:57 <abadger1999> I think if the builds aren't going into the fedora/epel repos, Im rpetty sure it's not FPC :-) 19:42:26 <pjones> But... it's builds for RHEL. I realize we're the overseers of EPEL as well, but it's still kind of not our jurisdiction. 19:42:26 <nirik> if they are doing branches they just need to realize that they can't currently ever delete them. ;) 19:42:50 <pjones> abadger1999: exactly 19:43:11 <nirik> now, if they are building stuff thats not ok license wise thats a problem. 19:43:57 <nirik> ok, any other open floor items? 19:44:10 <sgallagh> nirik: Ok, so to be clear, this is a "go ahead, have fun" answer? :) 19:44:29 <abadger1999> sgallagh: That's a good point about the branches too -- if they continued to use el6 it would pollute the branch for people who actually wanted to work on epel6 packages. 19:44:49 <pjones> sgallagh: yes 19:44:51 <abadger1999> i don't see a problem if they're using separate branches and a different repo. 19:44:53 <nirik> sgallagh: as far as I can see based on what I know... 19:45:05 <nirik> abadger1999: well, different repo wouldn't work. 19:45:12 <nirik> oh, rpms repo... sure. 19:45:16 * nirik was reading that as git repo. 19:45:17 <sgallagh> abadger1999: Well, these are el6 branches for packages that exist in base RHEL 19:45:21 <abadger1999> (although they may need something special for buildrequires) 19:45:39 <sgallagh> So theoretically, no one would ever be using those for an official EPEL build, per policy 19:45:53 <nirik> oh, I see. I misunderstood. 19:46:04 <abadger1999> sgallagh: ah.... I see... I think I'd be against reusing the el6 branches for that but it's more theoretical. 19:46:06 <nirik> that does seem like it would be confusing. 19:46:26 <nirik> typically when something lands in rhel the epel version is blocked. 19:46:41 <nirik> but scratch builds still work of course. 19:46:41 <abadger1999> yeah, confusion. git branch -a python-memcached... oh, why is this in epel, isn't it in rhel? 19:46:47 <abadger1999> things like that. 19:46:50 <sgallagh> abadger1999: As I mentioned above: the package that brought this up moved it to el6-havana after we discussed it 19:46:56 <abadger1999> <nod> 19:47:10 <abadger1999> sgallagh: yep. So tell them, please do more of that :-) 19:47:18 <notting> i'm ok with 'please do not use the official epel branch names if you're not intending to build for epel itself' 19:47:40 <nirik> yeah, +1 19:47:58 <t8m> notting, +1 19:48:05 <sgallagh> notting: +1 19:48:41 <mitr> notting: +1 19:49:42 <nirik> ok, do we want to agree to that? or just have sgallagh pass that along? 19:50:14 <abadger1999> notting: +1 19:50:18 <mmaslano> +1 19:50:56 <nirik> #agreed please do not use the official epel branch names if you're not intending to build for epel itself (+7,0,0) 19:51:01 <pjones> sure, I guess? It seems like they were talked to, realized they were wrong, and stopped 19:51:04 <nirik> anything else open floor wise? 19:51:49 * nirik will close out in a minute if not. 19:52:55 * notting has to head off to a different meeting @ 3 anyway 19:52:57 <nirik> Thanks for coming everyone! 19:52:59 <nirik> #endmeeting

1 0

Re: [Ambassadors] REMINDER French Fedora Meeting Today #fedora-meeting-1
by Emmanuel Seyman 12 Nov '13

12 Nov '13

* Reminder [12/11/2013 08:30] : > > This mail is a reminder for today's meeting for the French speaking community. > > Ce mail est un rappel pour la réunion de la communauté francophone. The minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… The logs: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… Emmanuel

1 0

Meeting Summary / November 12, 2013
by Máirín Duffy 12 Nov '13

12 Nov '13

Hi folks! Below find a summary of yesterday's meeting. You can also read it in blog format at http://fedoraserver-wgblog.rhcloud.com/?p=16 . Below the summary, you'll find the meetbot links if you'd like to read the raw logs. Meeting Minutes =============== Here’s a run-down of today’s Server Working Group meeting: Agenda ====== * Can a single server have multiple roles? * Installation of base + roles Can a single server have multiple roles? ======================================== This topic discussion covered the following points: * We agreed that a single server should be able to serve multiple roles. * Testing combinations of roles on the same server will be tricky. There are some known combinations that will not work (for example, FreeIPA isn’t compatible with mod_nss.) * We’ll start with basic, single server roles, and over time we will adde tested combinations. (All agreed.) “A server having multiple roles could be as simple as “In my cost-constrained office, I want my domain controller to also be my email server,” said sgallagh. I pointed out there were some concerns about that approach last week. sgallagh responded, “There was concern about being able to test such things.” “Yeah, testing can be a big pain if we have 10 featured things and you can install any one or any combo of them,” said nirik. “But we could also just say ‘we test each of these things alone, let us know if they interact poorly.’” mitr asked sgallagh, “We aren’t ordinarily concerned about testing a system that has both Firefox and Devhelp installed; isn’t this the same thing?” “At first glance I agree with you,” replied sgallagh. “but with server applications they can sometimes interact with each other in odd ways. Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known example out of the air.)” “Server can have one or more roles,” added Viking-Ice. “There is no doubt about that.” “But we need to be clear what we test in that world,” said nirik. “Yes,” agreed mitr. sgallagh added, “As I said above, I think it must be possible, but we can probably get away with stating that we only test each role in a vacuum.” “We chose a role and we test cover that role,” said Viking-Ice. “Alternatively, when/if we get automated tests,” said mitr, “doing a ‘full install’ and running all the tests on it should be reasonable – but let’s not commit do doing manual work twice.” Evolution asked, “Do we document roles that obviously conflict?” “I would say not,” answered Viking-Ice. “Well in some cases you can in some others you cannot,” simo answered. “In freeipa we use mod_nss… so you won’t be able to use it with another program that depends on mod_ssl. That may change in time to avoid issues, and fedora server contribution may actually help smooth those issues in some cases.” sgallagh also answered, “That would still require testing all of them together to learn whether they conflict.” “We can only guarantee what we test,” said simo. “So perhaps we should start just with bare roles, and in time add explicitly tested combinations.” mizmo brought simo’s proposal to the table and it was supported by everyone: *** Regarding multiple roles on one server, we will start with just bare roles, and in time add explicitly tested combinations. *** Installation of base + roles ============================ mizmo brought up, “It looks like another concern from last week’s minutes, about multiple roles per server, was how to install the server that way.” “You install the base server ( which I call FOSSP, )” replied Viking-Ice, “then install one or more roles.” “Yeh, that makes sense to me,” replied mizmo. “The anaconda UI actually makes this pretty easy… you can set various roles to be compatible / incompatible and let users select.” sgallagh asked, “By way of comps groups?” “Yep,” mizmo replied. “That’s the way to go in my opinion too,” said nirik. mizmo added, “If we have a better answer to comps groups or want to expand on them or fix them, though – it should be possible, I think.” “I think we can agree on this “FedoraOS Server Platform ( FOSSP ) is made available with or without an predefined server role,ready to use ks for traditional method of installation,directly into an isolated or OS container or as an whole-disk images to be used in private/public cloud as instance-store image or standalone server in the cloud itself.” “Way too many decisions in one sentence,” said mitr. nirik responded, “-1 on kickstarts.” “I think kickstart is too implementation-specific, although it’s obviously going to come into play,” added mizmo. “Kickstarts should be supported but not required,” simo added. sgallagh asked nirik, “Can you expand on that?” “Kickstarts only work at install/create time. You can’t for example install foo and then decide to add role bar later,” said nirik. “Kickstarts contain too many site-specific items.” mizmo responded, “If the role was a comps group, you could though,” pointing out how a role could be added on later. “Yes, which is why I think it’s a better solution,” said nirik. “So you’re just opposing pre-generated kickstart files we make available, rather than ‘don’t use kickstart to set up servers,’ I assume?” sgallagh asked nirik. “Yes,” nirik replied. “Nirik,” said Viking-Ice, “We install either the base server or base server + 1 ( and later as has been decide ) or more roles. We test this as is as it comes from us.” “I’d like to see it in anaconda/yum groups personally,” said Evolution. “Kickstart recipes would be good, but as a community thing maybe outside what we’re doing here.” mizmo added, “I don’t think we have a good GUI way to install groups post-install, though.” “That ‘needs to change,’” said mitr. “Mind, it’s not a matter of adding a comps group only; installing a server role should also allow easily invoking a GUI to set up that role as a group.” “That’s one thing actually I want to talk using Cockpit for, when that project finds its feet a bit,” sgallagh pointed out. “Which brings up for me how we still need to discuss personas :) ” said mizmo. Viking-Ice replied, “I think we can drop personas and target and just do the prd’s for roles.” mizmo questioned Viking-Ice, “Then how do you know how to make the decisions if you dont know who the product is for?” “Well, roles should be targeted at personas,” sgallagh said. “Where the persona may simply be “Admin that needs to run a mail server. Or more likely “Admin that needs to be able to manage a groupware suite.” “Right,” said Viking-Ice. “Our audience are administrators, and we do not care at which level or how experienced they are.” “I think we should actually be aiming to target a more junior admin than we traditionally have,” responded sgallagh. “I think it would be good to be clear about our targets,” added nirik. “What kind of personas do you have in mind?” asked simo. “Unix-savvy admin vs clueless admin? Are there any other?” mizmo replied, “Let’s pick that up after the install base + roles topic.” sgallagh said, “For post-install, I was personally envisioning doing something like canned ansible recipes (formulas?)” “Again, tho, the problem is that they are very site specific,” responded nirik. “BTW you can add an role later ( After install via yum or dnf foo )” said Viking-Ice. nirik replied, “If they are comps groups, sure… but if they are, why not use that in the installer to install whatever the person wants? Or they can write their own kickstart.” “Can we agree on goals instead of technology first?” asked mitr. mizmo, sgallagh, and simo agreed to this. Viking-Ice continued, “We provide vm’s and best out of the box experience ( which can be read as few steps to get it going.)” “I think we need to decide only if we want to make it easy to install a ‘role’ and when. Only at anaconda time or at any time?” said simo. mitr proposed a couple of goals: * “Goal 1: automated (“mass”) install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA.)” * “Goal 2: manual install without a supporting infrastructure (e.g. the very first Linux server).” After that we ended up hopping on an etherpad (via piratepad.net) and working through some goals. We got a good set of initial goals and deferred some goals for later discussion, then promoted the document to the wiki, here: https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation_G… We ran out of time and decided not to continue past the original allotted time this week. Further discussion about server role installation goals will take place in this thread on the mailing list. Meetbot Minutes: =============== Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting…

1 0

meeting Minutes 2013-11-12
by Toshio Kuratomi 12 Nov '13

12 Nov '13

Summary: This week's meeting pretty much wrapped up the governance document drafting process. ============================================ #fedora-meeting: Env and Stacks (2013-11-12) ============================================ Meeting started by mmaslano at 13:01:33 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-12/fedora-meeting.2… . Meeting summary --------------- * init process (mmaslano, 13:01:39) * governance draft (mmaslano, 13:05:16) * https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Governance (mmaslano, 13:06:41) * HELP: (bkabrda, 13:10:48) * AGREED: leave proposal as is, but change the part about filling empty seats. Election should happen on january 2015. Who can vote will be worked out later. (+5,-0,0) (mmaslano, 13:37:11) * Voting group to be cla+1 approved (+1:6, 0:0, -1:0) (abadger1999, 14:00:59) * Proposal Elections for half the seats will be held afer every fedora release (approximately 6 months) to match with fesco. Elected members serve for 2 release cycles before needing to stand for re-election Passed (+1:8, 0:0, -1:0) (abadger1999, 14:21:45) * Candidates for the Env and Stack WG are anyone in cla+1 Passed (+1:6, 0:0, -1:0) (abadger1999, 14:23:58) * We'll follow fesco election process on other details not mentioned here Passed (+1:6, 0:0, -1:0) (abadger1999, 14:27:07) * Change few days for lazy consensus to 3 days. Passed (+1:6, 0:0, -1:0) (abadger1999, 14:41:54) * Request trac for ticketing and voting Passed (+1:6, 0:0, -1:0) (abadger1999, 14:45:46) * ACTION: mmaslano will take care of trac request (mmaslano, 14:46:19) * ACTION: abadger1999 to update the election doc and post link to the list and fesco ticket. (abadger1999, 14:59:15) * Open Floor (abadger1999, 14:59:34) Meeting ended at 15:01:29 UTC. Action Items ------------ * mmaslano will take care of trac request * abadger1999 to update the election doc and post link to the list and fesco ticket. Action Items, by person ----------------------- * abadger1999 * abadger1999 to update the election doc and post link to the list and fesco ticket. * mmaslano * mmaslano will take care of trac request * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * abadger1999 (118) * juhp (113) * mmaslano (76) * tjanez (70) * samkottler (41) * bkabrda (29) * j_dulaney (25) * hhorak (18) * zodbot (10) * pkovar (9) * jreznik (7) * sgallagh (5) * pknirsch (2) * hhorak1 (1) * jwb (1) * drieden (1) * handsome_pirate (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

FAmSCo meeting minutes 2013-11-11
by Jiri Eischmann 11 Nov '13

11 Nov '13

Hi, we had another FAmSCo meeting today, mostly discussing swag for F20 cycle. If you'd like to know more, read the minutes: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-11/famsco.2013-11… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-11/famsco.2013-11… Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-11/famsco.2013-11… The next meeting will be on Nov 18th. I'm gonna travelling from tomorrow till Nov 30th. Alejandro Perez will chair FAmSCo meetings in the meantime. Jiri

1 0

2013-11-04 - Fedora QA Meeting - recap
by Adam Williamson 08 Nov '13

08 Nov '13

As always, minutes and IRC transcript available on the wiki at https://fedoraproject.org/wiki/QA/Meetings/20131104 Next meeting is scheduled for 2013-11-11 at 1600 UTC in #fedora-meeting. If you have topics you think we should bring up at the meeting, please add them to the Wiki page at https://fedoraproject.org/wiki/QA/Meetings/20131111 . Thanks! TOPIC: Previous meeting follow-up ======================================================================= * "roshi to write up recap of the graphics test week" - this was done[1] TOPIC: Fedora 20 Beta status ======================================================================= * There was at least one blocker bug known not to be resolved in Beta RC2[2] * We also needed information on #1023556[3] from dlehman * #1004621[4] may possibly be worth considering for FE or blocker status TOPIC: Open floor ======================================================================= N/A Action items ======================================================================= * viking-ice to check his possible resize issue in at least TC6 (ideally RC2) 1. http://scriptogr.am/roshi/post/graphics-test-week-recap 2. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1022206 3. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1023556 4. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1004621 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

[Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
by Dennis Gilmore 08 Nov '13

08 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================== #fedora-meeting: Fedora Base Design Working Group (2013-11-08) ============================================================== Meeting started by pknirsch at 15:00:59 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_desi… . Meeting summary - - --------------- * Governance discussion & draft (pknirsch, 15:12:13) * LINK: https://fedoraproject.org/wiki/Server/Governance_Charter (jwb, 15:17:02) * LINK: https://fedoraproject.org/wiki/Server/Governance_Charter looks good :) (haraldh, 15:19:36) * AGREED: (haraldh, 15:20:05) * AGREED: Proposal: Take the server governance charter and replace the names and present to FESCO for approval (pknirsch, 15:22:11) * ACTION: haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval (pknirsch, 15:23:36) * Regular meeting times (pknirsch, 15:28:03) * Keep meeting time at 15:00 UTC for the time being (pknirsch, 15:33:00) * Base mailing list discussion (pknirsch, 15:33:28) * AGREED: (haraldh, 15:37:11) * AGREED: Stay with fedora-devel mailinglist, use [Base] in subject to indicate emails around Base Design discussions (pknirsch, 15:39:33) * Role of Base Design group discussion (pknirsch, 15:42:57) * LINK: https://fedoraproject.org/wiki/Critical_path_package?rd=Critical_path_packa… (dgilmore, 15:45:34) * LINK: https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&collct… (dgilmore, 15:45:57) * LINK: http://fpaste.org/52688/38392758/ (pknirsch, 16:19:54) * Base definition: installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use (pknirsch, 16:21:30) * Open Floor (pknirsch, 16:25:50) * jreznik working on a communication plan with other WGs (pknirsch, 16:33:25) * ACTION: jreznik working on a communication plan with other WGs (pknirsch, 16:34:04) Meeting ended at 16:41:32 UTC. Action Items - - ------------ * haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval * jreznik working on a communication plan with other WGs Action Items, by person - - ----------------------- * haraldh * haraldh Proposal: Take the server governance charter and replace the names and present to FESCO for approval * jreznik * jreznik working on a communication plan with other WGs * **UNASSIGNED** * (none) People Present (lines said) - - --------------------------- * pknirsch (195) * dgilmore (105) * haraldh (69) * jreznik (68) * jwb (57) * masta (15) * zodbot (9) * kmacleod (1) * sgallagh (1) * Southern_Gentlem (1) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSfRdSAAoJEH7ltONmPFDRu4oQAKCaUJKJ77tMVokEqtCfNNHj BXN5xuB58a3m/9j4G6sSvVd7lYU9Zq+EqJ0ANfQYOiythks3DLUkR7uDzAXHAqvA 5IgmxSa3M/Yu27W1qzAXEcg3sdC7hlybUnRqy0oneX1JbRBiykU852AvaLeqUfsJ e/Um55YvgywIVjBk4p9hJgVBZZRGo74qV4EOXvVYigbGCrMzXisrthJ4dhRb5br4 o4bN/6Ys5zjK3VUuyF6eNKMV7eOzdqPH7HTVWhoo+SC827n8FqMwrvlASEk7GaEd dM3FHboFng5RUqAFocq8GJxGAgn07UeJVYPQlK5GSasbwnfwBJaEbZPeRVpKM6QM yjdkMjlln5kr2HJaN9kHtCTMt5DJgymUjm11MmlP9LEzgxuFOjI480vjSGReHYWB YZMv0Mf80PKpgZvxIR4fxwtpLD/lJSJT7cbDniX0lMtW2WPWVurZGI7qniSy98Wv tfBfovtzbmPg3Gb8cYhw35VeDm/5jSF5+IhA1EfuSUyqADcBAWaeHsaAtHUZNszf c3Wx7rA58h0oEA4HMUYzBQaCWh7e3UPB6kn61YuriuXwMx6aHv5b0fHe6/jF5u0l EpYq74bpLrNEvXyiyY6U4Wli5/XaNzwOubxq9PbUYYvxl6gmfD/aVVW2nI3C3Fju jQD7H6ANNs7RIC//XTHq =/qx5 -----END PGP SIGNATURE-----

1 0

Fedora Chinese Meeting Minutes (2013-11-08)
by Alick Zhao 08 Nov '13

08 Nov '13

Hi all, The IRC meeting minutes tonight are available at the link [1]. Thanks everyone for attending the meeting. In the meeting we talked about FUDCon bid progress, F20 Release Party, and L10N. Please review the proposed ideas and actions. The next IRC meeting will be held on next Friday (2013-11-15). Please come and join the discussion if you can! [1]: http://meetbot.fedoraproject.org/fedora-zh/2013-11-08/fedora-zh.2013-11-08-… ================== #fedora-zh Meeting ================== Meeting started by alick at 13:01:51 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-zh/2013-11-08/fedora-zh.2013-11-08-… . Meeting summary --------------- * 点名 (alick, 13:02:03) * zsun sent regrets for not being able to attend this meeting (alick, 13:07:53) * FUDCON APAC 2014 申办筹备 (alick, 13:11:51) * alick gbraad try to work out the plan document for venue provider by next week (alick, 13:13:53) * ACTION: alick gbraad try to work out the plan document for venue provider by next week (alick, 13:14:02) * HELP: everyone to update the bid wiki page: https://fedoraproject.org/wiki/FUDCon:Bid_for_Beijing_2014 (alick, 13:14:54) * IDEA: 申办维基页的场地同 GNOME 用户组的申办提案（外加地大），列出若干候选。 (alick, 13:17:32) * F20 Release Party (alick, 13:23:56) * shlug找到场地，在静安区 (RobberPhex, 13:28:28) * LINK: https://fedoraproject.org/wiki/F20_release_events (alick, 13:33:24) * IDEA: 北京的 relparty 日期建议为 2013-12-21/22 Sat/Sun (alick, 13:43:48) * IDEA: 北京的 relparty 地点个人建议这次放在学校 (alick, 13:44:56) * ACTION: RobberPhex call for talks for F20 Release Party Shanghai (alick, 13:49:01) * ACTION: alick call for talks for F20 Release Party Beijing (alick, 13:49:23) * 中文翻译 (alick, 13:51:13) * LINK: https://fedora.transifex.com/projects/p/fedora/language/zh_CN/?project=2060 (alick, 14:04:51) Meeting ended at 14:05:24 UTC. Action Items ------------ * alick gbraad try to work out the plan document for venue provider by next week * RobberPhex call for talks for F20 Release Party Shanghai * alick call for talks for F20 Release Party Beijing Action Items, by person ----------------------- * alick * alick gbraad try to work out the plan document for venue provider by next week * alick call for talks for F20 Release Party Beijing * RobberPhex * RobberPhex call for talks for F20 Release Party Shanghai * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * alick (52) * RobberPhex (15) * isyangxin (7) * BadGirl (5) * zodbot (4) * biergaizi (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

meetingminutes November 2013