Fedora Chinese Meeting Minutes (2013-11-29)
by Alick Zhao
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-2...
==================
#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-2...
.
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
10 years, 4 months
- 1
- 0
Minutes from today's (11/27/2013) cloud WG meeting
by Sam Kottler
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-meeti...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
Log (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-27/fedora-meeti...
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-meeti...
.
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-pa...
(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-2...
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-pa...
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-2... 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
10 years, 4 months
- 1
- 0
Latam Ambassadors Meeting / Reunion de Embajadores de Latam 2013-11-27
by alejandro perez
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-27/fedora_latam_a...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-27/fedora_latam_a...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-27/fedora_latam_a...
10 years, 4 months
- 1
- 0
Summary/Minutes from today's FESCo Meeting (2013-11-27)
by Marcela Mašláňová
===================================
#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-...
.
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&...
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
10 years, 4 months
- 1
- 0
Meeting Summary / November 26, 2013
by Máirín Duffy
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...
.
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-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeti...
10 years, 4 months
- 1
- 0
Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-26)
by Marcela Mašláňová
=============================
#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_an...
.
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_Brainst...
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
10 years, 4 months
- 1
- 0
Marketing team meeting minutes, November 25, 2013
by Ruth Suehle
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2013-11-25/fedora_marketi...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2013-11-25/fedora_marketi...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2013-11-25/fedora_marketi...
10 years, 4 months
- 1
- 0
FAmSco meeting 2013-11-25 minutes
by Christoph Wickert
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2013-11-25/fedora-meeti...
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-meeti...
.
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-...
(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)
10 years, 4 months
- 1
- 0
Docs Project Meeting Summary 25 Nov 2013
by Pete Travis
====================================================================================================
#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.20...
.
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
10 years, 4 months
- 1
- 0
Fedora Chinese Meeting Minutes (2013-11-22)
by Alick Zhao
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-2...
==================
#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-2...
.
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
10 years, 5 months
- 1
- 0