Minutes from today's (11-13-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-13/fedora-meeti...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeti...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeti...
Here's a summary of the meeting (link to the HTML version above):
==========================================
#fedora-meeting-1: Cloud WG weekly meeting
==========================================
Meeting started by samkottler at 17:00:31 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-13/fedora-meeti...
.
Meeting summary
---------------
* rollcall (samkottler, 17:02:00)
* agenda items (samkottler, 17:05:55)
* A few tools need to get packaged for GCE support, primarily gcutil
and image_bundle. All of them are free software and on GitHub.
(gholms, 17:07:58)
* ACTION: samkottler to figure out what's needed in koji to get images
built there (samkottler, 17:09:44)
* LINK: http://lists.debian.org/debian-cloud/2013/10/msg00004.html
(mattdm, 17:12:43)
* hguemar is looking to package gcutil and image_bundle (number80,
17:14:13)
* LINK: https://code.google.com/p/google-compute-engine-tools/
(gholms, 17:15:18)
* LINK: https://github.com/GoogleCloudPlatform/compute-image-packages
(samkottler, 17:18:18)
* ACTION: mattdm to kick of thread re google scripts vs cloud-init
(mattdm, 17:23:49)
* governance document review before submission to FESCo (samkottler,
17:25:10)
* ACCEPTED: add wording to charter about commiting to membership every
6 months like server wg (+6) (mattdm, 17:40:58)
* ACCEPTED: governance charter as of
https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627
ratified (mattdm, 17:44:39)
* open floor (mattdm, 17:45:35)
* we need to figure out our interaction with the server wg and how we
define what we're doing (mattdm, 17:53:35)
Meeting ended at 17:57:01 UTC.
Action Items
------------
* samkottler to figure out what's needed in koji to get images built
there
* mattdm to kick of thread re google scripts vs cloud-init
Action Items, by person
-----------------------
* mattdm
* mattdm to kick of thread re google scripts vs cloud-init
* samkottler
* samkottler to figure out what's needed in koji to get images built
there
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mattdm (92)
* frankieonuonga (77)
* samkottler (51)
* mrunge (38)
* number80 (21)
* gholms (16)
* nirik (8)
* zodbot (5)
* croberts (3)
* geppetto (2)
* dgilmore (1)
* rbergeron (0)
17:00:31 <samkottler> #startmeeting Cloud WG weekly meeting
17:00:31 <zodbot> Meeting started Wed Nov 13 17:00:31 2013 UTC. The chair is samkottler. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:49 <samkottler> #chair frankieonuonga mrunge mattdm rbergeron number80 geppetto
17:00:49 <zodbot> Current chairs: frankieonuonga geppetto mattdm mrunge number80 rbergeron samkottler
17:01:11 <samkottler> anyone I missed?
17:02:00 <samkottler> #topic rollcall
17:02:05 * frankieonuonga is here
17:02:18 * mrunge is here
17:02:19 * gholms takes a seat in the bleachers
17:02:52 * samkottler waits for a few more people to show up
17:03:28 * frankieonuonga suggests three min
17:03:29 <mrunge> imho red_trela said, he didn't had time for this meeting
17:04:16 <mattdm> hi all
17:04:22 <samkottler> hey mattdm!
17:04:25 <mrunge> hey
17:04:28 <number80> hi
17:04:30 <mattdm> sorry I am in a seriously split brain state :)
17:04:39 <gholms> mattdm: Isn't that the norm these days? :P
17:05:01 <mattdm> gholms apparently. :)
17:05:14 <mattdm> I'd take some time off to collect myself but that would just make the problem worse.
17:05:18 <mattdm> so here we are. :)
17:05:23 <samkottler> I have to head into a read-only state at 12:30
17:05:30 <samkottler> mattdm: are you okay with taking over at 12:30?
17:05:32 <mattdm> okay let's go then. :)
17:05:36 <mattdm> samkottler yep
17:05:39 <frankieonuonga> lets play
17:05:40 <samkottler> mattdm: thanks
17:05:45 <frankieonuonga> welcome guys
17:05:51 <frankieonuonga> i mean welcome folks
17:05:55 <samkottler> #topic agenda items
17:06:01 <samkottler> so GCE
17:06:15 <samkottler> I've been talking with the GCE people this past week and have good news
17:06:22 <mattdm> cool
17:06:26 <frankieonuonga> amazing .
17:06:34 <frankieonuonga> whats up ?
17:06:35 <samkottler> there are a few tools that need to get packaged, but all of them are free software and are on github
17:06:39 <mrunge> what is GCE ?
17:06:44 <samkottler> mrunge: google compute
17:06:48 <gholms> Google compute engine
17:06:55 <mrunge> ah, thanks, I see.
17:06:56 <mattdm> Google Compute Engine. A public cloud provider
17:06:56 <number80> samkottler: list them
17:07:19 <frankieonuonga> cool.
17:07:41 <frankieonuonga> samkottler: packaging should be easy
17:07:42 <samkottler> gcutil and image_bundler are the main two
17:07:48 <frankieonuonga> and at least they are open source
17:07:53 <samkottler> s/image_bundler/image_bundle
17:07:58 <gholms> #info A few tools need to get packaged for GCE support, primarily gcutil and image_bundle. All of them are free software and on GitHub.
17:08:20 <mattdm> I looked at the "what does the image need to look like" instructions
17:08:32 <mattdm> it seems like we are mostly in good shape already
17:09:20 <samkottler> I also spoke with dgilmore about how to get images built in koji and we will likely need to work with mikem to write a plugin to handle it
17:09:31 <mattdm> samkottler what format do the images need to be in?
17:09:44 <samkottler> #action samkottler to figure out what's needed in koji to get images built there
17:09:53 <frankieonuonga> samkottler and dgilmore please loop me into it
17:10:03 <frankieonuonga> that is what is needed for koji
17:10:16 <mattdm> samkottler I think they just want a raw disk file, actually. we already make that
17:10:19 <samkottler> frankieonuonga: absolutely, if you want to take charge on that item feel free :)
17:10:20 <frankieonuonga> this should go in line with rel-eng tasks right ?
17:10:30 <samkottler> mattdm: right, but do we need koji to upload it
17:10:39 <frankieonuonga> ok.
17:10:46 <mattdm> samkottler right now dennis uploads the ec2 images by hand
17:10:46 <samkottler> or do we just handle that externally?
17:10:49 <mattdm> koji doesn't do any uploading
17:11:01 <mattdm> we have the start of a separate uploader service for ec2
17:11:18 <mattdm> but it needs polish and finish. (the stuff andrew worked on last summer)
17:12:20 <samkottler> does someone want to take ownership of creating gcutil and image_bundle packages?
17:12:29 <samkottler> I can do a review for them, but I'm pretty swamped this week
17:12:40 <mattdm> we also maybe should look at GCE cloud-init integration
17:12:43 <mattdm> http://lists.debian.org/debian-cloud/2013/10/msg00004.html
17:12:45 <mattdm> gholms ^
17:12:47 <frankieonuonga> I can take that
17:12:50 <frankieonuonga> not a problem
17:13:02 <frankieonuonga> how soon are they required ?
17:13:22 <mattdm> frankieonuonga it would be pretty nice to have this with F20
17:13:27 <mattdm> so soon :)
17:13:31 <samkottler> frankieonuonga: the sooner the better at this point
17:13:38 <samkottler> yeah, I'd love to get the tools into f20
17:14:04 <frankieonuonga> :-) ok. will look into it and mail you guys tomorrow..but i think i would like to be done by sat
17:14:10 * gholms attempts to find those tools on github
17:14:13 <number80> #info hguemar is looking to package gcutil and image_bundle
17:14:23 <dgilmore> samkottler: we need something out of koji that can run on a releng box and do the uploading
17:14:28 <number80> gcutil is on google code
17:14:41 <samkottler> number80: frankieonuonga already volunteered
17:14:45 <samkottler> you two wanna work together on that?
17:14:59 <samkottler> number80: yeah, I just sent searching again for it, too, and google code is the place
17:15:08 <samkottler> the google folks told me github, not sure why
17:15:18 <gholms> https://code.google.com/p/google-compute-engine-tools/
17:15:24 <number80> https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master...
17:15:35 <number80> i found image_bundle, quite well hidden
17:15:46 <mattdm> number80, gholms, samkottler -- looks like debian is going with the cloud-init integration for running *in* the image
17:16:07 <gholms> mattdm: That's the idea, yeah. Do you happen to know if they bothered to ask upstream as well?
17:16:24 <number80> samkottler: ok, i already started with gcutil last week but i'm fine with leaving image_bundle
17:16:26 <number80> #undo
17:16:26 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x128aebd0>
17:16:28 <mattdm> gholms they said that they would but it might take some time. not sure what that's all about
17:16:45 <samkottler> #link https://code.google.com/p/google-compute-engine-tools/
17:16:49 <frankieonuonga> samkottler: sure we can work on it together with hguemar
17:16:56 <gholms> samkottler: I already posted that one. ;)
17:17:03 <number80> yup
17:17:15 <samkottler> gholms: without hash-link :)
17:17:37 <gholms> samkottler: meetbot has picked up messages that start with links since 2010.
17:17:44 <samkottler> #undo
17:17:44 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x15360710>
17:17:52 <samkottler> gholms: still fresh at this - thanks :)
17:18:05 <gholms> No worries. I'm happy to help. ;)
17:18:18 <samkottler> https://github.com/GoogleCloudPlatform/compute-image-packages
17:18:53 <gholms> I'm a little concerned by that google code page's source browser not actually containing any code, but I guess that's the best we're likely to get.
17:20:26 <samkottler> gholms: yeah, I noticed that too, not really sure what the deal is with it
17:20:30 <samkottler> I can ask the google folks
17:21:01 <samkottler> anyone else got stuff to add before we move on?
17:21:20 * gholms hopes all the bundled libs for gcutil are easy to split out
17:21:27 <mattdm> At some point we will have to decide if we want to configure the instance with cloud-init or google-startup-scripts
17:21:45 <frankieonuonga> mattdm: yeah you are right
17:21:49 <frankieonuonga> i totally agree.
17:22:12 <mattdm> but having them all available seems like a good start :)
17:22:12 <gholms> mattdm: Is the "one image for everything" idea still important?
17:22:12 <samkottler> I don't really like cloud-init all that much, but it's a known beast
17:22:20 <mattdm> samkottler +1
17:22:41 <gholms> cloud-init is kind of annoying, but on the bright side it's portable.
17:22:41 <samkottler> gholms: it is right now, that's a topic for another meeting
17:22:46 <frankieonuonga> can we lay down all pros and cons on email then decide
17:22:52 * gholms nods
17:22:53 <mattdm> +1 to take to email
17:23:00 <frankieonuonga> +1
17:23:12 <samkottler> who wants to kick off that thread?
17:23:49 <mattdm> #action mattdm to kick of thread re google scripts vs cloud-init
17:23:52 <mattdm> me
17:23:52 <number80> +1
17:23:58 <mrunge> +1
17:24:01 <samkottler> thanks mattdm
17:24:45 <samkottler> can we move on to the governance doc?
17:24:56 <number80> yes
17:25:10 <samkottler> #topic governance document review before submission to FESCo
17:25:25 <samkottler> mattdm: this will run longer than 5 minutes, so do you want to take over?
17:25:36 <mattdm> sure
17:25:56 <mattdm> although, um, I think the state of it is "mattdm said he would make some changes and isn't really done doing everything he said he would do"
17:26:06 * nirik has something for open floor if someone can ping me when it gets to that. ;)
17:26:28 * frankieonuonga will ping nirik
17:26:29 <mattdm> also, I think we should take a look at the docs from other groups and regularize language where we can
17:26:40 <number80> just to notice that there were no changes for 2 weeks
17:26:48 <frankieonuonga> is this the PRD?
17:26:50 <mattdm> so my proposal is for me to actually do those things and bring it back next week
17:26:56 <mattdm> frankieonuonga no, governance doc
17:27:01 <number80> frankieonuonga: nope: https://fedoraproject.org/wiki/Cloud/Governance
17:27:01 <mattdm> number80 see above :)
17:27:02 <samkottler> mattdm: isn't it due tomorrow?
17:27:08 <frankieonuonga> I see.
17:27:15 <mattdm> gah. lookit the time.
17:27:31 <mattdm> okay so. new plan. :)
17:27:38 <gholms> Heh
17:28:02 <frankieonuonga> we might need to finlize this thing like now..in terms of pressing issues to be discussed .
17:28:05 <mattdm> I edited the document with the basic changes we agreed to last time.
17:28:15 * samkottler has to go mostly offline now
17:28:20 <mattdm> samkottler kk
17:28:57 <frankieonuonga> so what is basically expected in this doc that is not there
17:29:03 <mrunge> is there anything missing in that document?
17:29:07 <frankieonuonga> are there any issues that need clarification ?
17:29:48 <mattdm> one of the issues in the other documents is quorum
17:30:06 <frankieonuonga> mattdm: kindly expound
17:30:17 <mattdm> eh wait we covered that too
17:30:34 <frankieonuonga> oh yeah…two meetings ago
17:30:37 <frankieonuonga> that we did .
17:30:37 <number80> a quorum of 5 should be ok
17:30:55 <frankieonuonga> we just need to access that log and do what we agreed
17:30:56 <mattdm> okay, so the other thing is that the server wg has a bit about "Each voting member of the working group will confirm their continued membership every six months."
17:30:59 <mattdm> do we want that?
17:31:13 <frankieonuonga> we had talked about this right
17:31:21 <frankieonuonga> we agreed for now..no way.
17:31:34 <frankieonuonga> reasoning behind it was it is a short time to get things going
17:31:43 <frankieonuonga> especially in a field that is still fresh
17:31:57 <mattdm> frankieonuonga I think this was just a way for making sure everyone involved was still active
17:32:04 <mattdm> not a need for a revote
17:32:07 <number80> that's neat though i'd prefer people resigning by themselves
17:32:11 <mrunge> I don't see any issue with refreshing
17:32:27 <number80> the same
17:32:33 <frankieonuonga> wasnt this voted on in that meeting.
17:32:53 <mattdm> frankieonuonga yeah I just wanted to know if we wanted to add their idea
17:32:54 <frankieonuonga> sorry but I feel we might be having the same conversation again
17:33:03 <mrunge> I agree, when anyone can foresee, he has no time to work in the group, I'd expect him/her to resign
17:33:12 <mattdm> okay, so, sounds like we want to leave it as is.
17:33:34 * frankieonuonga nods
17:33:40 <mattdm> do we want to approve it as it is?
17:33:57 <mattdm> do we actually have quorum to do so?
17:33:57 <frankieonuonga> yes.
17:34:01 <mrunge> so, it's and appointment for lifetime?
17:34:10 <mrunge> s/and/an/
17:34:13 <frankieonuonga> i think we need that until we are good to go..
17:34:25 <frankieonuonga> or at least until things are of the ground
17:34:26 <mattdm> mrunge we assume there will be enough natural turnover
17:34:44 <mattdm> other groups went the same way
17:34:45 <number80> mrunge: until you're unable to serve like FPC
17:34:50 <mrunge> mattdm, if we can guarantee that
17:35:00 * croberts croberts is here running late
17:35:12 <mattdm> mrunge what, by making sure we burn everyone out? :)
17:35:18 * frankieonuonga waving at croberts
17:35:29 * mrunge likes fresh ideas from fresh people from time to time
17:35:50 <frankieonuonga> i think if we change ideas too soon when starting we will end up failing
17:35:54 <frankieonuonga> sorry to insist on this
17:36:04 <frankieonuonga> but this was discussed in length earlier
17:36:07 <frankieonuonga> with so many reasons
17:36:10 <samkottler> I'm lurking so I think we have quorum
17:36:15 <mrunge> and refreshing is something like refreshing commitment
17:36:55 <mattdm> mrunge okay, so, like the server wg wording? appointments stay until you step down, but you do need to say you still want to be involved?
17:37:05 <mattdm> I'm okay with either adding that or leaving it open as it is now.
17:37:27 <mattdm> "able and willing", with no hard-coded definition of what that means
17:37:30 <mrunge> mattdm, yes, I like that. that's more encouraging
17:37:54 <mrunge> ...encouraging people to do something,
17:38:22 <mrunge> we might want to change that, e.g time-span, if refreshing just becomes tedious
17:38:33 <mattdm> okay, so: proposal: add wording like server wg's about members confirming their membership every six months
17:38:39 <mattdm> +1 to my own proposal
17:38:45 <frankieonuonga> +1
17:38:49 <geppetto> +1
17:38:49 <mrunge> +1 for that
17:39:10 <number80> +1
17:39:15 <samkottler> +1
17:39:38 <croberts> +1
17:40:00 <mattdm> croberts wait that confuses my counting :)
17:40:11 <mrunge> heh
17:40:27 <mattdm> but anyway
17:40:28 <croberts> :P
17:40:53 <frankieonuonga> :-)
17:40:58 <mattdm> #accepted add wording to charter about commiting to membership every 6 months like server wg (+6)
17:41:06 <mattdm> anything else anyone wants to raise?
17:41:28 <mattdm> i went ahead and did that :)
17:41:52 <mattdm> so: proposal: accept governance charter as https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627
17:42:07 <mattdm> +1 to myself, again
17:42:08 <frankieonuonga> is there any missing content
17:42:19 <frankieonuonga> maybe something to be included ?
17:42:21 <frankieonuonga> i am not sure
17:42:26 <frankieonuonga> that is why i am asking
17:42:46 <mattdm> frankieonuonga Maybe. I like simple. We can always add additional rules / bylaws if needed
17:43:17 <samkottler> remember that we can always amend stuff
17:43:18 <mrunge> do we want to keep the list of members in that document?
17:43:27 <geppetto> mattdm: +1 … seems simple enough.
17:43:29 <frankieonuonga> ok . sounds fine. I know nothing about this ..so I will just agree
17:43:44 <mrunge> ... if members change, that document needs to be reviewed again...
17:43:45 <mattdm> mrunge I think so, because it's important for that to be easily findable.
17:43:46 <samkottler> mattdm: +1
17:43:57 <frankieonuonga> +1
17:44:04 <number80> mattdm: +1
17:44:05 <mrunge> ok. +1 tjem
17:44:09 <mrunge> then
17:44:15 <mattdm> mrunge i think it's implied that that section can change to match reality
17:44:23 <mattdm> okay so that's 6
17:44:39 <mattdm> #accepted governance charter as of https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=360627 ratified
17:44:40 <mrunge> I'd expect that kind of information somewhere, mattdm
17:44:53 <mrunge> (members etc.)
17:45:16 * mattdm notes that when the fedora board changed this year, it took 6 months for the list to get updated. :)
17:45:30 <mattdm> okay, so, fesco meeting soon so let's move on.
17:45:35 <mattdm> #topic open floor
17:45:42 <mattdm> nirik?
17:45:47 <frankieonuonga> let me get nirik
17:45:47 <mrunge> yes
17:45:57 <nirik> Just something to ponder on/bring up:
17:46:31 <nirik> how do you folks see the interaction between the server wg and cloud wg? do you want us to handle the server end and you just do images? or you do both? or ?
17:46:57 <nirik> for example, an openstack server is something we might want to make a server role...
17:47:09 <mrunge> well....
17:47:24 <frankieonuonga> I have a diff opinion
17:47:26 <nirik> I don't know that we need an answer right now, but something to think about?
17:47:26 <mattdm> nirik I think that that's what we're thinking, yes.
17:47:39 <mattdm> nirik looks like we don't have consensus :)
17:47:56 <frankieonuonga> we may need someone on both ends
17:48:00 <mattdm> i think we might provide images for compute hosts in openstack
17:48:06 <frankieonuonga> cause one can not exist without the other
17:48:25 <mrunge> frankieonuonga, no. a server could live without a cloud image
17:48:28 <frankieonuonga> I think that we also need top look at all other platforms
17:48:54 <frankieonuonga> to look i mean
17:49:00 <frankieonuonga> a server could do that
17:49:07 <mrunge> my initial thought saw the cloud wg as wg to provide infrastructure to host cloud images
17:49:20 <number80> nirik: the server WG is quite central due to the various usage, i think that cloud WG will serve as a stakeholder for cloud hosting and we will probably participate to the making and testing
17:49:21 <frankieonuonga> but a server can also exist without having open stack.
17:49:23 <mrunge> and everything in that image will be filled by server wg
17:49:31 <frankieonuonga> there are too many variables
17:50:00 <nirik> right, it's interaction on many levels. ;)
17:50:25 <mattdm> mrunge The Fedora Cloud SIG has traditionally been focused on making Amazon images... in your model there's nothing for us to do. :)
17:50:29 <nirik> there's the bare metal side/server, and then inside cloud instances there could be many servers that people want to run
17:51:08 <frankieonuonga> I think this is something we need to look into for sur e
17:51:10 <frankieonuonga> sure i mean
17:51:20 <mrunge> mattdm, oh yes, there is. but I agreed to shut up ;-)
17:51:27 <mattdm> mrunge lol :)
17:51:43 <mattdm> nirik does that answer your question? heh.
17:51:48 <frankieonuonga> mrunge: dont shut up
17:52:04 <mrunge> frankieonuonga, let's discuss that at a different time
17:52:06 <frankieonuonga> I think this is a healthy conversation
17:52:11 <mattdm> +1 :)
17:52:19 <frankieonuonga> I think we should kick it of on email
17:52:23 <number80> +1
17:52:35 <nirik> yeah, just wanted to start everyone thinking about it.
17:52:44 <frankieonuonga> thanks nirik
17:52:52 <mattdm> frankieonuonga i think this is the 'ZOMG WHAT ARE WE BUILDING?!' thread from last week?
17:53:03 <mattdm> but another thread with a more specific title wouldn't hurt :)
17:53:14 <mattdm> frankieonuonga or mrunge you want to do that?
17:53:25 <mrunge> and I guess, there was an earlier thread as well
17:53:35 <mattdm> #info we need to figure out our interaction with the server wg and how we define what we're doing
17:53:41 <mrunge> mattdm, I can do that
17:53:41 <frankieonuonga> I have already taken a task…I dont want to seem like i am hogging
17:53:54 <mattdm> cool mrunge go for it :)
17:53:56 * frankieonuonga thankful that mrunge has taken that
17:54:15 <mrunge> as if my plate wasn't already full enough
17:54:30 <mattdm> I hear you. :)
17:54:35 <mrunge> no, will do that
17:54:35 <frankieonuonga> no offence
17:54:41 <mattdm> okay, so other topics :)
17:54:45 <mattdm> if any.
17:54:46 <frankieonuonga> which reminds me..what happen to that google thing we were to sign for non disclosure or something like that ?
17:54:56 <mattdm> frankieonuonga ping samkottler on that?
17:55:06 <samkottler> frankieonuonga: email me and I'll have them reach out
17:55:06 <frankieonuonga> ok will do
17:55:13 <frankieonuonga> will do
17:55:39 <mrunge> why should there be an nda? it's under ASL, right?
17:55:55 <mrunge> but confirming is better
17:56:57 <mattdm> okay, so I'm going to end the meeting because I need to grab food quick before fesco starts.
17:57:01 <mattdm> #endmeeting
10 years, 4 months
Summary/Minutes from today's FESCo Meeting (2013-11-13)
by Kevin Fenzi
===================================
#fedora-meeting: FESCO (2013-11-13)
===================================
Meeting started by nirik at 18:00:02 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fesco.2013-11-...
.
Meeting summary
---------------
* init process (nirik, 18:00:02)
* #1195 WG autonomy (nirik, 18:03:20)
* LINK: https://fedorahosted.org/fesco/ticket/1195 (nirik, 18:03:20)
* AGREED: The question is too general. Please bring up specific cases
to FESCo's attention as they come up. Specific cases should include
anything related to differences from existing Fedora policies,
guidelines, or practices. However, autonomy over things already
decreed as allowed by Spins to change can be assumed. We expect this
will becoming more clear over time. (+8,0,0) (nirik, 18:37:31)
* #1196 Set deadline for PRDs (nirik, 18:51:18)
* LINK: https://fedorahosted.org/fesco/ticket/1196 (nirik, 18:51:18)
* AGREED: 2014-01-13 deadline for working groups to provide product
requirement documents to fesco. (+8,0,0) (nirik, 18:59:15)
* #1198 Possible changes to Fedora EOL bug procedure (nirik, 18:59:23)
* LINK: https://fedorahosted.org/fesco/ticket/1198 (nirik, 18:59:23)
* AGREED: defer a week and get more input from bz team. (+8,0,0)
(nirik, 19:18:01)
* #1199 Ratify Base Working Group governance charter (nirik, 19:18:26)
* LINK: https://fedorahosted.org/fesco/ticket/1199 (nirik, 19:18:27)
* AGREED: Charter is approved (+7,0,0) (nirik, 19:28:34)
* LINK: https://fedoraproject.org/wiki/Cloud/Governance (mattdm,
19:28:55)
* #1200 Environments and Stacks WG Governance Document (nirik,
19:28:57)
* LINK: https://fedorahosted.org/fesco/ticket/1200 (nirik, 19:28:57)
* AGREED: Charter is approved (+7,0,0) (nirik, 19:31:25)
* Cloud working group charter (nirik, 19:31:43)
* LINK: https://fedoraproject.org/wiki/Cloud/Governance (nirik,
19:31:47)
* AGREED: Charter is approved (+7,0,0) (nirik, 19:32:56)
* Next weeks Chair (nirik, 19:36:34)
* ACTION: sgallagh to chair next week (nirik, 19:37:30)
* Open Floor (nirik, 19:37:38)
* AGREED: please do not use the official epel branch names if you're
not intending to build for epel itself (+7,0,0) (nirik, 19:50:56)
Meeting ended at 19:52:59 UTC.
Action Items
------------
* sgallagh to chair next week
Action Items, by person
-----------------------
* sgallagh
* sgallagh to chair next week
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (167)
* abadger1999 (78)
* mattdm (54)
* sgallagh (50)
* pjones (50)
* jwb (46)
* notting (39)
* jreznik (33)
* t8m (27)
* pknirsch (20)
* mmaslano (19)
* dgilmore (19)
* mitr (11)
* zodbot (10)
* w4r3d (3)
* tflink (2)
* drago01 (1)
* ajax (1)
--
18:00:02 <nirik> #startmeeting FESCO (2013-11-13)
18:00:02 <zodbot> Meeting started Wed Nov 13 18:00:02 2013 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:02 <nirik> #meetingname fesco
18:00:02 <nirik> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:00:02 <nirik> #topic init process
18:00:02 <zodbot> The meeting name has been set to 'fesco'
18:00:02 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:06 <t8m> hello
18:00:16 * notting is here
18:00:17 <mmaslano> hi
18:00:25 * abadger1999 is here
18:00:26 <sgallagh> .hellomynameis sgallagh
18:00:27 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh(a)redhat.com>
18:01:08 <nirik> morning everyone.
18:01:32 <mitr> Hello
18:02:01 * sgallagh is juggling a number of fires today, so please forgive me if my responses are intermittent
18:02:25 <pjones> yo
18:02:37 <nirik> mattdm: you around?
18:03:02 <nirik> ok, lets go ahead and dive in.
18:03:20 <nirik> #topic #1195 WG autonomy
18:03:20 <nirik> .fesco 1195
18:03:20 <nirik> https://fedorahosted.org/fesco/ticket/1195
18:03:22 <zodbot> nirik: #1195 (WG autonomy) – FESCo - https://fedorahosted.org/fesco/ticket/1195
18:03:24 <nirik> jwb: you around?
18:03:27 <jwb> i am
18:03:38 <sgallagh> nirik: mattdm will be around, he just mentioned disappearing to locate food first
18:03:53 <nirik> fair enough.
18:04:21 * mattdm has food
18:04:41 <pjones> is it soup?
18:04:43 <jwb> are we waiting on me?
18:04:59 <nirik> ok, so I agree with abadger1999 here... this is a difficult thing to write up
18:05:12 <nirik> jwb: no, just wanted you around since you filed the ticket and can add to the discussion? ;)
18:05:20 <jwb> ok
18:05:49 <notting> i do not know that we have a clear enough view where we can define what powers are reserved and what powers are delegated to the states^Wworking groups
18:06:21 <nirik> yeah, it's all kinda still squishy
18:06:38 <nirik> the two areas noted tho have already come up... 3rd party repos and release cycles.
18:06:42 <sgallagh> Proposal: FESCo always has the right to recover any powers it grants to the WGs at need.
18:06:51 <mattdm> pjones it is reheated pad thai
18:06:52 <abadger1999> yeah -- I hope that it might be possible to define in the future but for now it seems more like case-by-case
18:07:04 <pjones> Well, we have representatives in the groups - maybe we can make it their responsibility to raise it on both sides if they think there's a concern, regarding specific issues.
18:07:10 <nirik> sgallagh: I was assuming that was already the case?
18:07:12 <mattdm> I agree with what Toshio said in the ticket
18:07:17 <pjones> i.e. do we actually have to solve this problem for all cases?
18:07:39 <t8m> sgallagh, OK, I think this is implied, however I think we need a mechanism that diverging decisions are escalated or at least announced
18:07:45 <mmaslano> abadger1999: it's not clear to me how draw the line (as you put it)
18:07:48 <jwb> sgallagh, that proposal seems like something you'd do after you actually grant powers to the WGs
18:08:39 <jwb> the specific case taht prompted the broader issue is having packages in the products taht provide .repo files for repositories other than fedora repos.
18:08:43 <sgallagh> jwb: I disagree. After granting powers, deciding that you can take them back would be disingenuous
18:09:01 <pjones> sgallagh: we already have that ability
18:09:04 <mitr> pjones: I think it would be good if we were able to set expectations so that there are few surprises. I'm not sure it's possible.
18:09:07 <pjones> and no, it woudln't. that's absurd.
18:09:16 <jwb> sgallagh, my point was, your proposal isn't really solving the problem.
18:09:19 <nirik> proposal: encourage working groups/liasions to bring to fesco any cases where they plan to diverge significantly from current shared resources or philosophy
18:09:23 <nirik> (ok, that might be to useless0
18:09:25 <notting> jwb: technically, if you say "isn't available in fedora and isn't proprietary", chrome does not fit.
18:09:38 <sgallagh> jwb: Fair enough, I just don't want us locked into any decisions we make today
18:09:40 <jwb> notting, it was the example i was given. is chromium a better example?
18:09:45 <notting> jwb: yes
18:09:48 <jwb> well then assume that
18:09:50 <abadger1999> We could definitely decide on the two specific cases that we know about so far.
18:09:57 <jwb> or assume rpmfusion-free
18:10:04 <pjones> abadger1999: true
18:10:09 <notting> jwb: *bonghits*
18:10:16 <jwb> or assume $some_repo_you_guys_define_as_acceptable
18:10:28 <nirik> so, what are those exact examples?
18:10:41 <dgilmore> we really need to have fesco layout release schedules and lifecycles
18:10:48 <notting> nirik: i think without defining 'shared resources or philosophy', it leaves it rather vague
18:10:56 <nirik> notting: yeah, it does. ;(
18:11:02 <sgallagh> How about distributing RPMs for COPR repos?
18:11:08 <pjones> dgilmore: that's really not what we're talking about right now at all.
18:11:11 <sgallagh> That's a more clear example, I think
18:11:13 <nirik> jwb: can you provide the specific repo cases you were seeing?
18:11:25 <abadger1999> pjones: well, that was the other specific example I was thinking of.
18:11:56 <sgallagh> abadger1999: What was?
18:11:57 <abadger1999> "Can the products define their own separate release schedules and lifecycles"
18:11:57 <pjones> oh, well, okay.
18:12:03 <dgilmore> pjones: its something that cant be up to the Working Groups to decide. but sure
18:12:04 <nirik> dgilmore: thats the next case after this repo one. ;)
18:12:05 <jwb> nirik, chromium is about as acceptable of an example as i can come up with. the general idea is "repo files not fedora"
18:12:11 <dgilmore> nirik: cheers
18:12:29 <pjones> dgilmore: nevermind, I hadn't realized that's where abadger1999 was actually going, thought you were just bringing that up randomly since there was no context.
18:12:30 <jwb> nirik, so if there are limits around what "not fedora" means and we need explicit approval for each repo, fine
18:12:32 <nirik> jwb: but what about them? can we ship them in fedora rpms? can we enable them by default? can we ship them but not enable them?
18:12:41 <dgilmore> pjones: sorry.
18:12:47 <jwb> nirik, can the products enable them by default i believe
18:13:13 <jwb> or point users to them
18:13:16 <nirik> I'd say: no. But they could offer them to the user to accept?
18:13:17 <mattdm> jwb this actually may be a question for _legal_
18:13:36 <jwb> mattdm, this specific one, sure. the broader question of what autonomy the WGs have isn't
18:14:07 * nirik nods.
18:14:08 <jwb> and if we can't settle on a general method of operation, then we have problems
18:15:05 <jwb> so if FESCo's proposal is "the liaison is responsible for bringing any unclear decisions to fesco"... well that's what we can do but it isn't particularly clear.
18:15:05 <notting> nirik: well, we already have policies on packaging of third-party repo files. so that would be a matter of saying 'these still apply'
18:15:09 <abadger1999> I know it's a departure from precedent but I lean towards allowing enabling by default but retaining fairly tight control over what repos are allowed.
18:15:12 <nirik> so, in this case should we forumate some questions for legal? or?
18:15:34 <jwb> notting, sure. that's why i brought up the question. we have policies saying we don't do it. the draft PRD for Workstation hints at wanting to do it. discuss.
18:15:39 <mattdm> jwb Yeah but this one may not be a good test case for establishing the general
18:15:42 <nirik> notting: right, which is "do not"
18:15:51 <pjones> abadger1999: I really do as well, if only because it affects users' choice of which product they actually want
18:15:52 <jwb> mattdm, so discuss the general without an example.
18:15:53 <notting> nirik: it's "only in %docdir", actually
18:15:54 <mmaslano> jwb: what if we (fesco) just review list of approved decision and decide only about those, which are questionable?
18:16:03 <nirik> notting: ok.
18:16:03 <sgallagh> May I suggest that we're diving into a specific example that should probably have its own FESCo ticket?
18:16:05 <dgilmore> jwb: i guess they bring a proposal to FESCo saying please change this policy
18:16:07 <jwb> mmaslano, possible.
18:16:12 <jwb> dgilmore, consider it brought.
18:16:18 <sgallagh> That we can think on and discuss next week.
18:16:41 <t8m> sgallagh, +1, let's try to at least somehow solve the general problem first
18:16:44 <nirik> abadger1999: so, perhaps 'repos that only contain free software' ? or some other critera?
18:17:25 <dgilmore> pretty sure i was part of FESCo when it was decided to ban them, because someone decided mainting the package in Fedora was too hard, so they pushed an update that basically replaced the package with and enabled .repo file pointing to their external upstream repo
18:17:26 <sgallagh> nirik, abadger1999: Can we please just address this separately from the general question?
18:17:43 <nirik> dgilmore: yep. I recall that as well.
18:17:50 <notting> jwb: hm, "workgroups have autonomy over their content set, over anything that can be resonably considered 'default configuration', and over the implementation of services not provided by the TBD base layer. anything that refers to general fedora policies should be brought for reconsideration in terms of the product split. release cycles & lifetime is all TBD anyway."
18:17:52 <abadger1999> sgallagh: we can but... I don't think we can address the general question with a definite answer.
18:17:57 <jwb> dgilmore, and yet, now we have coprs. designed to do that explicitly ;)
18:18:04 <jwb> LOLOLOLOLOLOL ;)
18:18:15 <sgallagh> abadger1999: Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up.
18:18:48 <jwb> sgallagh, again, i'm fine with that but you need to be aware that it's nebulous and possibly error prone
18:18:51 <dgilmore> jwb: sure. things change, maybe its time we changed the policy, adding soem restrictions on what can be in .repo files, but thats likelylegals call on hats okay
18:18:54 <dgilmore> whats
18:19:01 <mattdm> In general, Working Groups should have autonomy over decisions which are "self contained". These decisions do need to stay in line with Fedora's overall guiding principles. When decisions have impact beyond that Working Group (impact on other WGs or on existing Fedora subprojects like rel-eng, qa, design, etc.), FESCo will mediate and ultimately make decisions if need be.
18:19:02 <sgallagh> jwb: More so than a blanket statement about autonomy?
18:19:05 <abadger1999> sgallagh: with the caveat that once we have decided on a few (for some definition of few) we might be able to address the general question.
18:19:05 <mmaslano> sgallagh: +1 I don't see how can we specify boundaries
18:19:29 <sgallagh> abadger1999: I think sensible boundaries may start to appear as we go forward, yes.
18:19:41 <drago01> mattdm: "design" ?
18:19:41 <sgallagh> But let's not derail this meeting thinking up such cases.
18:19:47 <jwb> sgallagh, not moreso, just differently. it means the WG has to read FESCo's mind on what is questionable, instead of FESCo reviewing decisions.
18:19:57 <mattdm> drago01 https://fedoraproject.org/wiki/Design
18:20:26 <abadger1999> liasons should err on the side of caution -- bring to fesco things that are controversial, may have been in conflict with past policy, or represent new directions for fedora.
18:20:55 <t8m> abadger1999, +1
18:20:57 <abadger1999> over time we'll figure out areas where fesco does not have to be involved in future decisions of that sort.
18:21:14 <pjones> I've got an idea. Why don't we leave this as an open question to be discussed occasionally, with everybody keeping an open eye towards the fact that we might eventually have to actually say something about it while they go about their WG work ;)
18:21:39 <sgallagh> pjones: I think you just rephrased my proposal there, so +1
18:21:44 <nirik> pjones: +1, sure.
18:21:47 <abadger1999> pjones: that works for me.
18:21:50 <abadger1999> +1
18:21:52 <pjones> (There, I've invented the FESCo Select Committee On Whether WGs Have Gone Too Damn Far ;)
18:21:52 <mitr> jwb: We've had an example of how expecting FESCo to notice the problematic changes without the change initiator explicitly trying to communicate doesn't work, just las week
18:22:06 <mattdm> jwb does that address your concerns well enough at this point?
18:22:13 <notting> pjones: i'm not sure that *solves* the issue, but it may be reasonable
18:22:25 <pjones> notting: it wasn't intended as a solution, no.
18:22:34 <jwb> mitr, "failing to notice" is exactly what will continue to happen if the WG doesn't think they're decision is controversial
18:22:39 <nirik> mitr: hopefully our liasions will help?
18:22:40 <sgallagh> mitr: How is that relevant? If the WG liason doesn't communicate a controversial chagne to us, it doesn't change anything
18:23:09 <sgallagh> Perhaps we should make that a clear part of the liason job-description?
18:23:17 <t8m> sgallagh, definitely
18:23:20 <nirik> well, it's always going to come down to judgement...
18:23:22 <abadger1999> Note that controversial needs to mean, not just controversial within the WG but within Fedora as a whole, with a knowledge of past history as well.
18:23:38 <mitr> sgallagh: I think therefore that "reading FESCo's mind" is something we actually have to expect and ask, even though it sounds ... kind of difficult
18:23:44 <nirik> unless we say: "all working group decisions must be ratified by fesco" which is insane micromanaging doom.
18:23:45 <pjones> the simple fact of the matter is that if FESCo isn't /paying attention/ to what the WGs do, this whole thing is *going* to fail.
18:24:01 <pjones> and I use that phrase as opposed to "looking over the shoulder" or "backseat driving" on purpose.
18:24:14 <pjones> (or, you know, pick your euphemism)
18:24:14 <jwb> nirik, there's a middle ground
18:24:26 <t8m> which means the FESCO liason role is pretty critical one
18:24:34 <abadger1999> pjones: <nod> Which is kinda why we included the fesco liasons I think... of course with the liasons not actually being on fesco in all cases, it makes things a little bit different.
18:24:40 <notting> alternately: "if a WG is intending to do something against current stated Fedora policies, please raise"
18:24:45 <pjones> t8m: yes. but it also means that WGs and FESCo both need to be keeping that in mind as they go about their business.
18:25:04 <dgilmore> pjones: completely agree, im taking the approach that I have to actively monitor what WG's are doing so i can stay on top of what deliverables will be and if we work out ho to deliver them
18:25:23 <nirik> jwb: sure. agreed, but that middle ground will be a judgement call... either on the liasion's part or fesco or whoever thinks it needs to be discussed by fesco
18:25:53 <nirik> notting: I could agree to that too.
18:25:53 * sgallagh is glad there are three FESCo members on the Server WG. Nothing is likely to sneak by unnoticed there...
18:26:31 <pjones> sgallagh: or that makes it the worst one for that ;)
18:27:23 <abadger1999> notting: although that's not a complete description of the problems that should be raised... there's actually very few things fesco has officially called policy...
18:27:32 <nirik> so, where are we? enough votes to leave this open and continue to look at? enough votes to accept any of the other proposals? new proposal?
18:27:59 <notting> abadger1999: packaging policies, forbidden items, etc.
18:28:08 <notting> update guidelines... there's a lot of things.
18:28:16 <mmaslano> nirik: probably not enough votes, let's vote once again on sgallagh proposal
18:28:35 <t8m> mmaslano, which one?
18:28:59 <abadger1999> notting: But equally, reboot to install updates, one dep solver, backwards compat focus...
18:29:04 <sgallagh> Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. abadger1999's addition: once we have decided on a few (for some definition of few) we might be able to address the general question
18:29:16 <mmaslano> Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up.
18:29:30 <mmaslano> sgallagh: yeah, this one +1
18:29:36 <sgallagh> +1
18:29:48 <nirik> +1 sgallagh (I assume that means keeping the ticket open and trying to address it as we move forward more)
18:29:55 <t8m> sgallagh, +1
18:29:56 <sgallagh> nirik: Yes
18:30:05 <notting> i'm leery b/c this doesn't give much guidance on the type of questions to bring. doesn't seem like enough of an answer
18:30:21 <nirik> notting: counter?
18:30:34 <jwb> notting, that's my concern
18:30:36 <abadger1999> <nod> I think we've said a lot of things in this meeting about type of questions to bring... but they aren't reflected in the Proposal.
18:30:54 <notting> nirik: "Specific cases should include anything related to differences from existing Fedora policies or guidelines."
18:31:25 <abadger1999> and also existing practice.
18:31:41 <pjones> yeah, I think "existing practice" is actually the big (and quite vague) on there
18:31:45 <abadger1999> which is the hardest part to nail down.
18:31:49 <abadger1999> <nod>
18:31:56 <pjones> because obviously there will be a big change to existing practice by /having/ the WGs
18:32:04 <sgallagh> At some point, no matter what, this will be a judgement call by the liasons.
18:32:13 <jwb> why you work this out, it's clear you want me to open a ticket specifically for the repo question right?
18:32:20 <sgallagh> Why don't we assume we can trust them to do their jobs properly until proven otherwise?
18:32:20 <pjones> sgallagh: not by the liasons. By the WGs and by FESCo.
18:32:23 <notting> jwb: yes
18:32:26 <abadger1999> jwb: yes please.
18:32:30 * jwb goes to open a ticket
18:32:31 <nirik> yep. please do
18:32:46 <notting> could add "Autonomy over things already decreed as allowed by spins to change can be assumed."
18:33:07 <pjones> sgallagh: the job of the liason is to make sure the WGs and FESCo are communicating appropriately. That includes bringing issues like this up, but mostly it's making sure we're all informed enough to see them coming.
18:33:12 <abadger1999> notting: +1
18:33:52 <nirik> notting: so, what does that give us for full proposal?
18:34:09 <sgallagh> pjones: I agree. I think that's the point I was trying to make, but just putting a certain measure of responsibility on the liason
18:34:19 <sgallagh> nirik: Spaghetti?
18:34:25 <pjones> it's the opposite of what you said, though.
18:34:26 <nirik> yummy. ;)
18:34:46 <notting> "The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed."
18:34:58 <sgallagh> notting: +1
18:34:59 <notting> "We expect that this will become more clear over time."
18:35:14 <nirik> so, this implies closing ticket?
18:35:20 <mattdm> notting +1
18:35:30 <abadger1999> notting: +1
18:35:39 <mmaslano> notting: +1
18:35:45 * abadger1999 doesn't care if we close the ticket or have it as a standing item.
18:35:49 <nirik> sure, +1
18:35:58 <pjones> I think a standing item may still be better, but +1
18:36:06 <abadger1999> It could be like open floor.
18:36:06 <mattdm> I would like to add (maybe just informally) that we don't necessary plan to *block* change, but we just want to _talk about it_.
18:36:20 <t8m> notting, +1
18:36:24 <mitr> notting: +1
18:36:28 <pjones> mattdm: I'd have thought you'd have learned that people read that the same way ;)
18:36:37 <abadger1999> mattdm: well.... I think it all depends on the change and also as the time frame we talk about.
18:36:55 <abadger1999> So at this point... I think it's still case-by-case.
18:36:56 <mattdm> pjones *sigh*
18:37:02 <notting> erm, then "We expect that this separation will become more clear over time, and policies and practices will change over time."
18:37:27 <mattdm> abadger1999 right obviously not all changes are rubber stamped. But we aren't anti progress, or else we wouldn't be doing _any_ of thise.
18:37:31 <nirik> #agreed The question is too general. Please bring up specific cases to FESCo's attention as they come up. Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices. However, autonomy over things already decreed as allowed by Spins to change can be assumed. We expect this will becoming more clear over time. (+8,0,0)
18:37:32 <abadger1999> notting: +1
18:37:43 <nirik> you want me to amed? its already really long. ;)
18:38:08 * pjones thinks that's good enough.
18:38:14 <nirik> move on?
18:38:27 <sgallagh> please
18:38:38 <nirik> jwb was filing ticket for the repo thing... do we want also another ticket for release cycle?
18:38:56 <dgilmore> nirik: I think its something that needs to be made clear
18:39:02 <abadger1999> nirik: yep. Should we ping pknirsch to do that?
18:39:06 <dgilmore> nirik: so from my perspective please
18:39:18 * pknirsch is lurking!
18:39:21 <pknirsch> whatup!
18:39:25 <nirik> sure. I don't care who does it, but we should ask for input from all the working groups on it.
18:39:45 <nirik> I know there's been talk of different release cycle in the server wg...
18:40:02 <dgilmore> nirik: well if we dont have a consistent release cycle for all products we lead to insanity and confusion
18:40:15 <nirik> dgilmore: +1 from me on that.
18:40:32 <mattdm> release cycle is clearly something that affects us all.
18:40:37 <pknirsch> mhm
18:40:47 <dgilmore> yep, which falls to FESCo to set
18:40:50 <nirik> pknirsch: can you file a fesco ticket about release cycles and needs for the various groups and if it should be the same for all, etc?
18:40:52 <abadger1999> Ah -- also related to the previous proposal... we should make sure to specifically alert all the fesco liasons about the decision and to read the fesco discussion.
18:40:56 <nirik> or I guess I could do it?
18:41:10 <t8m> abadger1999, +1
18:41:20 <nirik> abadger1999: good idea. Would someone be willing to send them all email about it? ;)
18:41:35 <abadger1999> nirik: yep, I'll take that on.
18:41:40 <nirik> and note the release cycle ticket too perhaps?
18:41:47 <ajax> "consistent" and "uniform across products" aren't necessarily the same thing.
18:41:57 <pknirsch> nirik: i can if you want to, or abadger1999 :)
18:42:34 <abadger1999> ajax: <nod> Although I think we probably want uniform across products for at least a few releases while we get our footing.
18:42:34 <pknirsch> at the end of the day though should we mandate a release cycle for all products? also future ones?
18:42:43 <pjones> I don't think they need to all be /the same/ release cycle. I do think they all need to be a part of the same broader plan.
18:42:50 <pknirsch> i mean, if some product decides to only do rolling releases?
18:42:56 <mattdm> pjones +1 broader plan!
18:43:01 <abadger1999> Creating three (or four depending on what base design decides their scope is) is going to be hard enough.
18:43:03 <pknirsch> what that then be shut down?
18:43:26 <pjones> pknirsch: I think "no rolling releases" fits well within "Specific cases should include anything related to differences from existing Fedora policies, guidelines, or practices."
18:43:27 <abadger1999> *three or four products
18:43:28 <pknirsch> s/what/would/
18:43:39 <pjones> pknirsch: i.e. that's not an option right now without more discussion on it specifically
18:43:46 * pknirsch nods
18:44:04 <nirik> pknirsch: hard to say without more details, but that is less of a bad case in my mind than 'product 1 wants to release 6 times a year' 'product 2 wants to release 3 times' etc
18:44:16 <pknirsch> nirik: right
18:44:32 <dgilmore> they need to be on the same release cycle
18:44:33 <pknirsch> as base would have to do lots of releases then
18:44:41 <pknirsch> dgilmore: right
18:44:50 <dgilmore> released on the same day, eol on the same day
18:45:09 <pknirsch> well, one product could decided to eol one release later?
18:45:13 <pknirsch> maybe?
18:45:19 <nirik> anyhow, would someone be willing to file this ticket? I don't know we can/should discuss this without more input right now.
18:45:20 <dgilmore> but doing things like cloud update images monthly should be allowed
18:45:30 <pknirsch> good point
18:45:33 <dgilmore> pknirsch: no eol needs to be the same
18:45:41 <mattdm> even the update images (which I'm all for!) would be nice in broader context.
18:45:57 <pknirsch> dgilmore: hm, thats going to be really tricky though. there will be no possibility for long time releases then
18:45:57 <tflink> if the different products are on different timelines, qa processes like blocker bugs may also need to be changed
18:46:19 <dgilmore> pknirsch: there is, just that all products get it
18:46:21 <pknirsch> dgilmore: but i understand your point
18:46:33 * nirik can file that. ;)
18:46:34 <nirik> Shall we move on ?
18:46:35 <mitr> Let's give this more time - at least in server WG we are not nearly agreed on what we want, perhaps some of the options will be eliminated before this even gets to FESCo
18:46:47 <pjones> mitr: +1
18:46:56 <nirik> mitr: yes, I'll file a ticket and we can collect input.
18:47:03 <abadger1999> nirik: yes please -- we need to discuss this but we probably should do it next week after people have a chance to write ideas into the ticket.
18:47:11 <nirik> or you are saying 'wait to file the ticket even' ?
18:47:33 <pjones> Bludgeoning "it must be this way" policy down is not the way, and we shouldn't do it. What we should do is let people consider what would be best, and then try to arrive at a sensible master plan for the whole thing that includes as much of that as possible.
18:47:50 <nirik> ok, then:
18:48:31 <pjones> s/people/WGs/
18:48:38 <t8m> pjones, +1
18:48:50 <mattdm> pjones +1
18:48:52 <nirik> I guess I can see starting to collect ideas now, or waiting.
18:49:54 <nirik> proposal: file fesco ticket to collect ideas on lifecycle and release cadence
18:50:10 <abadger1999> I think that timeframe and allocating new resources would be the big things
18:50:50 <nirik> very much so.
18:51:01 * pknirsch nods a lot
18:51:05 * nirik listens to crickets. ok, I'll file and move on then.
18:51:06 <abadger1999> ie: we don't say you can never do that but rather, you can't do that for the next release and you need to talk to X, Y, Z about what human resourcs you need to bring to the table to make it happen.
18:51:18 <nirik> #topic #1196 Set deadline for PRDs
18:51:18 <nirik> .fesco 1196
18:51:18 <nirik> https://fedorahosted.org/fesco/ticket/1196
18:51:19 <zodbot> nirik: #1196 (Set deadline for PRDs) – FESCo - https://fedorahosted.org/fesco/ticket/1196
18:51:29 <nirik> I'm fine with the poposed date in there.
18:52:04 * pjones too
18:52:06 <jwb> um
18:52:13 <t8m> +1 to the proposed date
18:52:15 <pjones> that's two months from today
18:52:17 <jwb> yeah, so it would have been nice to be CC'd on this ticket
18:52:31 <jwb> <- not in fesco. don't get ticket email by default.
18:52:34 <abadger1999> fesco meetings are on wed... maybe tuesday would be a more practical deadline :-)
18:52:53 <nirik> jwb: possibly all liasions would have been good to cc.
18:52:54 <pjones> abadger1999: I think the idea is to give us each a full day to read it
18:52:55 <abadger1999> but yeah, +1 for that week.
18:53:02 * nirik wonders if we should make an alias. ;)
18:53:08 <pjones> abadger1999: which I can certainly get behind.
18:53:11 <pjones> nirik: probably, yes
18:53:15 <abadger1999> or just cc all liasons on all fesco tickets?
18:53:23 <abadger1999> (like the fpc point of contacts)
18:53:30 <t8m> nirik, what about just adding all liaisons to the fesco alias
18:53:49 <t8m> nirik, being there does not give them the power to vote on FESCo :)
18:54:01 <nirik> t8m: it's a list...
18:54:16 <t8m> s/alias/list
18:54:19 <t8m> then
18:54:21 <nirik> abadger1999: we could, we can add anyone to bcc to fesco tickets on trac
18:54:23 <abadger1999> is there a separate fesco list and alias?
18:54:30 <nirik> no alias. it's a lsit.
18:54:36 * abadger1999 sees that answer jsut before he asks it
18:54:55 <nirik> jwb / pknirsch: would you like to get cc'ed on all fesco tickets? or is that too much noise?
18:55:03 <pknirsch> nirik: please do!
18:55:05 <abadger1999> I don't know -- previous fesco's set it up to be private to fesco.
18:55:06 <jwb> i'm fine with it
18:55:25 <abadger1999> so yeah, I'm more +1 to the CC plan.
18:55:38 <t8m> I'd say that FESCo liaison should have most of FESCo member privileges except the voting :)
18:56:01 <nirik> ok, can do.
18:56:02 * abadger1999 really needs to include more context in his messages so people know what he's +1 to and what he's not :-)
18:56:05 <sgallagh> t8m: Isn't voting the *only* privilege?
18:56:07 <notting> and i can't imagine someone would be in a position to be a liason and not be comfortable with excessive amounts of e-mail
18:56:07 <nirik> ok, back to this ticket... shall we vote? or ?
18:56:22 <notting> nirik: yup, that's a date. +1
18:56:25 <abadger1999> +1
18:56:34 <mattdm> +1
18:56:41 <notting> (i.e., it's arbitrary, but it's a defined arbitrary and therefore better than before)
18:56:43 <t8m> sgallagh, well if you do not count receiving more mail as privilege ;) ;)
18:56:44 <sgallagh> nirik: We're voting on the Monday I suggested?
18:56:58 <sgallagh> the 13th?
18:56:59 <mmaslano> +1 to CC
18:57:02 <sgallagh> If so, +1
18:57:36 <abadger1999> sgallagh: correct.. except for mmaslano who's apparently voting on dding liasons to the trac CC :-)
18:58:11 <nirik> so, thats +7?
18:58:17 <nirik> (so far)
18:58:32 <mitr> +1 on the date
18:59:15 <nirik> #agreed 2014-01-13 deadline for working groups to provide product requirement documents to fesco. (+8,0,0)
18:59:23 <nirik> #topic #1198 Possible changes to Fedora EOL bug procedure
18:59:23 <nirik> .fesco 1198
18:59:23 <nirik> https://fedorahosted.org/fesco/ticket/1198
18:59:26 <zodbot> nirik: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198
19:00:08 * jreznik is here to answer question, summary in the ticket
19:00:20 <mattdm> yeah, so I was shocked when I learned it worked this way.
19:00:22 <sgallagh> mattdm: Want to phrase this as a soundbite we can vote on?
19:00:24 <nirik> so, whats the proposed change?
19:01:22 <jreznik> the remaining question is what to do with that reopen issue
19:01:37 <jreznik> otherwise we already do it in the way mattdm proposed
19:01:40 <mattdm> a) leave bugs in needinfo state until the _next_ product as closed b) close as INSUFFICIENT_DATA instead of WONTFIX and c) change the message asking people to either file a new bug or ping an ombudsman of some sort (a role we don't have but I think we should)
19:01:43 <nirik> I'm very - on leaving things open in needinfo personally..
19:02:00 <jreznik> nirik: for how long?
19:02:06 <mattdm> nirik are you okay with a _longer_ needinfo?
19:02:07 <abadger1999> jreznik: just one clarification -- anyone in the fedora packager group can reopen correct?
19:02:09 <nirik> no.
19:02:16 <notting> only filer can?
19:02:18 <nirik> say you have a f18 bug...
19:02:23 <notting> or no one, b/c we close the product?
19:02:25 <mattdm> notting filer _cannot_
19:02:28 <mattdm> notting right.
19:02:40 <mattdm> actually, except I can. possibly all packagers can.
19:02:42 <nirik> you provide a patch or detailed info on how to fix it.
19:02:46 <mattdm> but regular users can't.
19:02:46 <jwb> fwiw, the kernel team uses a needinfo period of 2 weeks, then clsoe with insufficient_Data
19:02:54 <nirik> but the maintainer does not get to it. f18 goes eol.
19:02:56 <jwb> regardless of release standpoint
19:03:07 <nirik> the needinfo is wrong there. There's no info needed. It will never get fixed in f18
19:03:15 <mattdm> jwb that's not a big issue because people can reopen. it only becomes a big issue once the whole _release_ is closed.
19:03:23 <jreznik> for c) initially there was "clone a bug" but I think that was jwb who asked me to change that, we wasn't aware of that reopen issue
19:03:32 <mattdm> nirik info is "is this still an issue?"
19:03:47 <nirik> and you clear that and it's a open f18 bug.
19:03:47 <mattdm> cloning is kind of terrible in bugzilla
19:03:49 <jwb> cloning a bug is horrible. please don't do that
19:03:51 <jreznik> nirik: but it could be fixed in next version
19:04:16 <t8m> hmm what about automatically changing the product to next fedora and putting in needinfo and closing if still in needinfo this fedora is closed
19:04:17 <jreznik> jwb: well, c) proposed by mattdm is now - file a new bug
19:04:18 <mattdm> nirik -- i'm okay with forcing an update of the version if we can do that.
19:04:45 <mattdm> jreznik but to be clear I only think that's okay if we give people a longer window.
19:04:52 <nirik> t8m: hard to sort out... and confusing for maintainers that it's not right version
19:05:20 <nirik> mattdm: right, i don't know if thats possible, but I would be ok with that... if you reopen, it forces it against rawhide or last stable or something.
19:05:22 <mattdm> "My bug was closed and Fedora doesn't care about me" is in the top ten things I hear from people when asking for feedback on their experience with us.
19:05:37 <notting> you can't repoen while changing release? or we don't give you an interstitial that allows that?
19:05:49 <jreznik> mattdm: that's the problem - we can't fix all bugs... never, ever...
19:06:17 <sgallagh> I have to run for today, sorry.
19:06:28 <jreznik> and I think it's better to admit we're not able to fix it over letting it open indefinitely and waiting for miracles
19:06:35 <mattdm> notting right now, the users have no option to do either.
19:06:38 <abadger1999> mattdm: note -- this wouldn't change it really... the real problem is that no maintainer is looking at that set of bugs.
19:06:50 <nirik> notting: not sure. I think it won't let non fedorabugs/priv people reopen and change version... or it doesn't make clear you have to do that and won't let it happen until you do
19:07:24 <jreznik> nirik: so the question is if we can grant these privs and how sane it is to grant this privs
19:07:34 <mattdm> I think having a "bug ombudsman" role is really what we need. I'm not volunteering for that (I might have, about 8 years ago...)
19:07:47 <nirik> I don't know... bugzilla folks haven't answered the bug mattdm opened yet. ;)
19:07:50 <jreznik> mattdm: what's bug ombudsman?
19:08:00 <jwb> chief triager.
19:08:03 <jreznik> nirik: so I'll try to check with them
19:08:19 <nirik> bugzapper? :)
19:08:26 <jreznik> jwb: it's sad we don't have triagers anymore but I understand nobody wants to do it...
19:08:33 <mattdm> I hear the point about more honest / real problem / lots of bugs / etc., but it really is leaving a bad taste in users' mouths
19:08:36 <jwb> i do it all day long and i don't want to do it.
19:09:24 <abadger1999> mattdm: I mean -- leaving hte bug open with no comments for multiple releases is still going to leave a bad taste in users' mouths.
19:09:32 <jreznik> mattdm: trust me, I'd be more than happy to close 0 unfixed bugs over 9000...
19:09:34 <nirik> I agree it can be improved... I'm just not clear on what we can do to improve it yet.
19:09:44 <jreznik> abadger1999: yep
19:09:55 <mattdm> abadger1999 yeah, but closing it with no opportunity to respond is like a poke in the eyes on top of that.
19:09:57 <jreznik> it also helps maintainers to clear a bit theirs backlog
19:10:08 <jreznik> mattdm: and we're trying to solve this problem
19:10:09 <nirik> I'm against mattdm's a and b... I think a bug triager/ombudsmen would be great, but not sure who will do it. ;)
19:10:47 <jreznik> mattdm: it was mistake, we weren't aware of this rebase/reopen issue at that time, it's there just one release
19:11:02 <mattdm> jreznik I'm told that it has been the case for several years.
19:11:03 <jreznik> and I'll be more than happy to fix it
19:11:07 <mattdm> I it's hard to test that.
19:11:10 <nirik> proposal: defer a week and ask bz folks for any technical help they can give us and if any folks want to try and be ombudsmen.
19:11:17 <jreznik> mattdm: no, previously we said "clone a bug" and it worked
19:11:37 <mattdm> ah I see. before _that_, was said "reopen", and _that_ worked.
19:12:02 <nirik> right... first break was old versions getting closed to new bugs
19:12:03 <jreznik> but kernel guys were unhappy about clones, kde guys...
19:12:09 <mattdm> When I started this whole mass-closing of bugs at Fedora Core 2 or whenever, I actually added myself to the CC of each one.
19:12:15 <mattdm> and handled any complaints.
19:12:16 <nirik> then cloning fixed that, then it broke with telling people reopen
19:12:28 <jreznik> nirik: yep
19:12:30 <notting> i agree we should advise something that works
19:12:32 <mattdm> But in order for someone to do that now, I think it would be a full-time job.
19:12:34 <nirik> I read thru all the ones I get.
19:12:47 <jreznik> mattdm: it would be more that full time job
19:12:57 <nirik> and if anyone replies to them I'm happy to reopen. I think it's happened once or twice
19:13:06 <jreznik> I try to take a look at least on a few bugs I'm closing but 9000 is 9000
19:13:17 <abadger1999> notting: +1
19:13:21 <notting> *a* proposal could be to lengthen the period before closing, and change the message back to clone
19:13:28 <jreznik> so change the wording?
19:13:31 <notting> if people don't want clones, i'm fine with waiting for bz team ideas
19:13:52 <abadger1999> maybe change wording to "clone or reopen if you're a fedora packager"
19:14:21 <mattdm> jreznik you don't have to look at every one, but it would be good if there were an opportunity for users to get help without feeling abandoned.
19:14:23 <nirik> well, comments still work for users after the version closes? or no?
19:14:26 <jreznik> notting: I'm not sure about that longer period... if one month is not enough, half year would not be enough neither... people react on the warning and eol, in between not many bugs are updated
19:14:37 <jreznik> nirik: yes
19:14:52 <notting> jreznik: i can let that go
19:14:57 <mitr> mattdm: That's almost equivalent to "it would be good if bugs got fixed" - true, but we haven't even started thinking how to do that
19:15:03 <abadger1999> if bz team can provide a fix that's even better but I wouldn't want to keep the wrong advice while waiting :-)
19:15:03 <nirik> then we could add "or comment on this bug to have the maintainer reopen it for you" but that only works if the maintainer or a cc'ed person is looking
19:15:08 <abadger1999> nirik: uhh....
19:15:10 <notting> but i think we should definitely either change the wording so it gives the users an option that works, or fix the reopening
19:15:11 <jreznik> mattdm: it's fedora - you have to be active to get stuff done sometimes...
19:15:32 <abadger1999> nirik: yeah -- I think many of htese bugs are being closed in the first place because the maintainer isn't actively watching and dealing with the bug.
19:15:35 <nirik> well, we just need to decide wording in the next month or so right?
19:15:36 <jreznik> notting: yep, I'm sad the change caused this issue
19:16:03 <notting> i'm ok with leaving it for a week to get bz maintainer input
19:16:06 <abadger1999> so depending on them to reopen is... less than optimal.
19:16:07 <jreznik> maybe encourage people to try to talk to maintaner?
19:16:21 <abadger1999> notting: +1
19:16:35 <t8m> abadger1999, +1
19:16:35 * nirik is ok with that too. Hopefully they can help us.
19:17:01 <mmaslano> notting: +1
19:17:03 <nirik> mattdm: ok with you?
19:17:03 <t8m> notting, +1
19:17:09 <abadger1999> <nod> and if not we can change the wording next week.
19:17:15 <jreznik> abadger1999: yep
19:17:20 <pjones> notting: +1
19:17:33 <mattdm> nirik Yeah, I can wait. My main concern is making sure users don't feel like their involvement results in a slap in the face.
19:18:01 <nirik> #agreed defer a week and get more input from bz team. (+8,0,0)
19:18:11 <nirik> mattdm: sure, I agree we should make it better for sure.
19:18:26 <nirik> #topic #1199 Ratify Base Working Group governance charter
19:18:26 <nirik> .fesco 1199
19:18:27 <nirik> https://fedorahosted.org/fesco/ticket/1199
19:18:28 <zodbot> nirik: #1199 (Ratify Base Working Group governance charter) – FESCo - https://fedorahosted.org/fesco/ticket/1199
19:18:51 <w4r3d> Hola alguien habla español?
19:18:59 <nirik> note: according to the working groups doc, we should be asking the board to approve these, but I think thats silly and we should do it and ask the board to yell if they have a problem. ;)
19:19:19 <pjones> w4r3d: nyet
19:19:20 <mmaslano> I want to ask hear if everyone is fine that WGs do no vote about their members
19:19:42 <mmaslano> only Env and Stacks agreed on election after year of service
19:19:43 <mattdm> nirik yes, that came basically from https://fedoraproject.org/wiki/Defining_projects, which says "Only the Fedora Project Board announces new Fedora projects."
19:19:53 <mitr> nirik: the Board is supposed to approve the PRDs, not the charters
19:20:42 <w4r3d> Hola tengo una duda
19:21:01 <dgilmore> w4r3d: No esta un reunión
19:21:22 <tflink> w4r3d: https://fedoraproject.org/wiki/Communicating_and_getting_help?rd=Communic... for irc channels with more spanish speakers
19:21:23 <nirik> mattdm: yeah, I think thats historical and shouldn't matter anymore, but the Board could disagree I guess.
19:21:35 <w4r3d> gracias
19:21:46 <mattdm> nirik yeah. I'm good with let's-approve-them-here-and-send-em-on-for-ack
19:22:09 <nirik> mmaslano: I'm ok with no voting. I'm a little worried that there might be not enough new blood/turnover, but perhaps we can address that when we see it...
19:22:40 <mmaslano> nirik: exactly my point
19:22:45 <mmaslano> how would we do it?
19:23:01 <t8m> mmaslano, I'd prefer if the WG's memebers were voted on but I can live with the governance charters as they are and see and correct if bad things happen latter
19:23:01 <jwb> you pay attention, and you step in as the overseeing body
19:23:11 <nirik> on the other hand voting is bad because we want people who know the area/are technical, and voting is popularity.
19:23:51 <abadger1999> I've been a little surprised at how the WG's have decided to optimize for consistency with the past but... not sure I would meddle.
19:23:53 * jreznik still thinks WG are evolution of SIGs with stamp and can't imagine SIG members would be voted
19:24:26 <mattdm> FESCo elections (and this goes back to the autonomy discussion) are the democratic check on all of this.
19:24:28 <abadger1999> jreznik: heh -- but in a SIG, there wouldn't be a voting member vs non-voting member distinction.
19:24:35 <t8m> nirik, you could say that about FESCo member voting as well
19:24:42 <nirik> t8m: yep. indeed.
19:25:05 <jreznik> abadger1999: actually we tried FKDESCo once in KDE SIG :) with voting members preselected
19:25:43 <nirik> so, +1 from me for the base charter. when/if we see issues with elections/no elections we can step in.
19:25:57 <t8m> +1 agree with nirik
19:25:58 <mmaslano> ok, so I'm +1 for Base WG charter
19:25:59 <notting> i'm +1 to the charter as well. but i can abstain, as i'm on it
19:26:05 <abadger1999> +1 as well
19:26:28 <mitr> jwb: "this doesn't sound quite right but I can't put my finger on it", "there have been more flamewars than usual", "people seem to be leaving"... it's not at all obvious when to step in
19:27:02 <pknirsch> isn't that what the liasions are for though?
19:27:10 <mattdm> +1 to charter
19:27:12 <notting> mitr: well, we did that due to those and other reasosn in the creation of the committees, so...?
19:27:17 <mattdm> and +1 to pknirsch
19:27:20 <notting> (maybe i missed the point of what you said)
19:27:35 <jwb> mitr, *shrug*. FESCo created the WGs. FESCo is the overseer. you get to figure it out
19:27:41 <nirik> any other votes?
19:27:49 <pjones> nirik: I'm +1 to it
19:27:59 <jwb> NOTE: Acting on behalf of the board, i closed board ticket 168 which was opened for Board approval of charters
19:28:07 <jwb> so please just approve the charters
19:28:12 <jwb> and then send the PRDs up
19:28:15 <mattdm> okay awesome.
19:28:17 * jwb points this out to sgallagh
19:28:18 <abadger1999> jwb: Thanks
19:28:34 <pjones> jwb: sgallagh left already, so you may want to point it out individually later
19:28:34 <nirik> #agreed Charter is approved (+7,0,0)
19:28:39 <nirik> thanks jwb
19:28:46 <jwb> pjones, he opened the ticket, so i'm guessing he'll see it
19:28:48 <nirik> there was one further ticket that came in...
19:28:54 <mattdm> so, just at the meeting prior to this one cloud wg approved charter
19:28:55 <mattdm> https://fedoraproject.org/wiki/Cloud/Governance
19:28:57 <nirik> #topic #1200 Environments and Stacks WG Governance Document
19:28:57 <nirik> .fesco 1200
19:28:57 <nirik> https://fedorahosted.org/fesco/ticket/1200
19:28:58 <zodbot> nirik: #1200 (Environments and Stacks WG Governance Document) – FESCo - https://fedorahosted.org/fesco/ticket/1200
19:29:08 <nirik> mattdm: sorry...
19:29:10 <mattdm> (oops, do that first)
19:29:16 <nirik> mattdm: yeah, lets do that one next
19:29:21 <mmaslano> abadger1999: well written
19:29:50 <t8m> +1 at least we'll see whether voting on members or not is better or not
19:29:51 <abadger1999> thanks. Of course, there was lots of other contributors to it ;-)
19:29:52 <nirik> +1 here (again, unsure how voting will work out, but hey)
19:29:54 <mattdm> +1
19:29:59 <mmaslano> +1
19:30:02 <abadger1999> +1
19:30:28 <notting> +1
19:30:56 <pjones> +1
19:31:25 <nirik> #agreed Charter is approved (+7,0,0)
19:31:31 <abadger1999> elections for voting members and the way we handle abstentions are the two main ways this differs from the other charters.
19:31:43 <nirik> #topic Cloud working group charter
19:31:47 <nirik> https://fedoraproject.org/wiki/Cloud/Governance
19:32:01 <mattdm> this is substantially the same as the server one
19:32:07 <pjones> +1
19:32:09 <nirik> sure, +1
19:32:11 <mattdm> +1
19:32:14 <notting> +1
19:32:16 <mmaslano> +1
19:32:29 <abadger1999> +1
19:32:31 <t8m> +1
19:32:56 <nirik> #agreed Charter is approved (+7,0,0)
19:33:35 <nirik> so, we are missing workstation?
19:34:23 <nirik> or wait.
19:35:46 * sgallagh returns
19:36:05 <nirik> yeah, we didn't approve workstation yet right?
19:36:34 <nirik> #topic Next weeks Chair
19:36:38 <nirik> who wants it?
19:36:40 <sgallagh> I haven't done it in a while
19:37:21 <nirik> it's so much fun!
19:37:30 <nirik> #action sgallagh to chair next week
19:37:38 <nirik> #topic Open Floor
19:37:56 <nirik> so the deadline for gov docs is the 15th? do we want to vote on workstation in ticket? or ?
19:38:24 <abadger1999> I don't think there's a hurry to approve -- it was just a deadline for submission.
19:38:32 * nirik notes its very similar to others. ;)
19:38:54 <nirik> ok, any items for open floor?
19:39:08 <sgallagh> Let's vote in tickets and add it to the meeting next week if there are any concerns
19:39:25 <sgallagh> I have one, but it might be more for FPC.
19:39:51 <sgallagh> Ive heard from the RDO folks that they're using the Koji buildsystem to build a EL 6 version of RDO
19:40:15 <sgallagh> This includes dependencies that are replacing copies in RHEL 6, but they aren't pushing these to the EPEL repo.
19:40:27 <sgallagh> They're instead just using Koji and creating a repo of their own.
19:40:29 <nirik> ok, just using private branches/scratch builds?
19:40:45 <sgallagh> It wasn't clear if this was a spirit-of-the-law violation to me.
19:41:34 <pjones> I'm not sure why we care?
19:41:41 <sgallagh> nirik: They originally were using the el6 branch, but I did notice that after our conversation, python-memcached moved to el6-havana
19:41:41 <nirik> well, we allow scratch builds for anything thats free enough to be in fedora, so this seems like it would be ok to me... but possibly copr would be a better place down the road?
19:41:51 <pjones> nirik: exactly
19:41:52 <sgallagh> Yeah, I recommended COPR as well
19:41:57 <abadger1999> I think if the builds aren't going into the fedora/epel repos, Im rpetty sure it's not FPC :-)
19:42:26 <pjones> But... it's builds for RHEL. I realize we're the overseers of EPEL as well, but it's still kind of not our jurisdiction.
19:42:26 <nirik> if they are doing branches they just need to realize that they can't currently ever delete them. ;)
19:42:50 <pjones> abadger1999: exactly
19:43:11 <nirik> now, if they are building stuff thats not ok license wise thats a problem.
19:43:57 <nirik> ok, any other open floor items?
19:44:10 <sgallagh> nirik: Ok, so to be clear, this is a "go ahead, have fun" answer? :)
19:44:29 <abadger1999> sgallagh: That's a good point about the branches too -- if they continued to use el6 it would pollute the branch for people who actually wanted to work on epel6 packages.
19:44:49 <pjones> sgallagh: yes
19:44:51 <abadger1999> i don't see a problem if they're using separate branches and a different repo.
19:44:53 <nirik> sgallagh: as far as I can see based on what I know...
19:45:05 <nirik> abadger1999: well, different repo wouldn't work.
19:45:12 <nirik> oh, rpms repo... sure.
19:45:16 * nirik was reading that as git repo.
19:45:17 <sgallagh> abadger1999: Well, these are el6 branches for packages that exist in base RHEL
19:45:21 <abadger1999> (although they may need something special for buildrequires)
19:45:39 <sgallagh> So theoretically, no one would ever be using those for an official EPEL build, per policy
19:45:53 <nirik> oh, I see. I misunderstood.
19:46:04 <abadger1999> sgallagh: ah.... I see... I think I'd be against reusing the el6 branches for that but it's more theoretical.
19:46:06 <nirik> that does seem like it would be confusing.
19:46:26 <nirik> typically when something lands in rhel the epel version is blocked.
19:46:41 <nirik> but scratch builds still work of course.
19:46:41 <abadger1999> yeah, confusion. git branch -a python-memcached... oh, why is this in epel, isn't it in rhel?
19:46:47 <abadger1999> things like that.
19:46:50 <sgallagh> abadger1999: As I mentioned above: the package that brought this up moved it to el6-havana after we discussed it
19:46:56 <abadger1999> <nod>
19:47:10 <abadger1999> sgallagh: yep. So tell them, please do more of that :-)
19:47:18 <notting> i'm ok with 'please do not use the official epel branch names if you're not intending to build for epel itself'
19:47:40 <nirik> yeah, +1
19:47:58 <t8m> notting, +1
19:48:05 <sgallagh> notting: +1
19:48:41 <mitr> notting: +1
19:49:42 <nirik> ok, do we want to agree to that? or just have sgallagh pass that along?
19:50:14 <abadger1999> notting: +1
19:50:18 <mmaslano> +1
19:50:56 <nirik> #agreed please do not use the official epel branch names if you're not intending to build for epel itself (+7,0,0)
19:51:01 <pjones> sure, I guess? It seems like they were talked to, realized they were wrong, and stopped
19:51:04 <nirik> anything else open floor wise?
19:51:49 * nirik will close out in a minute if not.
19:52:55 * notting has to head off to a different meeting @ 3 anyway
19:52:57 <nirik> Thanks for coming everyone!
19:52:59 <nirik> #endmeeting
10 years, 4 months
Meeting Summary / November 12, 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/?p=16 .
Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
Meeting Minutes
===============
Here’s a run-down of today’s Server Working Group meeting:
Agenda
======
* Can a single server have multiple roles?
* Installation of base + roles
Can a single server have multiple roles?
========================================
This topic discussion covered the following points:
* We agreed that a single server should be able to serve multiple roles.
* Testing combinations of roles on the same server will be tricky. There
are some known combinations that will not work (for example, FreeIPA
isn’t compatible with mod_nss.)
* We’ll start with basic, single server roles, and over time we will
adde tested combinations. (All agreed.)
“A server having multiple roles could be as simple as “In my
cost-constrained office, I want my domain controller to also be my email
server,” said sgallagh.
I pointed out there were some concerns about that approach last week.
sgallagh responded, “There was concern about being able to test such
things.”
“Yeah, testing can be a big pain if we have 10 featured things and you
can install any one or any combo of them,” said nirik. “But we could
also just say ‘we test each of these things alone, let us know if they
interact poorly.’”
mitr asked sgallagh, “We aren’t ordinarily concerned about testing a
system that has both Firefox and Devhelp installed; isn’t this the same
thing?”
“At first glance I agree with you,” replied sgallagh. “but with server
applications they can sometimes interact with each other in odd ways.
Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known
example out of the air.)”
“Server can have one or more roles,” added Viking-Ice. “There is no
doubt about that.”
“But we need to be clear what we test in that world,” said nirik.
“Yes,” agreed mitr.
sgallagh added, “As I said above, I think it must be possible, but we
can probably get away with stating that we only test each role in a vacuum.”
“We chose a role and we test cover that role,” said Viking-Ice.
“Alternatively, when/if we get automated tests,” said mitr, “doing a
‘full install’ and running all the tests on it should be reasonable –
but let’s not commit do doing manual work twice.”
Evolution asked, “Do we document roles that obviously conflict?”
“I would say not,” answered Viking-Ice.
“Well in some cases you can in some others you cannot,” simo answered.
“In freeipa we use mod_nss… so you won’t be able to use it with another
program that depends on mod_ssl. That may change in time to avoid
issues, and fedora server contribution may actually help smooth those
issues in some cases.”
sgallagh also answered, “That would still require testing all of them
together to learn whether they conflict.”
“We can only guarantee what we test,” said simo. “So perhaps we should
start just with bare roles, and in time add explicitly tested combinations.”
mizmo brought simo’s proposal to the table and it was supported by everyone:
*** Regarding multiple roles on one server, we will start with just bare
roles, and in time add explicitly tested combinations. ***
Installation of base + roles
============================
mizmo brought up, “It looks like another concern from last week’s
minutes, about multiple roles per server, was how to install the server
that way.”
“You install the base server ( which I call FOSSP, )” replied
Viking-Ice, “then install one or more roles.”
“Yeh, that makes sense to me,” replied mizmo. “The anaconda UI actually
makes this pretty easy… you can set various roles to be compatible /
incompatible and let users select.”
sgallagh asked, “By way of comps groups?”
“Yep,” mizmo replied.
“That’s the way to go in my opinion too,” said nirik.
mizmo added, “If we have a better answer to comps groups or want to
expand on them or fix them, though – it should be possible, I think.”
“I think we can agree on this “FedoraOS Server Platform ( FOSSP ) is
made available with or without an predefined server role,ready to use ks
for traditional method of installation,directly into an isolated or OS
container or as an whole-disk images to be used in private/public cloud
as instance-store image or standalone server in the cloud itself.”
“Way too many decisions in one sentence,” said mitr.
nirik responded, “-1 on kickstarts.”
“I think kickstart is too implementation-specific, although it’s
obviously going to come into play,” added mizmo.
“Kickstarts should be supported but not required,” simo added.
sgallagh asked nirik, “Can you expand on that?”
“Kickstarts only work at install/create time. You can’t for example
install foo and then decide to add role bar later,” said nirik.
“Kickstarts contain too many site-specific items.”
mizmo responded, “If the role was a comps group, you could though,”
pointing out how a role could be added on later.
“Yes, which is why I think it’s a better solution,” said nirik.
“So you’re just opposing pre-generated kickstart files we make
available, rather than ‘don’t use kickstart to set up servers,’ I
assume?” sgallagh asked nirik.
“Yes,” nirik replied.
“Nirik,” said Viking-Ice, “We install either the base server or base
server + 1 ( and later as has been decide ) or more roles. We test this
as is as it comes from us.”
“I’d like to see it in anaconda/yum groups personally,” said Evolution.
“Kickstart recipes would be good, but as a community thing maybe outside
what we’re doing here.”
mizmo added, “I don’t think we have a good GUI way to install groups
post-install, though.”
“That ‘needs to change,’” said mitr. “Mind, it’s not a matter of adding
a comps group only; installing a server role should also allow easily
invoking a GUI to set up that role as a group.”
“That’s one thing actually I want to talk using Cockpit for, when that
project finds its feet a bit,” sgallagh pointed out.
“Which brings up for me how we still need to discuss personas :) ” said
mizmo.
Viking-Ice replied, “I think we can drop personas and target and just do
the prd’s for roles.”
mizmo questioned Viking-Ice, “Then how do you know how to make the
decisions if you dont know who the product is for?”
“Well, roles should be targeted at personas,” sgallagh said. “Where the
persona may simply be “Admin that needs to run a mail server. Or more
likely “Admin that needs to be able to manage a groupware suite.”
“Right,” said Viking-Ice. “Our audience are administrators, and we do
not care at which level or how experienced they are.”
“I think we should actually be aiming to target a more junior admin than
we traditionally have,” responded sgallagh.
“I think it would be good to be clear about our targets,” added nirik.
“What kind of personas do you have in mind?” asked simo. “Unix-savvy
admin vs clueless admin? Are there any other?”
mizmo replied, “Let’s pick that up after the install base + roles topic.”
sgallagh said, “For post-install, I was personally envisioning doing
something like canned ansible recipes (formulas?)”
“Again, tho, the problem is that they are very site specific,” responded
nirik.
“BTW you can add an role later ( After install via yum or dnf foo )”
said Viking-Ice.
nirik replied, “If they are comps groups, sure… but if they are, why not
use that in the installer to install whatever the person wants? Or they
can write their own kickstart.”
“Can we agree on goals instead of technology first?” asked mitr. mizmo,
sgallagh, and simo agreed to this.
Viking-Ice continued, “We provide vm’s and best out of the box
experience ( which can be read as few steps to get it going.)”
“I think we need to decide only if we want to make it easy to install a
‘role’ and when. Only at anaconda time or at any time?” said simo.
mitr proposed a couple of goals:
* “Goal 1: automated (“mass”) install within a larger Linux
infrastructure (e.g. PXE is an option, may have LDAP/IPA.)”
* “Goal 2: manual install without a supporting infrastructure (e.g. the
very first Linux server).”
After that we ended up hopping on an etherpad (via piratepad.net) and
working through some goals. We got a good set of initial goals and
deferred some goals for later discussion, then promoted the document to
the wiki, here:
https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation...
We ran out of time and decided not to continue past the original
allotted time this week. Further discussion about server role
installation goals will take place in this thread on the mailing list.
Meetbot Minutes:
===============
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeti...
10 years, 4 months
meeting Minutes 2013-11-12
by Toshio Kuratomi
Summary: This week's meeting pretty much wrapped up the governance document
drafting process.
============================================
#fedora-meeting: Env and Stacks (2013-11-12)
============================================
Meeting started by mmaslano at 13:01:33 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-12/fedora-meeting...
.
Meeting summary
---------------
* init process (mmaslano, 13:01:39)
* governance draft (mmaslano, 13:05:16)
* https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Governance
(mmaslano, 13:06:41)
* HELP: (bkabrda, 13:10:48)
* AGREED: leave proposal as is, but change the part about filling
empty seats. Election should happen on january 2015. Who can vote
will be worked out later. (+5,-0,0) (mmaslano, 13:37:11)
* Voting group to be cla+1 approved (+1:6, 0:0, -1:0) (abadger1999,
14:00:59)
* Proposal Elections for half the seats will be held afer every fedora
release (approximately 6 months) to match with fesco. Elected
members serve for 2 release cycles before needing to stand for
re-election Passed (+1:8, 0:0, -1:0) (abadger1999, 14:21:45)
* Candidates for the Env and Stack WG are anyone in cla+1 Passed
(+1:6, 0:0, -1:0) (abadger1999, 14:23:58)
* We'll follow fesco election process on other details not mentioned
here Passed (+1:6, 0:0, -1:0) (abadger1999, 14:27:07)
* Change few days for lazy consensus to 3 days. Passed (+1:6, 0:0,
-1:0) (abadger1999, 14:41:54)
* Request trac for ticketing and voting Passed (+1:6, 0:0, -1:0)
(abadger1999, 14:45:46)
* ACTION: mmaslano will take care of trac request (mmaslano,
14:46:19)
* ACTION: abadger1999 to update the election doc and post link to the
list and fesco ticket. (abadger1999, 14:59:15)
* Open Floor (abadger1999, 14:59:34)
Meeting ended at 15:01:29 UTC.
Action Items
------------
* mmaslano will take care of trac request
* abadger1999 to update the election doc and post link to the list and
fesco ticket.
Action Items, by person
-----------------------
* abadger1999
* abadger1999 to update the election doc and post link to the list and
fesco ticket.
* mmaslano
* mmaslano will take care of trac request
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* abadger1999 (118)
* juhp (113)
* mmaslano (76)
* tjanez (70)
* samkottler (41)
* bkabrda (29)
* j_dulaney (25)
* hhorak (18)
* zodbot (10)
* pkovar (9)
* jreznik (7)
* sgallagh (5)
* pknirsch (2)
* hhorak1 (1)
* jwb (1)
* drieden (1)
* handsome_pirate (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 4 months
[Base] Summary/Minutes from today's Base WG meeting (2013-11-08)
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
==============================================================
#fedora-meeting: Fedora Base Design Working Group (2013-11-08)
==============================================================
Meeting started by pknirsch at 15:00:59 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-08/fedora_base_de...
.
Meeting summary
- - ---------------
* Governance discussion & draft (pknirsch, 15:12:13)
* LINK: https://fedoraproject.org/wiki/Server/Governance_Charter
(jwb, 15:17:02)
* LINK: https://fedoraproject.org/wiki/Server/Governance_Charter looks
good :) (haraldh, 15:19:36)
* AGREED: (haraldh, 15:20:05)
* AGREED: Proposal: Take the server governance charter and replace the
names and present to FESCO for approval (pknirsch, 15:22:11)
* ACTION: haraldh Proposal: Take the server governance charter and
replace the names and present to FESCO for approval (pknirsch,
15:23:36)
* Regular meeting times (pknirsch, 15:28:03)
* Keep meeting time at 15:00 UTC for the time being (pknirsch,
15:33:00)
* Base mailing list discussion (pknirsch, 15:33:28)
* AGREED: (haraldh, 15:37:11)
* AGREED: Stay with fedora-devel mailinglist, use [Base] in subject to
indicate emails around Base Design discussions (pknirsch, 15:39:33)
* Role of Base Design group discussion (pknirsch, 15:42:57)
* LINK:
https://fedoraproject.org/wiki/Critical_path_package?rd=Critical_path_pac...
(dgilmore, 15:45:34)
* LINK:
https://admin.fedoraproject.org/pkgdb/lists/critpath?tg_format=plain&coll...
(dgilmore, 15:45:57)
* LINK: http://fpaste.org/52688/38392758/ (pknirsch, 16:19:54)
* Base definition: installer, compose tools, minimal install (for some
definition there), and functionality the majority products want to
use (pknirsch, 16:21:30)
* Open Floor (pknirsch, 16:25:50)
* jreznik working on a communication plan with other WGs (pknirsch,
16:33:25)
* ACTION: jreznik working on a communication plan with other WGs
(pknirsch, 16:34:04)
Meeting ended at 16:41:32 UTC.
Action Items
- - ------------
* haraldh Proposal: Take the server governance charter and replace the
names and present to FESCO for approval
* jreznik working on a communication plan with other WGs
Action Items, by person
- - -----------------------
* haraldh
* haraldh Proposal: Take the server governance charter and replace
the names and present to FESCO for approval
* jreznik
* jreznik working on a communication plan with other WGs
* **UNASSIGNED**
* (none)
People Present (lines said)
- - ---------------------------
* pknirsch (195)
* dgilmore (105)
* haraldh (69)
* jreznik (68)
* jwb (57)
* masta (15)
* zodbot (9)
* kmacleod (1)
* sgallagh (1)
* Southern_Gentlem (1)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSfRdSAAoJEH7ltONmPFDRu4oQAKCaUJKJ77tMVokEqtCfNNHj
BXN5xuB58a3m/9j4G6sSvVd7lYU9Zq+EqJ0ANfQYOiythks3DLUkR7uDzAXHAqvA
5IgmxSa3M/Yu27W1qzAXEcg3sdC7hlybUnRqy0oneX1JbRBiykU852AvaLeqUfsJ
e/Um55YvgywIVjBk4p9hJgVBZZRGo74qV4EOXvVYigbGCrMzXisrthJ4dhRb5br4
o4bN/6Ys5zjK3VUuyF6eNKMV7eOzdqPH7HTVWhoo+SC827n8FqMwrvlASEk7GaEd
dM3FHboFng5RUqAFocq8GJxGAgn07UeJVYPQlK5GSasbwnfwBJaEbZPeRVpKM6QM
yjdkMjlln5kr2HJaN9kHtCTMt5DJgymUjm11MmlP9LEzgxuFOjI480vjSGReHYWB
YZMv0Mf80PKpgZvxIR4fxwtpLD/lJSJT7cbDniX0lMtW2WPWVurZGI7qniSy98Wv
tfBfovtzbmPg3Gb8cYhw35VeDm/5jSF5+IhA1EfuSUyqADcBAWaeHsaAtHUZNszf
c3Wx7rA58h0oEA4HMUYzBQaCWh7e3UPB6kn61YuriuXwMx6aHv5b0fHe6/jF5u0l
EpYq74bpLrNEvXyiyY6U4Wli5/XaNzwOubxq9PbUYYvxl6gmfD/aVVW2nI3C3Fju
jQD7H6ANNs7RIC//XTHq
=/qx5
-----END PGP SIGNATURE-----
10 years, 4 months
Fedora Chinese Meeting Minutes (2013-11-08)
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-15). Please
come and join the discussion if you can!
[1]:
http://meetbot.fedoraproject.org/fedora-zh/2013-11-08/fedora-zh.2013-11-0...
==================
#fedora-zh Meeting
==================
Meeting started by alick at 13:01:51 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-zh/2013-11-08/fedora-zh.2013-11-0...
.
Meeting summary
---------------
* 点名 (alick, 13:02:03)
* zsun sent regrets for not being able to attend this meeting (alick,
13:07:53)
* FUDCON APAC 2014 申办筹备 (alick, 13:11:51)
* alick gbraad try to work out the plan document for venue provider by
next week (alick, 13:13:53)
* ACTION: alick gbraad try to work out the plan document for venue
provider by next week (alick, 13:14:02)
* HELP: everyone to update the bid wiki page:
https://fedoraproject.org/wiki/FUDCon:Bid_for_Beijing_2014 (alick,
13:14:54)
* IDEA: 申办维基页的场地同 GNOME 用户组的申办提案(外加地大),列出若
干候选。 (alick, 13:17:32)
* F20 Release Party (alick, 13:23:56)
* shlug找到场地,在静安区 (RobberPhex, 13:28:28)
* LINK: https://fedoraproject.org/wiki/F20_release_events (alick,
13:33:24)
* IDEA: 北京的 relparty 日期建议为 2013-12-21/22 Sat/Sun (alick,
13:43:48)
* IDEA: 北京的 relparty 地点个人建议这次放在学校 (alick, 13:44:56)
* ACTION: RobberPhex call for talks for F20 Release Party Shanghai
(alick, 13:49:01)
* ACTION: alick call for talks for F20 Release Party Beijing (alick,
13:49:23)
* 中文翻译 (alick, 13:51:13)
* LINK:
https://fedora.transifex.com/projects/p/fedora/language/zh_CN/?project=2060
(alick, 14:04:51)
Meeting ended at 14:05:24 UTC.
Action Items
------------
* alick gbraad try to work out the plan document for venue provider by
next week
* RobberPhex call for talks for F20 Release Party Shanghai
* alick call for talks for F20 Release Party Beijing
Action Items, by person
-----------------------
* alick
* alick gbraad try to work out the plan document for venue provider by
next week
* alick call for talks for F20 Release Party Beijing
* RobberPhex
* RobberPhex call for talks for F20 Release Party Shanghai
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* alick (52)
* RobberPhex (15)
* isyangxin (7)
* BadGirl (5)
* zodbot (4)
* biergaizi (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
10 years, 4 months