meetingminutes November 2013

meetingminutes@lists.fedoraproject.org

18 participants
44 discussions

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

29 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, L10N, and others. Please review the proposed ideas and actions. The next IRC meeting will be held on next Friday (2013-12-07). Please come and join the discussion if you can! [1]: http://meetbot.fedoraproject.org/fedora-zh/2013-11-29/fedora-zh.2013-11-29-… ================== #fedora-zh Meeting ================== Meeting started by alick at 13:01:28 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-zh/2013-11-29/fedora-zh.2013-11-29-… . Meeting summary --------------- * 点名 (alick, 13:02:17) * FAS 帐号可以当 OpenID 的。 (alick, 13:09:28) * FUDCON APAC 2014 申办 (alick, 13:15:47) * ACTION: alick post Chinese planning doc to wiki (alick, 13:21:42) * LINK: https://fedoraproject.org/wiki/FUDCon:Bid_for_Beijing_2014 (alick, 13:22:44) * ACTION: alick email to FUDCon organizers to update wiki (alick, 13:24:16) * F20 Release Party (alick, 13:30:09) * LINK: https://fedoraproject.org/wiki/Release_Party_F20_Beijing (alick, 13:30:28) * 中文翻译 (alick, 13:53:31) * 自由讨论 (alick, 14:04:54) * IDEA: IRC 会议开个主题，大家讨论各自报的 bug 的进展 (alick, 14:07:31) * AGREED: 下次IRC会议开展感动中国十佳Bug评选活动 (alick, 14:12:34) Meeting ended at 14:21:08 UTC. Action Items ------------ * alick post Chinese planning doc to wiki * alick email to FUDCon organizers to update wiki Action Items, by person ----------------------- * alick * alick post Chinese planning doc to wiki * alick email to FUDCon organizers to update wiki * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * alick (90) * Robin_cheese_Lee (28) * biergaizi (25) * zsun (21) * zodbot (15) * tonghuix (13) * BadGirl (6) * tiansworld1 (5) * isyangxin (5) * microcai (3) * gcell (2) * CyrusYzGTt (1) * AndChat|631721 (1) * touparx (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

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

27 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-27/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… Here's a summary of the meeting (link to the HTML and text versions above): ========================================== #fedora-meeting-1: Cloud WG weekly meeting ========================================== Meeting started by samkottler at 17:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeting… . Meeting summary --------------- * rollcall (samkottler, 17:00:37) * LINK: https://fedorahosted.org/cloud/ticket/4 (mattdm, 17:04:18) * update on GCE legal and packaging things (samkottler, 17:05:03) * email shk(a)redhat.com if you want to get added to the trusted testers program or want to see the language associated with it (samkottler, 17:05:58) * LINK: http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-pack… (samkottler, 17:06:59) * Fedora.next product branding (samkottler, 17:16:33) * LINK: http://cloud-images.ubuntu.com/locator/ec2/ (jzb, 17:30:52) * LINK: https://aws.amazon.com/marketplace (jzb, 17:31:23) * AGREED: we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses (samkottler, 17:43:44) * put together a team/plan to work on the PRD (samkottler, 17:53:38) * LINK: https://fedoraproject.org/wiki/Cloud_PRD (samkottler, 17:54:17) * open floor (samkottler, 18:02:49) * LINK: https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-… is a good write-up of that meeting (sgallagh, 18:07:03) Meeting ended at 18:23:52 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * samkottler (103) * jzb (52) * mattdm (49) * number80 (38) * frankieonuonga (29) * mrunge (27) * gholms (26) * rbergeron (25) * sgallagh (17) * geppetto (10) * juergh (8) * zodbot (5) 17:00:23 <samkottler> #startmeeting Cloud WG weekly meeting 17:00:23 <zodbot> Meeting started Wed Nov 27 17:00:23 2013 UTC. The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:37 <samkottler> #topic rollcall 17:00:42 * geppetto is here 17:00:44 <samkottler> \o 17:00:50 <rbergeron> heyooooo 17:00:59 <mrunge> heya! 17:00:59 <juergh> hi all 17:01:01 <samkottler> #chair geppetto mrunge number80 rbergeron mattdm frankieonuonga 17:01:01 <zodbot> Current chairs: frankieonuonga geppetto mattdm mrunge number80 rbergeron samkottler 17:01:27 <jzb> howdy 17:01:32 <samkottler> #chair jzb 17:01:32 <zodbot> Current chairs: frankieonuonga geppetto jzb mattdm mrunge number80 rbergeron samkottler 17:01:35 <mattdm> hi just a sec wrapping up Current Exciting Crisis 17:01:42 <gholms> Heh 17:03:49 * samkottler waits another minute for mattdm 17:03:58 <samkottler> we have a lot more people today than I was expecting :) 17:04:18 <mattdm> https://fedorahosted.org/cloud/ticket/4 17:04:27 <mattdm> just fyi :) 17:04:39 <rbergeron> samkottler: you haven't scared everyone off yet 17:04:47 <rbergeron> give it another minute or two :) 17:04:50 <samkottler> *yet* 17:05:03 <samkottler> #topic update on GCE legal and packaging things 17:05:26 <samkottler> so Fedora legal has said that people who wish to sign the google trusted tester document may do so individually 17:05:58 <samkottler> #info email shk(a)redhat.com if you want to get added to the trusted testers program or want to see the language associated with it 17:06:33 <number80> great 17:06:43 <samkottler> frankieonuonga, witlessb, and I started packaging the utlities we'll need 17:06:59 <samkottler> http://fedorapeople.org/cgit/skottler/public_git/google-compute-engine-pack… 17:07:15 <samkottler> help would be much appreciated 17:07:18 <samkottler> commit for everyone! 17:08:02 <mattdm> samkottler awesome thanks 17:08:06 <gholms> Great! How does that help us? 17:08:21 <mattdm> gholms fedora available in more public clouds 17:08:29 <samkottler> gholms: we'll need those tools to make fedora available in gce 17:08:35 <gholms> Wo's going to upload it? 17:08:42 <gholms> *Who's 17:08:54 <number80> samkottler: i could help 17:08:57 <gholms> Not rel-eng, I presume? 17:09:01 <mattdm> gholms eventually, release engineering. once we have it working. 17:09:13 <mattdm> rel-eng uploads ec2, and this is the same. 17:09:23 <gholms> I thought dgilmore wasn't going to do that. 17:09:50 <mattdm> gholms it could be someone working with him. dgilmore doesn't need more things piled on top of him, that's true. 17:09:50 <gholms> (the agreement thing, that is) 17:09:54 <number80> gholms: dgilmore needs moarr people to help him, so we need to get some people to join rel-eng 17:10:05 <gholms> Alrighty 17:10:10 <samkottler> frankieonuonga agreed to be the rel-eng rep a while back 17:10:18 <jzb> number80: what does that entail? 17:10:41 <samkottler> jzb: it'd mainly be scripting stuff to upload to public clouds 17:10:45 <samkottler> tools > humans 17:10:47 <gholms> I'm not trying to stop you or anything; I just want to have a clear picture. 17:11:31 <number80> jzb: plus improving general rel-eng process with more automation 17:11:43 <mattdm> yeah there is a plan to have image uploading be automatic. 17:11:50 <samkottler> it's also possible we could get dgilmore access without signing the document, but that's a whole other discussion 17:13:03 <number80> i'd say no, as it would force someone else to step up into rel-eng 17:13:30 <samkottler> well we should have someone else doing it regardless, but I was just putting that out on the table 17:15:15 <mrunge> esp. when thinking about release cycles, I'd love to see more automation 17:15:37 <rbergeron> automate all the things! 17:15:45 * rbergeron uses overused phrase 17:15:46 <samkottler> #topic +1 17:15:53 <samkottler> #undo 17:15:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x4c516d0> 17:15:55 <samkottler> +1 17:15:57 * rbergeron lulz 17:16:01 <gholms> Heh 17:16:02 <geppetto> :) 17:16:33 <samkottler> #topic Fedora.next product branding 17:16:35 <samkottler> :) 17:17:06 <samkottler> did people get a chance to read the thread on the list? 17:17:17 <mattdm> Yeah -- didn't respond but read it. 17:17:54 <jzb> I threw something out as a starter, I got one reply and I think we were largely saying the same things but slightly differently. 17:18:00 <mattdm> Are we generally in agreement with 17:18:02 <mattdm> Fedora Cloud provides a customizable base image and tools for developing 17:18:04 <mattdm> scale out applications on public and private clouds. 17:18:11 <mattdm> as our overall product? 17:18:14 <number80> yup 17:18:54 <number80> i wished that we added an emphasis on the devops side, but it's only a wording issue 17:19:11 <samkottler> the devops side in what respect? 17:19:18 <samkottler> ephemeralization of infrastructure? 17:19:43 <mattdm> I can get on board with that, although I'm also open to the idea of picking something more specific for the application scale-out approach and focusing around that 17:20:01 <mattdm> eg openshift and/or docker. 17:20:51 <samkottler> I think one thing that ubuntu has done really well in the cloud space is make their stuff extremely general purpose 17:21:06 <juergh> samkottler: +1 17:21:08 <number80> samkottler: not sure, i'm understanding that expression 17:21:31 <mattdm> whereas on the other hand, coreos goes the other way and basically comes batteries-included for a specific purpose. 17:22:01 <number80> It's more about providing tools from end to end of the process: the developer, the operator should use the same image 17:22:04 <mattdm> If I am alone in this, then we can just move on, because I think we can also do general purpose in a very succesful way. 17:22:10 <samkottler> number80: the ubuntu images can run docker, be ephemeral with the latest stuff, are a nice openstack guest standalone, etc. 17:22:20 <number80> samkottler: so we agree ;) 17:22:36 <samkottler> number80: yep, totally 17:23:35 <mattdm> overall, there's a tension between being able to do all of the things and being tailored to do one well. For example, normally one wouldn't want libvirt on a guest image, but that infrastructure will be necessary for selinux-protected docker, so we will want it for that... 17:23:53 <samkottler> mattdm: I don't mind aligning ourselves with certain other projects, but I thnink it's challenging to provide general, widespread value if we do 17:24:01 <mattdm> but it's a _big_ thing to add, so should probably be on the image itself for docker use, rather than installed with cloud-init or otherwise. 17:24:41 <samkottler> I almost feels like we need spins, but for cloud images 17:25:02 <mattdm> samkottler "library of cloud images". yes. 17:25:05 * rbergeron nods 17:25:15 <gholms> Thankfully lots of clouds make image customization a snap, too. 17:25:23 <jzb> samkottler: +1 17:26:29 <samkottler> so then we can produce a base, small image 17:26:36 <samkottler> and other stuff with the "value add" baked in 17:26:49 <samkottler> if you need a multi-tenant docker env, we've got that 17:26:50 <samkottler> etc. 17:26:57 <mrunge> well, I assume, that will confuse users to have a broad library of cloud images 17:27:16 <mrunge> so I'm -1 for (against) specialized images 17:27:27 <number80> the same 17:27:41 <samkottler> confuse users in what way? 17:27:45 <jzb> mrunge: they expect that, especially on AWS 17:27:45 <samkottler> they won't know which one to use? 17:27:57 <number80> i'd rather make it easy to build custom images and have a very bare one 17:28:15 <jzb> number80: we would, but also easy to use off-the-shelf images for specific things. 17:28:16 <mrunge> yeah, or if they see a list of 20 images, what do they do? 17:28:31 <mattdm> jzb +1 to off-the-shelf. 17:28:37 <jzb> mrunge: they pick the one that has the description that matches what they want 17:28:55 <mrunge> jzb, who reads docs? 17:28:55 <jzb> mrunge: this is not uniformed desktop users, this is developers who should be capable of reading a description and picking. 17:29:06 * gholms notes that we had this exact argument with the old spin download page 17:29:14 <samkottler> how many users are able to respin their own images without learning a significant amount of stuff 17:29:18 <jzb> mrunge: the people who choose from umpty-billion different AWS images based on Ubuntu? 17:29:23 <samkottler> remember that we're engineering for the 99% here :) 17:29:27 <gholms> samkottler: In AWS, all of them. 17:29:30 <samkottler> not the people who are in a working group :) 17:29:32 <gholms> Not sure about others. 17:29:40 <number80> jzb: from experience, specialized images always ends up with a lot of unused stuff for 90% of users 17:29:42 <geppetto> I think both extremes will be a bad idea â€¦ you don't want N people all "customizing" the same base into roughly the same baked in image. 17:29:48 <samkottler> gholms: that's not really true, though 17:29:53 <juergh> what about the effort to maintain a whole set of image vs. a bare image and some tools to customize it? 17:30:07 <samkottler> juergh: yep, that's basically what's being proposed 17:30:10 <juergh> think security updates and the likes. 17:30:12 <geppetto> Also the customizing can't be bugfree â€¦ which is a giant negative freeroll. 17:30:13 <samkottler> we'll keep the base image around 17:30:22 <jzb> number80: from experience with... images running in the cloud? 17:30:23 <samkottler> geppetto: mhm 17:30:50 <jzb> number80: this is our "competition" 17:30:51 <samkottler> number80: if the people don't need the stuff on top, then they just use the base image 17:30:52 <jzb> http://cloud-images.ubuntu.com/locator/ec2/ 17:31:23 <jzb> https://aws.amazon.com/marketplace 17:31:27 <number80> jzb: yup, at $dayjob, i'm doing a lot of SaaS migration :/ 17:31:31 <mattdm> So, thinking of the docker use case (just because that's what I'm working with), it's really awesome if there is a pre-made image that I can just launch or download+launch. 17:31:38 * mrunge needs to step out and will come back later 17:31:49 <number80> samkottler: +1 17:32:11 <mattdm> jzb but the cloud-images-locator is just the same as http://fedoraproject.org/en/get-fedora-options#clouds 17:32:36 <juergh> In my experience partners take a bare image, customize it, snapshot it and make that image available to their end users. There's alway some customization necesseray whether you start from a bare image or a specialized iamge. 17:32:59 <juergh> I'm not sold on customized images. 17:33:00 <geppetto> jzb: Is it obvious to other people how all those top 8 entries are different from each other? 17:33:05 <gholms> samkottler: You'vr seen how ridiculously easy EC2's console makes customizing an image, right? 17:33:17 <jzb> mattdm: similar, but my point is that people are capable of navigating things 17:33:41 <mattdm> gholms ridiculous in what sense? :) 17:34:07 <jzb> geppetto: I would hope if someone is doing app development and making some form of informed decision they are capable of reading a description and choosing. 17:34:19 <jzb> geppetto: also, this should not be a bare "the only thing they have is this page" situation 17:34:25 <samkottler> gholms: I wouldn't exactly say that 17:34:33 <jzb> geppetto: once we have soome customized images, we should be promoting them 17:34:34 <samkottler> most people don't build their own AMI's 17:34:54 <gholms> mattdm: Easy enough that I've got people from developers to graphic designers who figured it out on their own. ;) 17:34:56 <jzb> geppetto: e.g. "hey, wanna run docker on Fedora, use <link>" 17:35:16 <gholms> samkottler: From scratch, of course not. But customizi a base image is another story. 17:35:27 <jzb> geppetto: I think we'll put ourselves at a disadvantage having only a base image without any additional value-add images. 17:35:32 <samkottler> again, let's think about actual users 17:35:37 <samkottler> not us, but actual people :) 17:35:38 <jzb> though we should point loudly to the default 17:35:42 <geppetto> jzb: Sure. 17:35:45 <jzb> samkottler: hey, I think. 17:35:55 * jzb thought he was an actual people. 17:36:11 <number80> jzb: for our target, the barest image is itself a value 17:36:16 <gholms> samkottler: I really wish I could show you my data on this. :( 17:36:20 <mattdm> My viewpoint is that we have a pretty decent generic base image right now, and it's not getting very much traction. 17:36:21 * gholms cries 17:36:44 <gholms> mattdm: You know, that's a good point. 17:36:44 <jzb> mattdm: +1 17:36:46 <samkottler> gholms: I don't doubt that it's true, my point is that there are a lot of people who want to use an image without having to "rebake" it 17:37:04 <number80> mattdm: we lacks maintained application stacks :( 17:37:05 <gholms> samkottler: Makes sense 17:37:20 <mattdm> number80 +1 yes. 17:37:27 <number80> i'd rather rely on easily installable SCL than a bunch of images 17:37:41 <samkottler> telling users 'here, launch this AMI and you'll have docker/openshift/whatever' is huge 17:37:55 * gholms nods 17:38:01 <jzb> number80: let me see if I'm understanding this 17:38:05 <frankieonuonga> i am in guys 17:38:08 <frankieonuonga> sorry i am late 17:38:09 <mattdm> what if we kept the library small? three or four things in addition to the base, rather than 20? 17:38:13 <jzb> number80: you feel that offering 20 images is confusing 17:38:22 <jzb> number80: but offering one + shuttling them off to SCLs is not? 17:38:22 <number80> samkottler: we could add a script in user-data for that 17:38:29 <samkottler> 20 images is also insane to test 17:38:38 <samkottler> < 5 is perfect IMO 17:38:47 <number80> jzb: a base image and users are free to install any SCL they need 17:39:03 <jzb> number80: again, that's less confusing than offering it pre-baked? 17:39:07 <geppetto> samkottler: +1 â€¦ extremes of both cases will be pretty bad, IMO. 17:39:13 <jzb> when I can just spin up an Ubuntu image that has what I want? 17:39:43 <mattdm> so, proposal: base image, plus tools for extending (including application stack work), plus 2-4 images preconfigured for specific uses. 17:39:49 <samkottler> mattdm: +1 17:39:49 <jzb> geppetto, samkottler I am in agreement that 20 may be a bit much 17:39:56 <geppetto> mattdm: +1 17:40:00 <jzb> maybe 4 or 5 would be the ideal situation 17:40:26 <jzb> and if we start getting traction, perhaps the larger community will start building + offering more. 17:40:30 <gholms> Not to mention we'd have a lot easier time maintaining and testing just a few images. 17:40:33 <number80> jzb: yes, most of the time, your image will require frying anyway 17:40:43 <number80> n images = n times more QA 17:40:53 * rbergeron thinks there is a healthy balance between gholms's thoughts and samkottler's 17:41:17 <gholms> What if we start with just a few and see where that takes us? 17:41:21 <jzb> so, mattdm's proposal: ^^ 17:41:27 <geppetto> jzb: My guess is that it'd be a mistake to go above ~7 pre. baked images (roughly what people can remember, easily) 17:41:34 <samkottler> yeah, a few seems perfect for now 17:41:35 <frankieonuonga> i am +1 on gholms idea 17:41:40 <jzb> "base image, plus tools, plus 2-4 images preconfiguted for specific uses" 17:41:40 * rbergeron is also pretty sure that the number of folks that take a base image and then snapshot it after updating it in their own way is pretty large 17:41:48 <number80> if we have people to help maintaining more images, why not, but the main goal of fedora.next is to reduce the scope to get better products 17:41:54 <samkottler> if people like them then we can consider making more 17:41:55 <juergh> rbergeron: exactly 17:42:06 <geppetto> If everyone could stop re-proposing what mattdm said, and just +1 that'd be nice ;) 17:42:08 <number80> samkottler: +1 17:42:14 <jzb> so I'm +1 to mattdm / gholms 17:42:25 <jzb> geppetto: +1 17:42:35 * rbergeron just +1s the last 12 things said :) 17:42:37 <juergh> who/what's do decide what those additional images contain? 17:42:37 <frankieonuonga> i have already voted but just to clarigy gholms +1 17:42:48 * jzb +1's rbergeron 17:42:59 <jzb> (I think we have consensus) 17:43:18 * gholms +1s jzb just because :P 17:43:28 <mattdm> juergh all of us, and depending on who wants to work on what. 17:43:44 <samkottler> #agreed we'll produce a base image, with tools, and 2-4 images preconfigured for specific uses 17:43:49 * samkottler is excited about this 17:44:35 <mrunge> yeah, sounds good to me, the fewer, the better 17:45:06 <rbergeron> well - the worst that can happen is that we can find out that they're all wildly popular 17:45:21 <rbergeron> or that we were wrong about he popularity of one or another and ... figure out how to tune it / make it better / drop it 17:45:27 <rbergeron> learning ftw :) 17:45:42 <samkottler> agreed 17:45:56 <mattdm> rbergeron yes. and we need better metrics. we do not really have those right now. that might be a whole 'nuther issue. 17:46:06 <samkottler> next we need to figure out which ones we'll produce, but we can take that to the list 17:46:19 <number80> i suggest polls 17:46:24 * samkottler has a feeling some people will have opinions about that 17:47:07 <number80> i'd rather go ask actual users than relying on how own distorted perception :o) 17:47:13 <number80> well, mine is distorted 17:47:24 <samkottler> number80: well before we can poll we need some options, but yeah an end-user poll would be great 17:47:25 <mattdm> good polls are hard / expensive. 17:47:47 <frankieonuonga> totally agree with number80 but my only problem is how do we gather pols..do we let people vote as they download an image ? 17:47:48 <samkottler> also, remember that most of our target users currently aren't in the community :) 17:47:57 <mattdm> but could we bracket that for now and come back to it? there's more agenda to get through :) 17:48:03 <jzb> mattdm: +1 17:48:07 <frankieonuonga> mattdm: we could poll on the site and collect results on mysql 17:48:09 <mrunge> +1 17:48:12 <mattdm> the topic right now was product branding 17:48:15 <number80> +1 17:48:26 <mattdm> And this question was the big part of that that I felt was open 17:48:42 <mattdm> other than that, I think jzb's initial response was good except I would s/Docker/CoreOS/g 17:48:46 <samkottler> yeah, the PRD and branding docs will be much easier now 17:49:41 <jzb> mattdm: can we +CoreOS? 17:49:42 <samkottler> so should we take the branding document back to the list and move on? 17:49:56 <jzb> but I'm easy, s/Docker/CoreOS/g works too 17:50:24 <rbergeron> isn't coreOS like a ... whole different nut to crack from docker 17:51:10 <mattdm> Fedora happily includes Docker. CoreOS is a platform for Docker deployment + some other stuff, which is basically directly in competition. 17:51:19 <mattdm> friendly, open source competition :) 17:51:42 <number80> may the best win 17:52:04 <jzb> as long as it's us 17:52:08 <jzb> :-) 17:52:12 <frankieonuonga> :-) 17:53:09 * rbergeron looks back to samkottler's branding document question 17:53:24 <mattdm> yeah, +1 to back to the list and next item 17:53:38 <samkottler> #topic put together a team/plan to work on the PRD 17:54:03 <frankieonuonga> just as a reminder...what was PRD again ? 17:54:09 * rbergeron poked away some lsat week. 17:54:17 <samkottler> https://fedoraproject.org/wiki/Cloud_PRD 17:54:33 * samkottler is planning on working on it on friday and maybe tomorrow depending on how bored he gets 17:54:35 <rbergeron> but slowly. and having help would be teh awesomes so i am not feeling sad and lonely and wondering if i'm doing the right thing :) 17:55:13 * frankieonuonga offers to help samkottler 17:55:17 <jzb> rbergeron: will try to poke at it more this weekend 17:55:29 <jzb> rbergeron: will be doing the traditional gorging tomorrow and Friday 17:55:40 <rbergeron> jzb: TURKEEEEEEE 17:55:43 <samkottler> remember that we agreed to try and get it done by december 15th 17:55:47 <samkottler> which is kinda soon 17:56:02 <samkottler> rbergeron: don't remind me 17:56:04 <number80> rbergeron: i did some proof-reading this afternoon, and i plan to import openstack personas so we could grok our own personas 17:56:24 <frankieonuonga> we use cloud stack where i work so i can do that 17:56:39 <jzb> frankieonuonga: +1 17:56:47 * jzb says, wearing CloudStack PMC hat. 17:56:52 <samkottler> do we want individual personas for each private cloud impl? 17:57:06 <rbergeron> number80: cool, thanks 17:57:12 <rbergeron> samkottler: yeah. it's very soon :) 17:57:28 <number80> jzb: i prefer my yellow shiny eucalyptus t-shirt :P 17:57:37 <rbergeron> frankieonuonga: you just made jzb and ke4qqq smile, lol 17:57:46 <rbergeron> number80: that's because it's an epic shirt 17:57:51 <number80> \o/ 17:57:53 <rbergeron> samkottler: impl? 17:57:56 <frankieonuonga> :-) always a pleasure to ...plus ke4qqq is a huge help 17:58:03 <rbergeron> sorry, my head isn't right 17:58:08 <frankieonuonga> thanks mate 17:58:22 <jzb> samkottler: probably 17:58:58 <frankieonuonga> I would say 2 people in each 17:58:58 <number80> sorry, let's focus 17:59:04 <frankieonuonga> if possible 17:59:44 <samkottler> the PRD is just the kind of thing that requires hammering away on 17:59:44 <number80> (besides fesco meeting in one minute) 18:00:01 <number80> samkottler: +1 18:00:09 <samkottler> anyone have anything else to add on the PRD? 18:00:32 <samkottler> rbergeron: implementation 18:00:39 <rbergeron> samkottler: AHHHH 18:01:47 <samkottler> can we bump the release/lifecycle discussion to next week? 18:01:58 <number80> +1 18:02:02 <mrunge> +1 18:02:05 <mattdm> samkottler yes that's fine.. 18:02:08 <jzb> samkottler: maybe start on email? 18:02:08 <frankieonuonga> +1 18:02:10 <jzb> but +1 18:02:10 * mattdm has fesco meeting now 18:02:11 <number80> maybe kickstarting the discussion on the list 18:02:21 <samkottler> mattdm: can you kick that off on the list? 18:02:28 <mattdm> samkottler yep 18:02:41 <samkottler> mattdm: danke! 18:02:49 <samkottler> #topic open floor 18:03:09 <samkottler> anyone got anything else before we wrap up? 18:03:14 <frankieonuonga> yes 18:03:14 <sgallagh> Dangerous topic: dividing line of Server and Cloud? (Sorry if this was discussed earlier, just got here) 18:03:34 <frankieonuonga> I will wait for sgallagh to finish then i come in with mine 18:03:41 <mrunge> oh yes, good question 18:04:53 <mrunge> and sgallagh IMHO we had that very briefly on the cloud-ml, but didn't come to any conclusion 18:05:00 <frankieonuonga> I want to ask if we have some docs for the server side to find out what their limit is 18:05:02 <sgallagh> So it came up on yesterday's call that it's somewhat ambiguous 18:05:08 <mattdm> It's looking to me that there is going to be some overlap 18:05:12 <sgallagh> s/call/meeting/ 18:05:15 <mattdm> which is not necessarily bad. 18:05:17 <sgallagh> As there should be 18:05:23 <sgallagh> But how much? 18:05:59 <frankieonuonga> I personally think that we need to go in a few months before we know exactly what is happening 18:06:05 <frankieonuonga> but that is just me 18:06:20 <samkottler> sgallagh: it seems like we need to establish where we have the potential to overlap before we can figure out how much overlap is okay? 18:06:41 <mattdm> possibly a lot, at the core level. We're also going to focus on prebaked images for things like docker and openshift 18:06:45 <sgallagh> samkottler: We covered that somewhat in our Server WG meeting yesterday. 18:07:02 <samkottler> sgallagh: I'll re-read the log then, thanks 18:07:03 <sgallagh> https://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-… is a good write-up of that meeting 18:07:10 <mattdm> also, I think that we will be somewhat concerned more with _language_ stacks and server maybe more with _application_ stacks? 18:07:12 * samkottler will make a point of attending those meetings 18:07:36 * frankieonuonga is lost but will figure it out 18:07:52 <sgallagh> mattdm: We're focusing our intentions pretty heavily around the ability to assign "roles" to a server 18:07:57 * number80 gotta go (office building is closing) 18:08:13 <sgallagh> At a high level "i.e. This machine is a domain controller", "This machine is a PostgreSQL server" 18:09:13 <frankieonuonga> by the way guys I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again 18:09:43 <mrunge> and how fits e.g oVirt in this figure? 18:10:10 <mrunge> server based on small images 18:10:47 <mrunge> so, somehow oVirt is a classical data-center product 18:10:52 <mrunge> == a server product 18:11:24 <mrunge> but on one side totally based on small images (for compute nodes) 18:11:33 <mattdm> ovirt node vs. ovirt [whatever the not-node-part-is-called] 18:11:54 <mattdm> sgallagh Another differentiator might be image-based deployment vs. kickstart deployment. 18:11:55 * samkottler likes the idea of operating under the premise that server owns the hypervisor and we own the guest 18:12:05 <jzb> samkottler: +1 18:12:18 <frankieonuonga> +1 samkottler 18:12:30 <mrunge> samkottler, in the oVirt case, we would own both 18:12:40 <mrunge> and the same applies to server WG 18:12:42 <mattdm> who owns 'postgresql server' in that model? 18:12:51 <sgallagh> mattdm: I'm not sure if that differentiates the products really 18:13:13 <sgallagh> (Referring to kickstart vs. image) 18:13:26 <sgallagh> To me, the product is the result of that action 18:13:32 <samkottler> mrunge: no in the ovirt case we'd own neither 18:13:59 <samkottler> mattdm: the server WG would own the things that aren't cloud related 18:14:20 <samkottler> so we could own cloud-init, virtio stuff (maybe?) and they would own all the 'regular' packages 18:14:31 <frankieonuonga> i beg to differ...to some extent i think that our images in some cases are used as servers. 18:14:37 <gholms> Seems reasonable 18:14:38 <frankieonuonga> but i might be wrong 18:15:00 <sgallagh> samkottler: I generally agree on the hypervisor vs. guest thing 18:15:09 <sgallagh> Except of course for the tenancy case... 18:16:00 <sgallagh> i.e. virt-on-virt 18:16:22 <jzb> sgallagh: virt-on-virt? 18:16:34 <samkottler> frankieonuonga: oh yeah of course, we're mainly talking about where the server WG's role ends and ours begins 18:16:41 <samkottler> and I guess then where theirs starts again 18:16:44 <sgallagh> jzb: I set up a virtualized cloud and then rent you the ability to do virt inside my cloud 18:16:54 <samkottler> jzb: russia doll virt 18:16:58 <samkottler> russian doll** 18:17:11 <mrunge> jzb, e.g the undercloud-overcloud thing in OpenStack 18:17:19 <mrunge> jzb, named TripleO 18:17:32 <sgallagh> where virt may be one or more of "kvm, xen, lxc, docker..." 18:17:59 <samkottler> sgallagh: so basically you'd own the 'lowest' hypervisor 18:18:01 <jzb> ah 18:18:10 <mrunge> I'm not sure, if we can divide them at all 18:18:17 <samkottler> mrunge: tripleo is a whole other thing from russian doll virt 18:18:25 <mrunge> (I mean server and cloud) 18:19:13 <mrunge> samkottler, I don't think so. 18:19:31 <mrunge> nevertheless, this is nothing we can decide right now 18:19:49 <samkottler> mrunge: tripleo is using openstack to provision physical hardware 18:19:55 <samkottler> mrunge: and then install a hypervisor on top 18:20:17 <samkottler> vs. virtualizing on top of a hypervisor and then using that hypervisor to run another guest inside of it 18:21:21 <mrunge> samkottler, it's not necessarily the case 18:21:30 <samkottler> do we actually want to vote on something related to this? 18:21:32 <mrunge> but usually folks will implement it that way 18:22:35 <samkottler> frankieonuonga: you had something to bring up? 18:22:41 <frankieonuonga> yeah 18:22:55 <frankieonuonga> I am sorry . I know I had promised the packages for about 1 week ago but I have been badly busy at work. anyway happy to say that Samkottler has been a great help so i should be able to finish by end week. sorry again 18:23:17 <frankieonuonga> i thought it might be easier but there are some things i had over looked 18:23:21 <frankieonuonga> so i am doing what i can 18:23:40 <samkottler> no worries - let us know where/when you need help :) 18:23:52 <samkottler> #endmeeting

1 0

Latam Ambassadors Meeting / Reunion de Embajadores de Latam 2013-11-27
by alejandro perez 27 Nov '13

27 Nov '13

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

1 0

Summary/Minutes from today's FESCo Meeting (2013-11-27)
by Marcela Mašláňová 27 Nov '13

27 Nov '13

=================================== #fedora-meeting: FESCO (2013-11-27) =================================== Meeting started by mmaslano at 18:00:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-27/fesco.2013-11-27… . Meeting summary --------------- * init process (mmaslano, 18:03:04) * #1193 reboots for all updates -- are we ready for this? (mmaslano, 18:03:40) * ACTION: mattdm will contact the Change owner to update the wiki page and release notes (mmaslano, 18:09:08) * #1185 Enable "-Werror=format-security" by default (mmaslano, 18:09:21) * AGREED: Give the go-ahead to mass-file bugs (+5,-0,0) (mmaslano, 18:14:48) * Change owner shouldn't file bugs for those already fixed (mmaslano, 18:15:27) * #1198 Possible changes to Fedora EOL bug procedure (mmaslano, 18:15:36) * defer for a next week, mattdm needs to test it again (mmaslano, 18:17:28) * #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17 (mmaslano, 18:18:10) * ACTION: mmaslano will close the old ticket (mmaslano, 18:20:20) * #1201 Enabling third party repositories (mmaslano, 18:20:34) * ACTION: abadger1999 will rephrase sgallagh question and we will wait for spot answer (mmaslano, 18:28:44) * ACTION: abadger1999 will ask proper questions to legal (mmaslano, 18:40:58) * #1207 provenpackager request (mmaslano, 18:41:06) * ACTION: mmaslano will close this ticket, no -1, auto approval (mmaslano, 18:44:30) * #1208 Request Proven Packager (mmaslano, 18:44:34) * LINK: http://fedoraproject.org/wiki/Provenpackager_policy (abadger1999, 18:48:13) * ACTION: nirik will close both provenpackager tickets and add permission to those users (mmaslano, 18:51:13) * Next week's chair (mmaslano, 18:51:34) * ACTION: mattdm wil be chairman next week (mmaslano, 18:55:42) * Open Floor (mmaslano, 18:55:49) Meeting ended at 18:59:50 UTC. Action Items ------------ * mattdm will contact the Change owner to update the wiki page and release notes * mmaslano will close the old ticket * abadger1999 will rephrase sgallagh question and we will wait for spot answer * abadger1999 will ask proper questions to legal * mmaslano will close this ticket, no -1, auto approval * nirik will close both provenpackager tickets and add permission to those users * mattdm wil be chairman next week Action Items, by person ----------------------- * abadger1999 * abadger1999 will rephrase sgallagh question and we will wait for spot answer * abadger1999 will ask proper questions to legal * mattdm * mattdm will contact the Change owner to update the wiki page and release notes * mattdm wil be chairman next week * mmaslano * mmaslano will close the old ticket * mmaslano will close this ticket, no -1, auto approval * nirik * nirik will close both provenpackager tickets and add permission to those users * sgallagh * abadger1999 will rephrase sgallagh question and we will wait for spot answer * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mmaslano (77) * sgallagh (38) * nirik (37) * abadger1999 (29) * mattdm (27) * zodbot (12) * mitr (7) * jreznik (1) * t8m (0) * pjones (0) * notting (0) 18:00:39 <mmaslano> #startmeeting FESCO (2013-11-27) 18:00:39 <zodbot> Meeting started Wed Nov 27 18:00:39 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:44 <mmaslano> #meetingname fesco 18:00:44 <zodbot> The meeting name has been set to 'fesco' 18:00:49 <mmaslano> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:49 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:01:17 * nirik is sort of here, but dealing with an outage 18:01:21 <mmaslano> t8m appologies from meeting 18:01:28 <mmaslano> how many people are here? 18:02:11 <mitr> Hello 18:02:15 <mattdm> i am 18:02:29 <mmaslano> sgallagh: ? 18:02:40 <sgallagh> .hellomynameis sgallagh 18:02:45 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh(a)redhat.com> 18:02:49 <mmaslano> 5 people 18:02:56 <mmaslano> it's a meeting 18:03:04 <mmaslano> #topic init process 18:03:40 <mmaslano> #topic #1193 reboots for all updates -- are we ready for this? 18:03:44 <mmaslano> .fesco 1193 18:03:45 <zodbot> mmaslano: #1193 (reboots for all updates -- are we ready for this?) – FESCo - https://fedorahosted.org/fesco/ticket/1193 18:03:51 <mmaslano> not sure about status of this one 18:04:05 <mmaslano> imho nothing is happening 18:04:13 <sgallagh> I think we were waiting on someone to update the Change page with the actual implementation 18:04:21 <mattdm> we were looking for changes to the feature page and release notes. 18:04:30 <mattdm> also something in the release notes. 18:04:32 <sgallagh> Shall we ping Richard again? 18:04:58 <mmaslano> preferably not in the ticket 18:05:01 <mmaslano> he didn't reply there 18:05:11 * abadger1999 here 18:06:47 <mmaslano> who shall ping him? 18:07:26 <mattdm> I -think- jreznik was going to? 18:07:41 <mmaslano> jreznik: ? 18:08:05 <nirik> actually from last meeting: 18:08:09 * nirik mattdm to contact the Change owner to update the wiki page and release notes 18:08:11 <nirik> :) 18:08:38 <mattdm> oooohh. 18:08:40 * jreznik can re-check and there's follow up to be announced 18:08:42 <mattdm> okay sorry :) 18:08:47 <mattdm> I will do it. 18:09:08 <mmaslano> #action mattdm will contact the Change owner to update the wiki page and release notes 18:09:21 <mmaslano> #topic #1185 Enable "-Werror=format-security" by default 18:09:25 <mmaslano> .fesco 1185 18:09:27 <zodbot> mmaslano: #1185 (Enable "-Werror=format-security" by default) – FESCo - https://fedorahosted.org/fesco/ticket/1185 18:10:44 <nirik> so, not sure there's more to do here for us.... ? 18:11:11 <mmaslano> sgallagh had last comment there 18:11:36 <mmaslano> from last meeting: wait a week for devel feedback (from people already interested); 2) if there are no show-stoppers identified, mass file bugs; 3) 3 weeks later, enable in rawhide configuration by default 18:11:43 <mmaslano> it's a week, so no action 18:11:59 <sgallagh> So I think we just need to vote: okay to mass-file at this point? 18:12:04 <sgallagh> Sorry... 18:12:12 <mitr> Yes, +1 to start filing bugs 18:12:13 <sgallagh> Proposal: Give the go-ahead to mass-file bugs 18:12:17 <nirik> not much more feedback on devel list I don't think... so I think change owners can move forward on 2) and 3) 18:12:17 <sgallagh> +1 18:12:49 <mmaslano> +1 to mass file bugs 18:12:53 <nirik> sure, +1, but they should make sure not to file against the already fixed ones. 18:14:04 <mmaslano> abadger1999: ? 18:14:12 <sgallagh> nirik: Worst-case, they get closed immediately. I'm not too sure I want to force them to do another mass-rebuild just to limit the bug-filing 18:14:15 <abadger1999> +1 18:14:35 <nirik> well, it's not really mass... it's the 300... but whatever. 18:14:48 <mmaslano> #agreed Give the go-ahead to mass-file bugs (+5,-0,0) 18:15:06 <abadger1999> nirik: Agreed 18:15:27 <mmaslano> #info Change owner shouldn't file bugs for those already fixed 18:15:36 <mmaslano> #topic #1198 Possible changes to Fedora EOL bug procedure 18:15:40 <mmaslano> .fesco 1198 18:15:41 <zodbot> mmaslano: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198 18:16:13 <mattdm> i need to retest this. 18:16:35 <mattdm> I haven't had a chance, though. Vote to defer until more testing is done. 18:16:42 <mattdm> Because _something_ definitely isn't right. 18:16:51 <nirik> fair enough 18:17:28 <mmaslano> #info defer for a next week, mattdm needs to test it again 18:17:43 <mattdm> at LISA I had someone show me bugs he couldn't reopen. saw with my own eyes. 18:18:03 <mmaslano> mattdm: ok, please continue 18:18:07 <mmaslano> in testing :) 18:18:10 <mmaslano> #topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17 18:18:14 <mmaslano> .fesco 1140 18:18:15 <zodbot> mmaslano: #1140 (F20 Self Contained Changes - week 2013-07-10 - 2013-07-17) – FESCo - https://fedorahosted.org/fesco/ticket/1140 18:18:38 <nirik> I think this can be closed after the agreed from last week 18:18:47 <nirik> unless there's new info? 18:19:10 <mmaslano> it's not clear from the last comment 18:19:45 <sgallagh> I left it open mainly for us to keep track of it 18:19:47 <mmaslano> should I close it and it's up to QA? 18:19:54 <sgallagh> mmaslano: That's probably fine 18:20:03 <mmaslano> sgallagh: you know what happens to open tickets like this 18:20:05 <nirik> +1 close. 18:20:15 <sgallagh> mmaslano: They waste time in this meeting? :) 18:20:20 <mmaslano> #action mmaslano will close the old ticket 18:20:34 <mmaslano> #topic #1201 Enabling third party repositories 18:20:37 <mmaslano> .fesco 1201 18:20:38 <zodbot> mmaslano: #1201 (Enabling third party repositories) – FESCo - https://fedorahosted.org/fesco/ticket/1201 18:21:55 <sgallagh> The only question that was asked received a prompt answer. 18:22:05 <mattdm> okay, so, that's: okay for coprs. 18:22:17 <mmaslano> spot answered in the ticket: I see no legal issue with a copr including a "repo" rpm that enables that copr on a user's system, assuming, of course, that the copr is in compliance with the legal rules binding coprs. 18:22:35 <mattdm> I'm pretty happy with agreeing to _that_ reduced subset: repo files for COPRs can be shipped in RPMs. 18:22:47 <mmaslano> I'll speak to Mirek tomorrow and close this ticket 18:22:55 <mmaslano> I guess there are no more issues to solve here 18:23:01 <sgallagh> mattdm: But only in RPMs served outside the main Fedora repos 18:23:12 <mmaslano> sure 18:23:19 <sgallagh> just to be clear 18:23:37 * nirik is still confused. 18:23:38 <mitr> I've generally assumed that the primary case here was things like Chrome, Flash and the like, not COPRs 18:24:06 <sgallagh> mitr: I take away from this that Fedora repos cannot ship repo files pointing outside of Fedora repos. 18:24:06 <abadger1999> nirik: I think what spot answered was "the way coprs currently operates is fine" 18:24:10 <nirik> those repo files for copr repos, are shipped in rpms in the copr right? or are you positing they are in fedora itself? 18:24:11 <mattdm> sgallagh Yes. Although I'm also okay in principle with the larger (still reduced) case of including COPRs-repo-rpms in main fedora repos. 18:24:11 <sgallagh> (Yo dawg...) 18:24:41 <mmaslano> mitr: yeah, but legal said no if I remeber 18:24:42 <sgallagh> nirik: The ruling is that they may not be shipped from Fedora[-updates] repos 18:24:42 <mattdm> COPRs is Fedora (Project) but not Fedora (Distribution). 18:24:48 <abadger1999> He was not asked about whether having the copr yum repos be shipped inside of the Fedora Main Repos would be okay. 18:24:55 <nirik> mattdm: that gets back to adding a burden on legal 18:25:02 <nirik> ok, fine. 18:25:05 <mmaslano> abadger1999: so this will be the next question :) 18:25:09 <sgallagh> abadger1999: That was the EXACT question I posed. 18:25:15 <sgallagh> Did I phrase it ambiguously? 18:25:19 <abadger1999> sgallagh: yes. 18:25:37 <abadger1999> Well -- let me verify... I know that spot answered a different question than that. 18:25:42 <sgallagh> "Specifically, does this mean: On a pristine installed system, I cannot do 'yum install package-providing-repo-for-a-copr'" 18:25:56 <nirik> It wasn't clear to me. 18:25:59 <mattdm> proposal: rephrase that question, wait until next week. 18:26:05 * sgallagh sighs 18:26:16 <nirik> yum install http://copr.whatever/foo-copr.rpm 18:26:18 <mattdm> on rereading it looks clear to me but obviously it isn't to everyone. 18:26:30 <mitr> mattdm: ... and ask jwb whether the answer is relevant to the Workstation WG 18:26:30 <mmaslano> sgallagh: only one question per comment, otherwise it's confusing ;-) 18:26:40 <abadger1999> sgallagh: ah here's where things got ambiguous: 18:26:49 <abadger1999> Right after that example you said: "Or does it also mean that COPR cannot provide an RPM for a particular repo. " 18:27:04 <abadger1999> sgallagh: That's the question that spot answered. 18:27:10 <nirik> I think it might be more clear to list out specific examples. 18:27:16 * sgallagh facepalms 18:27:36 <sgallagh> Ok, someone gooder with words than me should do that. 18:27:55 <mattdm> Okay go abadger1999 :) 18:28:03 <abadger1999> haha :-) 18:28:06 <mmaslano> sgallagh: not me, I understand I can install copr repo and it can be shipped :) 18:28:15 <abadger1999> Okay, I can rephrase sgallagh's question. 18:28:41 <sgallagh> Thank you 18:28:42 <abadger1999> If other people have questions, please add those to the ticket yourselves :-) 18:28:44 <mmaslano> #action abadger1999 will rephrase sgallagh question and we will wait for spot answer 18:29:07 <mattdm> On the rest of the question, do we ant to say something about a) the proprietary repos and/or b) non-COPRs free-software repos? 18:29:26 <mmaslano> I guess Workstation WG asked first 18:29:41 <sgallagh> mattdm: I interpreted this to mean that COPRs and non-COPRs free-software repos should be treated equivalently 18:30:18 <mattdm> As I understood it there is a difference because we already have some responsibility over COPRs repos 18:30:19 <mmaslano> if they obey Fedora licensing 18:31:05 <nirik> mattdm: but no one is reviewing that unless someone reports a problem. 18:31:17 <sgallagh> Well, if we assume the ruling is "Fedora distribution cannot ship repo files for COPRs and other external repos", then this is a moot point 18:31:21 <abadger1999> mattdm: My impression from talking with spot at FPC is that COPR is included in "other third party repos" in terms of Fedora Legal having to vette the packages within them in an on-going manner. 18:31:52 <mattdm> okay, so, let's wait until that is answered then. 18:32:06 <sgallagh> Or add your question as a corrolary on the bug 18:32:06 <abadger1999> mattdm: But -- repos with proprietary software are even more work for Fedora Legal to vette than other third party repositories. 18:32:30 <sgallagh> abadger1999: He said "free software" 18:32:46 <abadger1999> So... it may be easier for Fedora Legal to vette Copr repos than, say, the adobe flash repo but it would still be a lot of extra work. 18:33:25 * nirik isnt sure question 2 of the orig ticket was really answered 18:33:59 <nirik> "Can products make third party repositories discoverable via search terms in some fashion and easily enabled without actually shipping the .repo files" 18:34:09 <abadger1999> sgallagh: he == spot? I was just replying to mattdm's "a) the proprietary repos". 18:34:34 <sgallagh> abadger1999: Ah sorry. Missed the a) portion there. Carry on. 18:35:59 <nirik> I guess the 'putting them in docdir' was answered... not sure how else the 'search terms' would work. 18:36:09 <abadger1999> nirik: yeah, I don't think that was directly addressed -- it seems like it's trying to define a boundary in a big grey zone, though, so it may need to be more specific (have an example). 18:36:30 <nirik> yeah, if so we should ask the workstation wg for examples. ;) 18:37:09 <mitr> nirik: GNOME software would be a likely place 18:37:42 <nirik> mitr: sure, but how? 18:38:08 <abadger1999> I think the limits of "discoverable" and "search terms" probably could get us into contirbutory infringement territory. 18:38:10 <mitr> nirik: ... who cares? appdata, /usr/share/gnome-software/something, hardcoded in the binary, what does it matter? 18:38:36 <nirik> mitr: see above. 18:38:43 <nirik> if we point to specific things, legal has to vet them 18:38:55 <abadger1999> So someone probably needs to say "This is how it would operate" and then Legal could say "that is fine" or "that is not fine". 18:39:06 <nirik> right 18:40:29 <nirik> anyhow, lets move on? I or abadger1999 can ask them for more examples? 18:40:39 <sgallagh> Yes please (to both) 18:40:58 <mmaslano> #action abadger1999 will ask proper questions to legal 18:41:06 <mmaslano> #topic #1207 provenpackager request 18:41:13 <mmaslano> .fesco 1207 18:41:14 <zodbot> mmaslano: #1207 (provenpackager request) – FESCo - https://fedorahosted.org/fesco/ticket/1207 18:41:28 <abadger1999> mmaslano: uh... 18:41:45 <abadger1999> I don't think I can sign up for more than rephrasing sgallagh's question. 18:41:54 <mmaslano> abadger1999: fine by me 18:42:30 <mmaslano> abadger1999: I guess we can fight about questions later in the ticket 18:42:55 <mmaslano> Michal Srb, I guess we only approve, no -1 in the ticket 18:42:56 <abadger1999> This second part of the question I'm pretty sure Legal will want to know the specifics of what we want to do is and that's something I odn't know the answer to. 18:43:57 <nirik> mmaslano: yeah, auto approve on this one. 18:44:08 <sgallagh> +1 approve (as noted in the ticket) 18:44:30 <mmaslano> #action mmaslano will close this ticket, no -1, auto approval 18:44:34 <mmaslano> #topic #1208 Request Proven Packager 18:44:39 <mmaslano> .fesco 1208 18:44:40 <zodbot> mmaslano: #1208 (Request Proven Packager) – FESCo - https://fedorahosted.org/fesco/ticket/1208 18:45:14 <nirik> not enough +1's... 18:45:18 * nirik looks 18:45:29 <mmaslano> tstclair 18:45:50 <mmaslano> do we have some minimal +1's? 18:45:54 <mmaslano> I see only +2 18:46:07 * mattdm looks 18:46:26 <mattdm> +1 18:46:31 <sgallagh> other members of the SIG for which he wants provenpackager seem to support it. 18:46:35 <nirik> +1 from me... I've not talked to tstclair in a while, but I recall condor packaging is good. 18:46:35 <sgallagh> I'm +1 on those grounds. 18:47:27 <abadger1999> Has commit on 7 packages: https://admin.fedoraproject.org/pkgdb/users/packages/tstclair?acls=owner&ac… 18:48:09 <abadger1999> mmaslano: You must get at least 3 positive votes with no negative votes, over a one week review period, to be automatically approved. 18:48:13 <abadger1999> http://fedoraproject.org/wiki/Provenpackager_policy 18:48:40 <mmaslano> he wrote: I'm requesting proven packager status is to coordinate updates with maintainers of the dependency tree. 18:48:47 <mmaslano> how many packages is there? 18:49:03 <mmaslano> is it worth of provenpackager? 18:49:41 <abadger1999> there were no -1's in ticket so really.. we don't need fesco to vote in full, mattdm and nirik's +1 could count towards the "3 positive votes" if they want. 18:49:50 <nirik> right, true. 18:50:15 <mattdm> should i put my +1 in the ticket? does that help? 18:50:24 <nirik> sure. 18:50:36 <abadger1999> mattdm: yeah do that and then we'll just do automatic approval. 18:50:50 <nirik> mmaslano: I can close both those tickets and add the users... 18:50:55 <mmaslano> nirik: thanks 18:51:13 <mmaslano> #action nirik will close both provenpackager tickets and add permission to those users 18:51:34 <mmaslano> #topic Next week's chair 18:52:45 <sgallagh> Don't all volunteer at once... 18:53:27 <mitr> I'm not sure I'll be here next week 18:53:39 <mmaslano> we can volunteer someone who's not here... 18:54:05 * mattdm looks at calendar 18:54:19 <mattdm> okay I can do it :) 18:55:42 <mmaslano> #action mattdm wil be chairman next week 18:55:49 <mmaslano> #topic Open Floor 18:57:29 * nirik has nothing 18:57:32 <mmaslano> nothing? 18:57:38 <mmaslano> I will close the meeting in 3 minutes 18:57:39 <mattdm> *crickets chirp* 18:57:40 <sgallagh> I had something, but I can't bring it to mind. 18:57:49 <sgallagh> I'll post on the list if it turns out to have been important... 18:57:55 <mmaslano> crickets died in the snow... 18:58:02 <abadger1999> sgallagh: you were going to wish everyone a happy holiday season ;-) 18:58:12 <sgallagh> Well, that goes without saying! :) 18:59:32 <sgallagh> mmaslano: Close now and we'll have kept to an hour :) 18:59:44 <mmaslano> fine 18:59:50 <mmaslano> #endmeeting

1 0

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

26 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/fedora-server-working-group-nov-26-m… . Below the summary, you'll find the meetbot links if you'd like to read the raw logs. Meeting Minutes =============== Agenda ====== Our agenda was set ahead of time on the mailing list after an active discussion on the call for agenda post. * Select a new member of the Working Group * Personas Members Present =============== * sgallagh * nirik * mitr * simo * mizmo * davidstrauss * tuanta * Evolution Working Group Member Selection ============================== Jóhann (Viking-Ice) decided to step down from the server working group. So the server working group needs to select a new working group member. As mitr pointed out, our charter says we should choose from “from the active Fedora Server community” but the group hasn’t been around long enough to build up an active community. Since Jóhann represented the QA community in Fedora, we agreed on the following: * We will ask the QA community to recommend someone from their ranks. * If no one from QA steps forward, we will put out a general call, particularly to those who previously volunteered. Personas ======== Most of the meeting time was spent on discussing personas. I (mizmo) gave a status update on where the personas are at right now: * We have a working personas document available at: https://fedoraproject.org/wiki/Server/Personas. It’s based on the personas nirik suggested at last week’s meeting. * We have one sysadmin interview completed to help inform the personas. mizmo and sgallagh interviewed kdetony last week. He is a sysadmin for a large company. (The interview notes are now available in the wiki.) mizmo will interview davidstrauss too when he returns to the US. * sgallagh and mizmo basically put together a FAQ on personas as well (I just put it up on the wiki now.) A quick review -------------- Evolution missed the last meeting, so we filled him in on the point of personas and how we’d go about using them. I added our answers to the persona FAQ so if you are curious about these things please check that out. “I like the general concept,” said Evolution, “so long as we don’t get caught up in arbitrarily pigeon-holing things because of this.” “We all agree on that score,” sgallagh assured him. Persona order? -------------- Nirik also had a great question about whether or not personas have an order to them; they can – for example, we can define a couple of primary personas, have secondary personas, and maybe anti-personas (we would explicitly not cater to the needs of the anti-personas, but could define them for clarity.) The personas from the first draft --------------------------------- So next I walked folks through the three personas we have: * Senior sysadmin / nonprofit org / she’s classified as ‘MacGuyver’ because they don’t have a lot of resources but try to get a lot done * Server app developer / freelancer / (no nickname yet) *Junior sys admin / huge company / lots of resources available (no nickname for him yet either) What does junior mean, and another persona suggestion ----------------------------------------------------- davidstrauss asked, “What makes the third one ‘junior?’” “He might not have as much decision-making power,” I (mizmo) replied, “He’s not the team lead or anything like that. so he may be stuck with decisions made over his head.” “It seems strange to couple abundant company resources with the ‘junior’ guy,” davidstrauss responded. I replied, “Well, not necessarily. E.g., if he needs more hardware he probably won’t have a hard time getting it, but he’s not going to be able to change the bureacracy at his org.” “Well, I guess I’m the contrast to that persona, anyway. We have lots of resources, and I’m CTO,” said davidstrauss. “I think you would be an excellent additional persona,” I replied. “I would probably nickname your persona ‘decision maker.’” davidstrauss answered, “I don’t really care if it’s me, but we need someone with resources + power.” “Yes, a decision maker is an important case,” mitr added. Going meta sgallagh suggested that we add a persona for folks creating a new server role for Fedora Server. This would be a kind of meta persona – a person who contributes to Fedora by putting together a role for the server platform product. We’ll add it as a secondary persona. The question this persona might help answer, as posed by davidstrauss: “How does one create a service that plugs nicely into Fedora?” Developer vs. DevOps “I do agree we need a developer persona (particularly for the requirements on languages and deployment),” mitr pointed out. “Can we clarify that Server is not the OS one uses to actually develop the application (i.e. run Eclipse / ask on stackoverflow …) – that should be Workstation [... which requires inter-WG agreement on the languages and deployment mechanism)." nirik added, "Yes, but we shouldn't ignore that case... they need to install server software to test, etc." I (mizmo) took the action item to modify the developer persona accordingly. I also asked, "Should we have a devops persona too in addition to the developer?" "I thought that was what your developer persona was, there," sgallagh responded. mitr asked, "What would be unique about devops? Ability to deploy and to monitor should already be there." "We could make him devops then," I said, "I think Ijust need more info about how the guy would work. I don't know enough about it. E.g., does a devops person get paged at all hours when there's an outage?" mitr said, "I'd slightly prefer not restricting ourselves to devops (multiple platforms, and speed to deploy are equally important when deploying a 10-year old J2EE application), but I don't feel strongly about it." "The primary difference with DevOps," sgallagh explained, "is the concept of 'Mean time to recovery' is more important than 'Uptime.'" "Does devops necessarily mean a smaller organization?" I asked. "Because I don't know how you'd have them combined into one role for a huge app like the one I'm thinking of." Simo responded, "Well, devops people would say no, but in reality I see real devops only in startups. :) " "Devops kind of captures nicely "the Ruby problem" (sorry, I'm unfairly picking on a single language for simplicity)," mitr added. I asked, "What's the ruby problem?" "The ruby problem is mainly 'the bundling problem' rehashed," sgallagh answered. "Except with a community that has no stake in backwards-compatibility (in the general case.)" "What sgallagh said, + the culture that 'that's how things are done.'" added mitr. To confirm my understanding, I asked, "So with ruby you need devops, because the platform isn't backwards compatible, so you need a developer to port things forward if something goes wrong because of a bug in the platform or whatnot?" "Precisely," sgallagh answered. simo added, "It is not just ruby." "Right, ruby is just a representative example," sgallagh said. "This is true of a lot of Java shops too." "It is also: oh cloud provider X we use is going to change API in 10 days," explained simo. "Need to develop a different connector for the production servers ASAP. Language really doesn't matter" "And Google APIs..." added sgallagh. "So it's really about resiliency not just of the service but also the deployment itself." Simo explained further, "It's about people using *new* platforms that keep changing and shifting all the time. They use so much of *everything* it is all in costant motion." "Well, it's also about a perception change," sgallagh added. "That absolute stability is not as important as rapid recovery." davidstrauss said, "It's part of the perception change I'm referring to in the migrations vs. support duration [thread]. How easy is it to keep the app on a supported foundation? *versus* How long can the foundation we’ve deployed to remain supported?” “It is a lot about automation,” said Simo, “because devops will redeploy a lot. A lot more than traditional ops used to.” Nirik also illustrated the point, “‘Thing x is hard and we only do it once a year, so, lets do it 10x/day now and fix all the problems so that we can keep going.’” “Right, the devops folks pretty much live in the ‘livestock’ side of things, except possibly for their hypervisors,” added sgallagh, referring back to the analogy that some servers are treated as expendable (like livestock), and some are given names and fixed up when they get broken and are kept around long-term (like pets.) “They concentrate on the changing pieces but absolutely rely on the stable infra as well,” simo said. I asked, to confirm, “So devops people are more automated, the traditional people are more ‘omg don’t break it?’” “That’s a pretty fair analogy,” replied sgallagh. So we concluded that I’d make the developer persona more ‘devoppy,’ now that I had a better understanding of what that meant. Where does Server end and Cloud begin? One thing that came up at this point in the conversation was the line between the Cloud product and the Server product. “When it comes to server and cloud usage, I want Fedora to leapfrog the current popular choices philosophically,” said davidstrauss. “Our competition is, in some ways, CoreOS more than Ubuntu.” nirik added, “I think we can add a lot of value in standardizing/best practices…” “Let’s also not get in the Cloud group’s way too much either,” sgallagh pointed out. “I think we probably want to be focusing on the infrastructure to support their product. Fedora Cloud is likely to be Fedora’s answer to CoreOS.” “I’d generally prefer if a Cloud application and Server application were bit-for-bit the same (but it hasn’t been discussed yet,)” mitr added. davidstrauss agreed. “To be honest, I see less and less separation between server and cloud product,” said simo in response to sgallagh. “I wonder if they really will be that different if we keep pushing hypervisor stuff that way.” “I always thought cloud os would care about guests more than bare metal,” simo said. Evolution responded, “There’s a large amount of crossover in the two.” “But the guests are often-times running the server bits we’re interested in,” replied Evolution. simo in response said, “I wonder if it really make sense to have separate stuff in the end.” “We deploy Fedora to bare metal as a container host,” davidstrauss explained. “Once companies like GitHub, Etsy, etc. grow to a certain point, they often substantially leave ‘cloud’ for bare metal. And once they leave cloud, they either deploy to hypervisors on their own hardware or something like the “guest images” to bare metal directly.” sgallagh said, “Whereas our position is to deliver sturdy infrastructure both for traditional roles and to support Cloud deployments.” simo replied to davidstrauss, “True, many company have mixed environments, with in house clouds + overflow on public clouds after some time.” “Some companies opt to run their own clouds. Others move to PXE deployments and similar,” responded davidstrauss. Traditional Developer Persona ----------------------------- “Did anybody have a chance to read through some of the stuff on the developer persona? I kind of really just made it up but I don’t know if I was getting at the wrong thing,” I asked. “E.g., under frustrations: ‘Spending cycles porting code to an endless array of platforms – it’s time-consuming and uninteresting work,’ but I guess a devop wouldn’t do that?” sgallagh answered, “No, devops would pick a minimalist platform and just VM/Containerize it.” I asked further, “Do we care about devs/admins who would need to do porting work like that on a server?” “Traditional app developers will need to be served, yes,” sgallagh answered, “The Oracle DBs and SAPs of the world, for example.” I asked for more examples of traditional deployments, and got the following: * Domain controller * DNS server * Email infrastructure * File server * Storage cluster * Office proxy * Office DNS and web proxy Personas and timelines ---------------------- “We probably should try and finish personas in not too long… given our short timeframe to come up with deliverables/document,” said nirik. “I think we’re pretty close,” I pointed out. “I didn’t see a whole lot of contention here about the ones we have so fair, just some refinements / expansion.” As sgallagh proposed, I’ll try to have the personas document ready to be voted on December 10. Meetbot Minutes: =============== Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting…

1 0

Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-26)
by Marcela Mašláňová 26 Nov '13

26 Nov '13

============================= #fedora-meeting: (2013-11-26) ============================= Meeting started by mmaslano at 13:00:25 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-26/environment_and_… . Meeting summary --------------- * init process (mmaslano, 13:01:15) * http://piratepad.net/PwUiH4MEPR (mmaslano, 13:09:53) * tools for setting up development environments/more automation for packaging/providing stacks (mmaslano, 13:19:58) * LINK: http://ambre.pingoured.fr/cgit/review_srv.git/ (pingou, 13:41:51) * So, my attempt at summarization: one idea regarding the automatic packaging is to help existing maintainers see the automatically updated spec file and the generated rpm, so they have less work updating the packages, and to enable the eager users to use them AS IS (mmaslano, 13:48:49) * the other idea I saw was: The other idea is to enable easier/quicker packaging of dependent RPM files by generating spec files for the packager automatically (mmaslano, 13:48:58) Meeting ended at 14:00:03 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mmaslano (40) * juhp_ (36) * tjanez (35) * pingou (30) * sochotni (18) * hhorak (6) * samkottler (4) * zodbot (4) * bkabrda (3) * pkovar (1) * abadger1999 (0) * juhp (0) * handsome_pirate (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 13:00:25 <mmaslano> #startmeeting (2013-11-26) 13:00:25 <zodbot> Meeting started Tue Nov 26 13:00:25 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:47 <mmaslano> #meetingname Environment and Stacks 13:00:47 <zodbot> The meeting name has been set to 'environment_and_stacks' 13:01:03 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda handsome_pirate hhorak juhp 13:01:03 <zodbot> Current chairs: abadger1999 bkabrda handsome_pirate hhorak juhp mmaslano pkovar samkottler tjanez 13:01:15 <mmaslano> #topic init process 13:01:21 <mmaslano> hi guys 13:01:29 <tjanez> hi 13:01:40 <bkabrda> hey 13:01:49 <hhorak> Hi all 13:02:29 <juhp_> hi 13:06:25 <mmaslano> so, do we continue discussion from last week? 13:06:36 <mmaslano> I saw lot of ideas what we should be doing on mailinglist 13:06:48 <mmaslano> but I guess we need higher level ideas... 13:07:10 <juhp_> yes 13:08:14 <tjanez> mmaslano: I agree that we should maybe try to define what our WG in a more general way 13:08:24 <juhp_> should we try to collect ideas somewhere and then try to extract higher level goals from there perhaps? 13:08:45 <mmaslano> tjanez: definitely 13:09:44 <tjanez> juhp_: the piratepad last week was an attempt 13:09:53 <mmaslano> #info http://piratepad.net/PwUiH4MEPR 13:09:59 <tjanez> juhp_: It's been copied to https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Charter_Brainstor… 13:10:01 <mmaslano> we can continue there 13:10:31 <hhorak> having in mind concrete ideas from mailing list, we can ask WHY we want to do it and we should get more general ideas 13:10:59 <juhp_> tjanez, thanks - I just opened the pad 13:12:02 <juhp_> it looks more formal than what I had in mind at this stage but good 13:12:49 <mmaslano> it should be shorter 13:12:57 * pkovar is late 13:13:36 <tjanez> one of the high-level goals which comes to mind is "to enable inclusion of all (legally acceptable) stacks in Fedora, which are not possible in today's Fedora landscape (policies, guidelines, tools, ...)" 13:14:07 <tjanez> I'd put it in the pad, however, I don't know where to put it 13:15:15 <juhp_> tjanez, yes 13:15:51 <juhp_> right that is why I would prefer a more free-form wiki page for branch-storming 13:16:12 <sochotni> juhp_: brainstorming? 13:16:21 <juhp_> ah yes thanks ;) 13:16:24 <juhp_> :) 13:16:29 <juhp_> lol 13:17:26 <tjanez> Another thing we should do is define the terms environment and stacks 13:17:32 <juhp_> sochotni, also agree with your idea of a package review app - that seems totally needed - dunno if it is really in the scope of this WG per se 13:17:54 <sochotni> juhp_: it's probably more in line with core fedora infra 13:17:58 <mmaslano> tjanez: personally, I don't are what is stack and what is environment 13:17:59 <juhp_> yes 13:17:59 <sochotni> i.e. generic tooling 13:18:24 <juhp_> could we just be the Stacks WG? :) 13:18:32 <mmaslano> sure :) 13:19:01 <juhp_> seems okay to me too 13:19:36 <bkabrda> so my high-level proposal: tools for setting up development environments/more automation for packaging/providing stacks (meaning python2/python3, ruby/jruby) 13:19:36 <sochotni> I agree it would be less confusing 13:19:40 <juhp_> maybe Env is supposed to imply more than Stacks? <shrug/> 13:19:47 <mmaslano> maybe 13:19:58 <mmaslano> #topic tools for setting up development environments/more automation for packaging/providing stacks 13:21:03 <tjanez> I would also be for just Stacks WG :), but juhp_ has a point, maybe we want to also work on improving the development environment 13:21:12 <tjanez> here is where "environment" comes in :) 13:21:20 <juhp_> true 13:21:34 <juhp_> so maybe we are good with the name then :) 13:22:33 <sochotni> pingou | sochotni: I had started something yes, but I haven't touched it in a while 13:22:42 <sochotni> that was wrt review app 13:23:06 * pingou looks at the title 13:23:12 <tjanez> sochotni: I liked your idea regarding the Fedora review app 13:23:21 <mmaslano> it could improve the process, it could help automatization 13:23:30 <juhp_> yes 13:23:45 <tjanez> sochotni: I think it could be incubated within our WG first and then proposed to general (core) Fedora audience 13:23:57 <mmaslano> tjanez: sounds good 13:24:01 <pingou> I need to get pkgdb2 out of the door, but if there is such a demand I can start working again on the review app 13:24:20 <mmaslano> pingou: I was thinking about automatic generation of srpm from some upstreams 13:24:50 <pingou> mmaslano: things like R, perl, python (to some extend) and php would be pretty easy 13:25:08 <pingou> we already have a bunch of *2spec and sometime even *2rpm 13:25:25 <pingou> the critical part of the review becomes more the license than the spec file 13:25:44 <mmaslano> pingou: yes, we have tools, which we are using for generation of packages 13:26:09 <sochotni> in cooperation with copr we could have automatically updated repos 13:26:11 <pingou> but maybe we could come up with something like: insert here you upstream project url to tarball -> get your srpm here and your rpm from this copr repo 13:26:26 <sochotni> yeah 13:26:27 <juhp_> my cabal-rpm tool can generally generate haskell srpms from upstream but of course that is special case 13:26:46 <mmaslano> pingou: big picture :) give a list of modules, which we want from cpan/other sources and receive them in srpm :) 13:26:48 <sochotni> being able to build stuff by giving Fedora service a github url with sources would be nice :-0 13:26:51 <pingou> a first thing would be to gather all these projects :) 13:27:11 <mmaslano> pingou: we don't need everything available, just list of what's interesting 13:27:24 <pingou> mmaslano: I mean the *2spec projects 13:27:31 <pingou> to see which area we cover 13:27:48 <mmaslano> ok 13:28:08 <mmaslano> pingou: i was also thinking about helper for updating existing packages 13:28:26 <pingou> I've been playing in the R field quite a bit, we have R2spec in the repo that comes in with a R2rpm flavor, the issue of on building the deps when provided with a certain project 13:28:33 <juhp_> mmaslano, yes 13:28:39 <tjanez> So, if I understand correctly, there is demand for an RPM repository that contains all, e.g. CPAN, Pypi packages? 13:28:50 <pingou> mmaslano: one day I will want to write an easy spec API in python :) 13:29:02 * pingou already has his own UpdateRPackage.py that does it :] 13:29:12 <bkabrda> tjanez: I wouldn't say all. more like some of them ("important") in the latest versions or so 13:29:19 <pingou> tjanez: only the one the user asks 13:29:22 <mmaslano> tjanez: not all, we could do only what we have in Fedora. It would safe time which we spend on updates of packages 13:29:27 <pingou> tjanez: maybe like: all the deps for projects X 13:30:17 <tjanez> Aha, ok, this is a bit different 13:30:27 <tjanez> then what I though :) 13:30:52 <tjanez> I would like to come up with some high-level description of what we want this *2spec tools and repositories coming from that 13:31:12 <pingou> (why do I feel like there is an interesting mailing-list I'm missing? :)) 13:31:20 <mmaslano> I gues we have one are what we want to do 13:31:41 <mmaslano> pingou: it should be discussed on our mailnig list, but it wasn't yet 13:31:45 <samkottler> pingou: it hasn't gotten very interesting yet, but you should join the stack-and-envs list 13:31:54 <pingou> samkottler: thanks ;) 13:32:13 <juhp_> envs-and-stacks :) 13:32:24 <pingou> yup I corrected and subscribed, thanks 13:32:38 <samkottler> heh, I figured he'd be able to find it regardless :) 13:32:46 <juhp_> great 13:33:02 <tjanez> One of the goals would be: "To provide repositories with automatically updates specs and generated rpms of Python, Perl, etc. modules that are ALREADY in Fedora" 13:33:24 <juhp_> do we have to restrict to in Fedora already? 13:33:25 <mmaslano> sounds good to me as high level goal 13:33:37 <tjanez> So in a way, the repository would follow upstream release schedule 13:33:44 <pingou> I'd wouldn't do it for things which are already in Fedora 13:33:55 <tjanez> As soon as the upstream puts it on CPAN, PyPI, it would be available in the repo 13:34:04 <pingou> unless indeed there is a major version with API/ABI bump that we cannot back port 13:34:09 <samkottler> there'd be huge bloat in the repos if we did it for everything 13:34:19 <pingou> but otherwise I'd go mroe w/ automated rpm generation for the missing deps 13:34:32 <mmaslano> samkottler: I would prefer only list of important as was said 13:34:36 <juhp_> there could be a middle way - but yeah if you want full automation... 13:34:38 <tjanez> juhp_, pingou: I'm just discussing, I would like to see your point 13:35:06 <samkottler> we might have to figure out how to track ABI changes over time because lots of library authors don't properly version 13:35:31 <pingou> copr is clearly going to lack the space to fully automatically build everything + I just don't think we want that anyway 13:35:51 <juhp_> if we had a lower barrier of entry than main fedora repos it would be a good testing ground for new candidate packages/stacks too 13:36:12 <mmaslano> yeah, but the space on copr is a real problem 13:36:46 <juhp_> sure not everything - I am just suggesting we don't have to restrict to fedora only packages - and even if we do there will be new dependencies that need to be packaged anyway 13:36:46 <pingou> mmaslano: well not so far, but might become yes 13:36:53 <tjanez> juhp_: Yes, I agree, but who should select which subset of PyPi/CPAN is interesting and packaged automatically AS IS 13:37:10 <juhp_> tjanez, right I dunno 13:37:20 <hhorak> samkottler: I already started looking into it and rather than one spicific api/abi testing tool I'd like to come up with some general tool that could test more than that and would be easy to run the same on localhost or in the infrastructure 13:37:29 <pingou> juhp_: I'd go more the opposite, copr are complementary to the official fedora repo, so don't re-build what already is 13:37:33 <juhp_> perhaps additional packages could be added/proposed somehow shrug 13:37:49 <tjanez> juhp_, or do it like AUR in Arch 13:37:59 <juhp_> pingou, okay perhaps - but then what about newer versions 13:38:11 <juhp_> tjanez, yea 13:38:31 <sochotni> hhorak: you mean rpm QA tool? 13:38:36 <pingou> juhp_: then it would appply indeed, but only on branch where this update hasn't been done (for example to get django 1.6 on F20) 13:38:48 <juhp_> sure 13:39:22 <hhorak> sochotni: something like that.. 13:40:33 <juhp_> I like the overall idea we're creating 13:40:57 <tjanez> juhp_: +1 13:41:20 <sochotni> pingou: for the logs, can you point to the codebase for current review tool? 13:41:51 <pingou> http://ambre.pingoured.fr/cgit/review_srv.git/ 13:42:20 <tjanez> Could someone attempt to summarize the general idea of the discussion? 13:42:21 <pingou> but it's still quite far from complete 13:42:37 <mmaslano> juhp_: +1 13:42:58 <sochotni> pingou: I don't expect anything else :-) 13:43:13 <sochotni> it's just something to start off from 13:43:39 <pingou> sochotni: for the record I did put it on the list of things I would like to work on next year (sent to my manager :)) 13:44:02 <pingou> so I might get some time to revive it 13:44:08 <sochotni> pingou: good! 13:46:42 <tjanez> So, my attempt at summarization: one idea regarding the automatic packaging is to help existing maintainers see the automatically updated spec file and the generated rpm, so they have less work updating the packages, and to enable the eager users to use them AS IS 13:46:57 * mmaslano has to leave in 14 minutes 13:47:09 <mmaslano> tjanez: yes 13:47:30 <mmaslano> tjanez: I would be fine with summarization of what we said -> first goal 13:47:44 <juhp_> tjanez, I might add early access to packages/stacks still under/before package review 13:47:44 <mmaslano> and next week we can speak about different area 13:48:21 <tjanez> juhp_: yes, agreed 13:48:30 <tjanez> the other idea I saw was: The other idea is to enable easier/quicker packaging of dependent RPM files by generating spec files for the packager automatically 13:48:49 <mmaslano> #info So, my attempt at summarization: one idea regarding the automatic packaging is to help existing maintainers see the automatically updated spec file and the generated rpm, so they have less work updating the packages, and to enable the eager users to use them AS IS 13:48:50 <juhp_> yes 13:48:58 <mmaslano> #info the other idea I saw was: The other idea is to enable easier/quicker packaging of dependent RPM files by generating spec files for the packager automatically 13:49:42 <hhorak> sounds fine. 13:50:21 <tjanez> There was also an idea regarding trying out a new kind of package review process (via to-be-developed review app) 13:50:45 <hhorak> I remember I heard already of some "rebase helper" that could be used (if ready).. I'll try to get more info and will send to ML. 13:50:50 <tjanez> which could be incubated within our WG and then re-iterated/refined for proposal into Fedora proper 13:52:34 <tjanez> Along side the new review process, we could rethink the packaging guidelines (along the ideas proposed in the ML) 13:53:22 <sochotni> I believe whole approach to packaging could be changed/improved while preserving current guidelines 13:53:31 <sochotni> just giving us more time to actually care bout it 13:55:02 <juhp_> yeah 13:55:36 <tjanez> sochotni: Yes, agreed. I was thinking about also improving the documentation on the Wiki pages so it would be shorter and not mix guidelines, best practices, etc. 13:55:51 <tjanez> But this could be improved independently 13:56:29 <juhp_> that is true - more streamlining and separating to the bare essentials would be good 13:56:30 <tjanez> I also like the idea proposed by hhorak about some sort of CI for our package repositories 13:57:01 <tjanez> So that we ensure that the already included packages stay in good shape 13:57:13 <tjanez> Spec files come to mind first 13:57:40 <sochotni> tjanez: http://jenkins.cloud.fedoraproject.org/job/javapackages-tools/ (that's CI for Java tooling - requires/provides generators etc) 13:57:45 <pingou> I had started to work on something using datagrepper that we could use to rebuild automatically all packages that have not been rebuild in, say, 1 fedora release 13:58:23 <pingou> if that's also of interest, I could pick it up again :) 13:58:25 <mmaslano> I need to go, volunteer who take chairman? 13:58:42 <tjanez> sochotni: Cool, I will check it our 13:59:46 <mmaslano> no volunteer? 13:59:56 <sochotni> we are getting to one hour....we'll just have to pick it up later 14:00:03 <mmaslano> #endmeeting

1 0

Marketing team meeting minutes, November 25, 2013
by Ruth Suehle 25 Nov '13

25 Nov '13

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

1 0

FAmSco meeting 2013-11-25 minutes
by Christoph Wickert 25 Nov '13

25 Nov '13

Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeting… Meet you again next week Monday December 2nd at 17:00 UTC in #fedora-meeting-2! Regards, Christoph ==================================== #fedora-meeting-2: FAmSCo 2013-11-25 ==================================== Meeting started by cwickert at 17:04:21 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeting… . Meeting summary --------------- * Roll call (cwickert, 17:04:38) * sesivany sent regrets, he his on holidays (cwickert, 17:05:25) * AGREED: : FAmSCo is unhappy about the repeated absence of bckurera but will note remove him from the committee as the elections are around the corner (cwickert, 17:12:07) * LINK: : the agenda for today#s meeting can be found https://fedorahosted.org/famsco/report/9 (cwickert, 17:13:31) * RH Community Credit Card holder for APAC (cwickert, 17:14:51) * AGREED: tuanta to ask rsuehle and rbergeron to talk to the finance people and convince them to allow a non-RH person as CC holder for APAC. Once they have green light, make KageSenshi the CC holder (cwickert, 17:21:56) * EMEA Mentor Nomination: Keiran Smith (cwickert, 17:23:18) * Schedule (cwickert, 17:29:34) * LINK: http://fedorapeople.org/groups/schedule/f-20/f-20-ambassadors-tasks.html (cwickert, 17:29:45) * official release is 2013-12-10, let's hurry up (cwickert, 17:31:18) * ACTION: cwickert to send out the call for release events (cwickert, 17:31:42) * ACTION: cwickert to send aeperezt the pins (cwickert, 17:32:41) * AGREED: cwickert to bring up the idea of a central media production and distribution as ticket. it's unclear if it works, but we should think about it (cwickert, 17:45:05) * ACTION: cwickert to bring up the idea of a central media production and distribution as ticket. it's unclear if it works, but we should think about it (cwickert, 17:45:10) * LINK: http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-18/famsco.2013-11… (tuanta, 17:47:34) * ACTION: if you have anybody who deserves a 10th anniversary shirt and who is not yet listed on https://fedoraproject.org/wiki/F20_anniversary_tshirt , please let robyduck know. I am thinking of long-term contributors with great impact who are not part of any group like FAmSCo, FESCo etc, e. g. (former) packagers (cwickert, 17:51:50) Meeting ended at 17:52:47 UTC. Action Items ------------ * cwickert to send out the call for release events * cwickert to send aeperezt the pins * cwickert to bring up the idea of a central media production and distribution as ticket. it's unclear if it works, but we should think about it * if you have anybody who deserves a 10th anniversary shirt and who is not yet listed on https://fedoraproject.org/wiki/F20_anniversary_tshirt , please let robyduck know. I am thinking of long-term contributors with great impact who are not part of any group like FAmSCo, FESCo etc, e. g. (former) packagers Action Items, by person ----------------------- * aeperezt * cwickert to send aeperezt the pins * cwickert * cwickert to send out the call for release events * cwickert to send aeperezt the pins * cwickert to bring up the idea of a central media production and distribution as ticket. it's unclear if it works, but we should think about it * **UNASSIGNED** * if you have anybody who deserves a 10th anniversary shirt and who is not yet listed on https://fedoraproject.org/wiki/F20_anniversary_tshirt , please let robyduck know. I am thinking of long-term contributors with great impact who are not part of any group like FAmSCo, FESCo etc, e. g. (former) packagers People Present (lines said) --------------------------- * cwickert (97) * tuanta (47) * aeperezt (38) * LoKoMurdoK (14) * zodbot (10)

1 0

Docs Project Meeting Summary 25 Nov 2013
by Pete Travis 25 Nov '13

25 Nov '13

==================================================================================================== #fedora-meeting: Docs Project Meeting - Agenda: https://fedoraproject.org/wiki/Docs_Project_meetings ==================================================================================================== Meeting started by randomuser at 14:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-25/fedora_docs.2013… . Meeting summary --------------- * Roll Call (randomuser, 14:00:03) * release notes (randomuser, 14:05:24) * Guide Status (randomuser, 14:11:00) * Pete wants to get some content pumped into the new MultiBoot guide and get it published (randomuser, 14:11:38) * Check bugzilla for docs work, and open bugs too (randomuser, 14:16:49) * LINK: https://git.fedorahosted.org/git/docs/ARM-getting-started-guide.git (zoglesby, 14:19:53) * zoglesby needs help with the ARM-GSG (randomuser, 14:22:06) * BZ tickets (randomuser, 14:26:57) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=998327 (randomuser, 14:27:10) * the script that redirects to a given locale is broken for romanian (randomuser, 14:27:33) * LINK: http://tinyurl.com/lbrq84 (randomuser, 14:32:09) * thanks ciupicri for the patch! (randomuser, 14:38:03) * open floor discussion (randomuser, 14:41:27) Meeting ended at 14:55:19 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * randomuser (67) * jjmcd (17) * zoglesby (11) * ciupicri (8) * pbokoc (6) * pkovar (6) * sgordon (4) * zodbot (3) * yruseva (1) * pwhalen (1) -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org

1 0

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

22 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-29). Please come and join the discussion if you can! [1]: http://meetbot.fedoraproject.org/fedora-zh/2013-11-22/fedora-zh.2013-11-22-… ================== #fedora-zh Meeting ================== Meeting started by alick at 13:07:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-zh/2013-11-22/fedora-zh.2013-11-22-… . Meeting summary --------------- * 报到 (alick, 13:07:42) * FUDCON APAC 2014 申办 (alick, 13:14:44) * ACTION: alick to email out the current version of planning document (alick, 13:16:56) * HELP: everyone to update the bid wiki page (alick, 13:20:52) * LINK: https://fedoraproject.org/wiki/FUDCon:Bid_for_Beijing_2014 (alick, 13:21:07) * F20 Release Party (alick, 13:25:39) * LINK: https://fedoraproject.org/wiki/Release_Party_F20_Beijing (alick, 13:31:17) * ACTION: alick mention budget in mail list (alick, 13:45:25) * 中文翻译 (alick, 13:46:25) * LINK: https://fedora.transifex.com/projects/p/fedora/language/zh_CN/?project=2060 (alick, 13:48:15) * 自由讨论 (alick, 13:55:20) Meeting ended at 14:09:15 UTC. Action Items ------------ * alick to email out the current version of planning document * alick mention budget in mail list Action Items, by person ----------------------- * alick * alick to email out the current version of planning document * alick mention budget in mail list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * alick (45) * tonghuix_ (30) * endle (18) * zsun (9) * zodbot (6) * BadGirl (4) * chenchacha (4) * isyangxin (2) * zsun_mob (2) * zsun1 (1) * tonghuix (0) * tiansworld (0) * microcai (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

meetingminutes November 2013