18:00:02 #startmeeting FESCO (2013-11-13) 18:00:02 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 #meetingname fesco 18:00:02 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:02 #topic init process 18:00:02 The meeting name has been set to 'fesco' 18:00:02 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:06 hello 18:00:16 * notting is here 18:00:17 hi 18:00:25 * abadger1999 is here 18:00:26 .hellomynameis sgallagh 18:00:27 sgallagh: sgallagh 'Stephen Gallagher' 18:01:08 morning everyone. 18:01:32 Hello 18:02:01 * sgallagh is juggling a number of fires today, so please forgive me if my responses are intermittent 18:02:25 yo 18:02:37 mattdm: you around? 18:03:02 ok, lets go ahead and dive in. 18:03:20 #topic #1195 WG autonomy 18:03:20 .fesco 1195 18:03:20 https://fedorahosted.org/fesco/ticket/1195 18:03:22 nirik: #1195 (WG autonomy) – FESCo - https://fedorahosted.org/fesco/ticket/1195 18:03:24 jwb: you around? 18:03:27 i am 18:03:38 nirik: mattdm will be around, he just mentioned disappearing to locate food first 18:03:53 fair enough. 18:04:21 * mattdm has food 18:04:41 is it soup? 18:04:43 are we waiting on me? 18:04:59 ok, so I agree with abadger1999 here... this is a difficult thing to write up 18:05:12 jwb: no, just wanted you around since you filed the ticket and can add to the discussion? ;) 18:05:20 ok 18:05:49 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 yeah, it's all kinda still squishy 18:06:38 the two areas noted tho have already come up... 3rd party repos and release cycles. 18:06:42 Proposal: FESCo always has the right to recover any powers it grants to the WGs at need. 18:06:51 pjones it is reheated pad thai 18:06:52 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 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 sgallagh: I was assuming that was already the case? 18:07:12 I agree with what Toshio said in the ticket 18:07:17 i.e. do we actually have to solve this problem for all cases? 18:07:39 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 abadger1999: it's not clear to me how draw the line (as you put it) 18:07:48 sgallagh, that proposal seems like something you'd do after you actually grant powers to the WGs 18:08:39 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 jwb: I disagree. After granting powers, deciding that you can take them back would be disingenuous 18:09:01 sgallagh: we already have that ability 18:09:04 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 and no, it woudln't. that's absurd. 18:09:16 sgallagh, my point was, your proposal isn't really solving the problem. 18:09:19 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 (ok, that might be to useless0 18:09:25 jwb: technically, if you say "isn't available in fedora and isn't proprietary", chrome does not fit. 18:09:38 jwb: Fair enough, I just don't want us locked into any decisions we make today 18:09:40 notting, it was the example i was given. is chromium a better example? 18:09:45 jwb: yes 18:09:48 well then assume that 18:09:50 We could definitely decide on the two specific cases that we know about so far. 18:09:57 or assume rpmfusion-free 18:10:04 abadger1999: true 18:10:09 jwb: *bonghits* 18:10:16 or assume $some_repo_you_guys_define_as_acceptable 18:10:28 so, what are those exact examples? 18:10:41 we really need to have fesco layout release schedules and lifecycles 18:10:48 nirik: i think without defining 'shared resources or philosophy', it leaves it rather vague 18:10:56 notting: yeah, it does. ;( 18:11:02 How about distributing RPMs for COPR repos? 18:11:08 dgilmore: that's really not what we're talking about right now at all. 18:11:11 That's a more clear example, I think 18:11:13 jwb: can you provide the specific repo cases you were seeing? 18:11:25 pjones: well, that was the other specific example I was thinking of. 18:11:56 abadger1999: What was? 18:11:57 "Can the products define their own separate release schedules and lifecycles" 18:11:57 oh, well, okay. 18:12:03 pjones: its something that cant be up to the Working Groups to decide. but sure 18:12:04 dgilmore: thats the next case after this repo one. ;) 18:12:05 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 nirik: cheers 18:12:29 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 nirik, so if there are limits around what "not fedora" means and we need explicit approval for each repo, fine 18:12:32 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 pjones: sorry. 18:12:47 nirik, can the products enable them by default i believe 18:13:13 or point users to them 18:13:16 I'd say: no. But they could offer them to the user to accept? 18:13:17 jwb this actually may be a question for _legal_ 18:13:36 mattdm, this specific one, sure. the broader question of what autonomy the WGs have isn't 18:14:07 * nirik nods. 18:14:08 and if we can't settle on a general method of operation, then we have problems 18:15:05 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 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 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 so, in this case should we forumate some questions for legal? or? 18:15:34 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 jwb Yeah but this one may not be a good test case for establishing the general 18:15:42 notting: right, which is "do not" 18:15:51 abadger1999: I really do as well, if only because it affects users' choice of which product they actually want 18:15:52 mattdm, so discuss the general without an example. 18:15:53 nirik: it's "only in %docdir", actually 18:15:54 jwb: what if we (fesco) just review list of approved decision and decide only about those, which are questionable? 18:16:03 notting: ok. 18:16:03 May I suggest that we're diving into a specific example that should probably have its own FESCo ticket? 18:16:05 jwb: i guess they bring a proposal to FESCo saying please change this policy 18:16:07 mmaslano, possible. 18:16:12 dgilmore, consider it brought. 18:16:18 That we can think on and discuss next week. 18:16:41 sgallagh, +1, let's try to at least somehow solve the general problem first 18:16:44 abadger1999: so, perhaps 'repos that only contain free software' ? or some other critera? 18:17:25 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 nirik, abadger1999: Can we please just address this separately from the general question? 18:17:43 dgilmore: yep. I recall that as well. 18:17:50 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 sgallagh: we can but... I don't think we can address the general question with a definite answer. 18:17:57 dgilmore, and yet, now we have coprs. designed to do that explicitly ;) 18:18:04 LOLOLOLOLOLOL ;) 18:18:15 abadger1999: Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. 18:18:48 sgallagh, again, i'm fine with that but you need to be aware that it's nebulous and possibly error prone 18:18:51 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 whats 18:19:01 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 jwb: More so than a blanket statement about autonomy? 18:19:05 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 sgallagh: +1 I don't see how can we specify boundaries 18:19:29 abadger1999: I think sensible boundaries may start to appear as we go forward, yes. 18:19:41 mattdm: "design" ? 18:19:41 But let's not derail this meeting thinking up such cases. 18:19:47 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 drago01 https://fedoraproject.org/wiki/Design 18:20:26 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 abadger1999, +1 18:20:57 over time we'll figure out areas where fesco does not have to be involved in future decisions of that sort. 18:21:14 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 pjones: I think you just rephrased my proposal there, so +1 18:21:44 pjones: +1, sure. 18:21:47 pjones: that works for me. 18:21:50 +1 18:21:52 (There, I've invented the FESCo Select Committee On Whether WGs Have Gone Too Damn Far ;) 18:21:52 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 jwb does that address your concerns well enough at this point? 18:22:13 pjones: i'm not sure that *solves* the issue, but it may be reasonable 18:22:25 notting: it wasn't intended as a solution, no. 18:22:34 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 mitr: hopefully our liasions will help? 18:22:40 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 Perhaps we should make that a clear part of the liason job-description? 18:23:17 sgallagh, definitely 18:23:20 well, it's always going to come down to judgement... 18:23:22 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 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 unless we say: "all working group decisions must be ratified by fesco" which is insane micromanaging doom. 18:23:45 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 and I use that phrase as opposed to "looking over the shoulder" or "backseat driving" on purpose. 18:24:14 (or, you know, pick your euphemism) 18:24:14 nirik, there's a middle ground 18:24:26 which means the FESCO liason role is pretty critical one 18:24:34 pjones: 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 alternately: "if a WG is intending to do something against current stated Fedora policies, please raise" 18:24:45 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 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 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 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 sgallagh: or that makes it the worst one for that ;) 18:27:23 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 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 abadger1999: packaging policies, forbidden items, etc. 18:28:08 update guidelines... there's a lot of things. 18:28:16 nirik: probably not enough votes, let's vote once again on sgallagh proposal 18:28:35 mmaslano, which one? 18:28:59 notting: But equally, reboot to install updates, one dep solver, backwards compat focus... 18:29:04 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 Proposal: The question is too general. Please bring specific cases to FESCo's attention as they come up. 18:29:30 sgallagh: yeah, this one +1 18:29:36 +1 18:29:48 +1 sgallagh (I assume that means keeping the ticket open and trying to address it as we move forward more) 18:29:55 sgallagh, +1 18:29:56 nirik: Yes 18:30:05 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 notting: counter? 18:30:34 notting, that's my concern 18:30:36 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 nirik: "Specific cases should include anything related to differences from existing Fedora policies or guidelines." 18:31:25 and also existing practice. 18:31:41 yeah, I think "existing practice" is actually the big (and quite vague) on there 18:31:45 which is the hardest part to nail down. 18:31:49 18:31:56 because obviously there will be a big change to existing practice by /having/ the WGs 18:32:04 At some point, no matter what, this will be a judgement call by the liasons. 18:32:13 why you work this out, it's clear you want me to open a ticket specifically for the repo question right? 18:32:20 Why don't we assume we can trust them to do their jobs properly until proven otherwise? 18:32:20 sgallagh: not by the liasons. By the WGs and by FESCo. 18:32:23 jwb: yes 18:32:26 jwb: yes please. 18:32:30 * jwb goes to open a ticket 18:32:31 yep. please do 18:32:46 could add "Autonomy over things already decreed as allowed by spins to change can be assumed." 18:33:07 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 notting: +1 18:33:52 notting: so, what does that give us for full proposal? 18:34:09 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 nirik: Spaghetti? 18:34:25 it's the opposite of what you said, though. 18:34:26 yummy. ;) 18:34:46 "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 notting: +1 18:34:59 "We expect that this will become more clear over time." 18:35:14 so, this implies closing ticket? 18:35:20 notting +1 18:35:30 notting: +1 18:35:39 notting: +1 18:35:45 * abadger1999 doesn't care if we close the ticket or have it as a standing item. 18:35:49 sure, +1 18:35:58 I think a standing item may still be better, but +1 18:36:06 It could be like open floor. 18:36:06 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 notting, +1 18:36:24 notting: +1 18:36:28 mattdm: I'd have thought you'd have learned that people read that the same way ;) 18:36:37 mattdm: well.... I think it all depends on the change and also as the time frame we talk about. 18:36:55 So at this point... I think it's still case-by-case. 18:36:56 pjones *sigh* 18:37:02 erm, then "We expect that this separation will become more clear over time, and policies and practices will change over time." 18:37:27 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 #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 notting: +1 18:37:43 you want me to amed? its already really long. ;) 18:38:08 * pjones thinks that's good enough. 18:38:14 move on? 18:38:27 please 18:38:38 jwb was filing ticket for the repo thing... do we want also another ticket for release cycle? 18:38:56 nirik: I think its something that needs to be made clear 18:39:02 nirik: yep. Should we ping pknirsch to do that? 18:39:06 nirik: so from my perspective please 18:39:18 * pknirsch is lurking! 18:39:21 whatup! 18:39:25 sure. I don't care who does it, but we should ask for input from all the working groups on it. 18:39:45 I know there's been talk of different release cycle in the server wg... 18:40:02 nirik: well if we dont have a consistent release cycle for all products we lead to insanity and confusion 18:40:15 dgilmore: +1 from me on that. 18:40:32 release cycle is clearly something that affects us all. 18:40:37 mhm 18:40:47 yep, which falls to FESCo to set 18:40:50 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 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 or I guess I could do it? 18:41:10 abadger1999, +1 18:41:20 abadger1999: good idea. Would someone be willing to send them all email about it? ;) 18:41:35 nirik: yep, I'll take that on. 18:41:40 and note the release cycle ticket too perhaps? 18:41:47 "consistent" and "uniform across products" aren't necessarily the same thing. 18:41:57 nirik: i can if you want to, or abadger1999 :) 18:42:34 ajax: Although I think we probably want uniform across products for at least a few releases while we get our footing. 18:42:34 at the end of the day though should we mandate a release cycle for all products? also future ones? 18:42:43 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 i mean, if some product decides to only do rolling releases? 18:42:56 pjones +1 broader plan! 18:43:01 Creating three (or four depending on what base design decides their scope is) is going to be hard enough. 18:43:03 what that then be shut down? 18:43:26 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 *three or four products 18:43:28 s/what/would/ 18:43:39 pknirsch: i.e. that's not an option right now without more discussion on it specifically 18:43:46 * pknirsch nods 18:44:04 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 nirik: right 18:44:32 they need to be on the same release cycle 18:44:33 as base would have to do lots of releases then 18:44:41 dgilmore: right 18:44:50 released on the same day, eol on the same day 18:45:09 well, one product could decided to eol one release later? 18:45:13 maybe? 18:45:19 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 but doing things like cloud update images monthly should be allowed 18:45:30 good point 18:45:33 pknirsch: no eol needs to be the same 18:45:41 even the update images (which I'm all for!) would be nice in broader context. 18:45:57 dgilmore: hm, thats going to be really tricky though. there will be no possibility for long time releases then 18:45:57 if the different products are on different timelines, qa processes like blocker bugs may also need to be changed 18:46:19 pknirsch: there is, just that all products get it 18:46:21 dgilmore: but i understand your point 18:46:33 * nirik can file that. ;) 18:46:34 Shall we move on ? 18:46:35 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 mitr: +1 18:46:56 mitr: yes, I'll file a ticket and we can collect input. 18:47:03 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 or you are saying 'wait to file the ticket even' ? 18:47:33 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 ok, then: 18:48:31 s/people/WGs/ 18:48:38 pjones, +1 18:48:50 pjones +1 18:48:52 I guess I can see starting to collect ideas now, or waiting. 18:49:54 proposal: file fesco ticket to collect ideas on lifecycle and release cadence 18:50:10 I think that timeframe and allocating new resources would be the big things 18:50:50 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 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 #topic #1196 Set deadline for PRDs 18:51:18 .fesco 1196 18:51:18 https://fedorahosted.org/fesco/ticket/1196 18:51:19 nirik: #1196 (Set deadline for PRDs) – FESCo - https://fedorahosted.org/fesco/ticket/1196 18:51:29 I'm fine with the poposed date in there. 18:52:04 * pjones too 18:52:06 um 18:52:13 +1 to the proposed date 18:52:15 that's two months from today 18:52:17 yeah, so it would have been nice to be CC'd on this ticket 18:52:31 <- not in fesco. don't get ticket email by default. 18:52:34 fesco meetings are on wed... maybe tuesday would be a more practical deadline :-) 18:52:53 jwb: possibly all liasions would have been good to cc. 18:52:54 abadger1999: I think the idea is to give us each a full day to read it 18:52:55 but yeah, +1 for that week. 18:53:02 * nirik wonders if we should make an alias. ;) 18:53:08 abadger1999: which I can certainly get behind. 18:53:11 nirik: probably, yes 18:53:15 or just cc all liasons on all fesco tickets? 18:53:23 (like the fpc point of contacts) 18:53:30 nirik, what about just adding all liaisons to the fesco alias 18:53:49 nirik, being there does not give them the power to vote on FESCo :) 18:54:01 t8m: it's a list... 18:54:16 s/alias/list 18:54:19 then 18:54:21 abadger1999: we could, we can add anyone to bcc to fesco tickets on trac 18:54:23 is there a separate fesco list and alias? 18:54:30 no alias. it's a lsit. 18:54:36 * abadger1999 sees that answer jsut before he asks it 18:54:55 jwb / pknirsch: would you like to get cc'ed on all fesco tickets? or is that too much noise? 18:55:03 nirik: please do! 18:55:05 I don't know -- previous fesco's set it up to be private to fesco. 18:55:06 i'm fine with it 18:55:25 so yeah, I'm more +1 to the CC plan. 18:55:38 I'd say that FESCo liaison should have most of FESCo member privileges except the voting :) 18:56:01 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 t8m: Isn't voting the *only* privilege? 18:56:07 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 ok, back to this ticket... shall we vote? or ? 18:56:22 nirik: yup, that's a date. +1 18:56:25 +1 18:56:34 +1 18:56:41 (i.e., it's arbitrary, but it's a defined arbitrary and therefore better than before) 18:56:43 sgallagh, well if you do not count receiving more mail as privilege ;) ;) 18:56:44 nirik: We're voting on the Monday I suggested? 18:56:58 the 13th? 18:56:59 +1 to CC 18:57:02 If so, +1 18:57:36 sgallagh: correct.. except for mmaslano who's apparently voting on dding liasons to the trac CC :-) 18:58:11 so, thats +7? 18:58:17 (so far) 18:58:32 +1 on the date 18:59:15 #agreed 2014-01-13 deadline for working groups to provide product requirement documents to fesco. (+8,0,0) 18:59:23 #topic #1198 Possible changes to Fedora EOL bug procedure 18:59:23 .fesco 1198 18:59:23 https://fedorahosted.org/fesco/ticket/1198 18:59:26 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 yeah, so I was shocked when I learned it worked this way. 19:00:22 mattdm: Want to phrase this as a soundbite we can vote on? 19:00:24 so, whats the proposed change? 19:01:22 the remaining question is what to do with that reopen issue 19:01:37 otherwise we already do it in the way mattdm proposed 19:01:40 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 I'm very - on leaving things open in needinfo personally.. 19:02:00 nirik: for how long? 19:02:06 nirik are you okay with a _longer_ needinfo? 19:02:07 jreznik: just one clarification -- anyone in the fedora packager group can reopen correct? 19:02:09 no. 19:02:16 only filer can? 19:02:18 say you have a f18 bug... 19:02:23 or no one, b/c we close the product? 19:02:25 notting filer _cannot_ 19:02:28 notting right. 19:02:40 actually, except I can. possibly all packagers can. 19:02:42 you provide a patch or detailed info on how to fix it. 19:02:46 but regular users can't. 19:02:46 fwiw, the kernel team uses a needinfo period of 2 weeks, then clsoe with insufficient_Data 19:02:54 but the maintainer does not get to it. f18 goes eol. 19:02:56 regardless of release standpoint 19:03:07 the needinfo is wrong there. There's no info needed. It will never get fixed in f18 19:03:15 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 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 nirik info is "is this still an issue?" 19:03:47 and you clear that and it's a open f18 bug. 19:03:47 cloning is kind of terrible in bugzilla 19:03:49 cloning a bug is horrible. please don't do that 19:03:51 nirik: but it could be fixed in next version 19:04:16 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 jwb: well, c) proposed by mattdm is now - file a new bug 19:04:18 nirik -- i'm okay with forcing an update of the version if we can do that. 19:04:45 jreznik but to be clear I only think that's okay if we give people a longer window. 19:04:52 t8m: hard to sort out... and confusing for maintainers that it's not right version 19:05:20 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 "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 you can't repoen while changing release? or we don't give you an interstitial that allows that? 19:05:49 mattdm: that's the problem - we can't fix all bugs... never, ever... 19:06:17 I have to run for today, sorry. 19:06:28 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 notting right now, the users have no option to do either. 19:06:38 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 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 nirik: so the question is if we can grant these privs and how sane it is to grant this privs 19:07:34 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 I don't know... bugzilla folks haven't answered the bug mattdm opened yet. ;) 19:07:50 mattdm: what's bug ombudsman? 19:08:00 chief triager. 19:08:03 nirik: so I'll try to check with them 19:08:19 bugzapper? :) 19:08:26 jwb: it's sad we don't have triagers anymore but I understand nobody wants to do it... 19:08:33 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