=================================== #fedora-meeting: FESCO (2013-11-13) ===================================
Meeting started by nirik at 18:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-13/fesco.2013-11-13-18.00.log.html . 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' <sgall...@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=Communicate#International 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
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
