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@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