18:00:06 #startmeeting FESCO (2014-02-26) 18:00:06 Meeting started Wed Feb 26 18:00:06 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:07 #meetingname fesco 18:00:07 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:07 #topic init process/roll call 18:00:07 The meeting name has been set to 'fesco' 18:00:07 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:15 .hellomynameis sgallagh 18:00:17 sgallagh: sgallagh 'Stephen Gallagher' 18:00:31 * abadger1999 here 18:00:37 * notting is here 18:00:48 i am somewhat here 18:01:17 I am all here, as the cloud meeting ending nice and early 18:01:19 * jreznik is available for anything fesco wants from him ;) 18:01:30 jreznik Cake, please. 18:01:48 Hello all 18:02:57 * dgilmore is here 18:03:32 ok, I guess lets go ahead and get started... 18:03:33 yay, my other meeting ended. 18:03:50 pjones: cool. :) sadly this one is just begun... 18:03:54 #topic ticket #1178 Fedora 21 scheduling strategy 18:03:54 .fesco 1178 18:03:54 https://fedorahosted.org/fesco/ticket/1178 18:03:56 nirik: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:04:21 so, in this ticket it was suggested we set a 'not sooner than' for deadline for changes... thoughts? discussion? 18:04:34 there was a response from websites on-list with actual data about time they needed 18:05:03 yeah. 18:05:25 nirik: it was in changes ticket, so far I just announced it's opened and asked folks to submit them asap... if you set deadline, I'll send update 18:05:32 they also noted they were unsure what we wanted to do with spins.fedoraproject.org... which we should clarify if we can? 18:05:32 they're asking for 6 weeks before alpha 18:06:23 mattdm: websites likely has a lot of work to do 18:06:41 #info Websites team is asking for 6 weeks before alpha (instead of normal 2 weeks), with content, features, and dl links known before then 18:07:06 mattdm: with august in mind (not saying it's the target, just to put it into context), alpha would have to in the end of May 18:07:30 and before that 6 weeks you need answers for website guys first, so add a few more weeks 18:07:49 * dgilmore rerally thinks we should look at october, see if we can get done what we want to in that time 18:07:49 jreznik So mid april for all the features to be finalized?F 18:08:00 dgilmore +1 to the last two things you've said :) 18:08:45 I'm ready to declare a Halloween release and then work back from there 18:08:45 jreznik: six weeks before that alpha would mean we'd need answers for websites RSN 18:08:46 I don't think we should set the schedule today... 18:08:46 dgilmore: it's really becoming october but let's have that data collected first before playing with it for several times 18:08:56 nirik: no 18:08:56 I think having a deadline of sorts people will know I can get foo done in that time. we may not get everything we want but we should be able to make a great start 18:09:02 we could set a deadline for changes tho if we wanted... 18:09:33 nirik change submission? 18:10:01 right. 18:10:25 for change submission I'd like to have some flexibility in accepting changes even later, on the other hand it would be nice to have overview of what's going to happen as soon as possible 18:10:34 ask WGs to break PRDs/tech specs into changes 18:10:46 jreznik +1 18:11:00 maybe we require those changes _first_? 18:11:00 ask other teams to propose changes too - and you know, it depends on what WGs wants etc 18:11:15 mattdm: yeah, maybe 18:11:22 we are asking working groups to give us info by march 3rd currently. 18:11:57 nirik: it's tech spec - so beginning of April to break it into changes? 18:12:01 the cloud wg is basically making a list of changes we plan to file 18:12:16 jreznik +1 18:12:23 I don't know. we are kinda operating in new lands here. 18:12:36 and then let's ask for other system-wide changes to be filed by the same time 18:12:37 we are, but change process fits pretty well here 18:13:14 mattdm: yeah, that sounds like a workable plan 18:13:44 and then we can have a second deadline later for the stand-alone changes 18:14:00 and we can also accept system-wide changes on a case-by-case basis, with a naturally higher bar 18:14:03 mattdm: that seems workable 18:14:06 sure 18:14:23 (last statement meant to be "can accept later") 18:14:42 The only problem with having a later deadline for stand-alone is that sometimes those get promoted to "system-wide" 18:14:46 so, concrete proposal(s)? 18:15:14 sgallagh good point -- maybe some wording in the deadline annoucement along those lines 18:15:22 sgallagh: again - case by case 18:15:37 Right, but with a later deadline, they by definition have less time to sort it out 18:15:40 ("if you think this might _possibly_ have wider impact, getting this in sooner rather than later is best for all") 18:15:46 Or else we have to slip, etc. 18:15:53 and I'm ok with this way - actually something I really wanted 18:15:54 ("if you think your self-contained change might _possibly_ have wider impact, getting this in sooner rather than later is best for all") 18:16:08 yep 18:17:08 #proposal Changes from working group prds/tech specs, and other system-wide changes, due April 7th 18:17:17 (first monday in april) 18:17:38 wfm 18:17:43 mattdm: +1 18:17:51 so, we would then set the schedule after that? 18:18:01 nirik yes? 18:18:02 For meeting notes, could we make cleat that this is part of the changes process rather than the "changes to how fedora is produced"? 18:18:18 *clear 18:18:22 thats longer without a clear schedule, but sure I guess. 18:18:35 abadger1999 the changes process is how we make changes to how fedora is produced, right/ 18:18:37 ? 18:18:39 #info changes here are the changes process, not changes to how fedora is made 18:18:59 mattdm: +1 18:19:02 mattdm: Not that I've been thinking... I've been thinking that the Changes process is what is changing within fedora. 18:19:28 abadger1999 eg changes process applies to fedora-distribution, not to fedora-project 18:19:38 sure I guess that's reasonable. 18:19:45 mattdm: The changes to how fedora is produced continue to be due on Mar 3 and then we work out with releng/infra/etc which of those things are doable in our timeframe. 18:19:49 abadger1999: right, we could use the change process for how we produce fedora 18:20:06 but to me its changes in fedora 18:20:33 abadger1999 got it. although for the cloud wg at least, most of our stuff will be expressable in the form of this type of Changes 18:20:35 abadger1999: right, but those things we do do, we also make into 'changes' so we can track them and have people following them, etc. 18:20:52 nirik: That would be fine for me. 18:21:02 abadger1999: idea is to break these tech specs into changes, so it's trackable etc. 18:21:12 nirik was faster :) 18:21:23 I see that it is kind of an expansion of the scope of the changes process, but I think it's a reasonable one 18:21:25 I just don't want to see new changes to how fedora is produced for the first time on April 7th 18:21:45 given that we don't really have a framework for the other, and this is a relatively lightweight and already tested one 18:21:46 abadger1999: no, definitely not 18:21:57 abadger1999: +1 18:22:01 abadger1999: we will likely see those changes later than that 18:22:17 dgilmore I think abadger1999 means the _plan_ for them 18:22:19 not the implementation 18:22:25 mattdm: right. 18:22:31 mattdm: well I can't do the plan yet 18:22:38 mattdm: well, it's standard process how even our downstream produces theirs releases 18:22:39 right. I think we should feel free to reject anything like that that shows up at the last minute... 18:22:51 because I don't know, trying to get some tools opened up 18:23:00 which needs a legal review and sign off 18:23:15 there could always be exceptions... 18:23:15 which I don't know when or if that will happen 18:23:21 dgilmore okay, so, it might be more like "a plan for a plan". 18:23:38 and if we have the high-level tracking for that as a change, we can know what the blockers are 18:23:50 its very wishy washy right now what exact changes we will get 18:23:55 and for example ask spot to try to unblock certain things 18:24:29 #proposal Fedora Changes Process submission deadline is April 7th. Changes to how fedora is produced for fedora.next are still due on March 3rd. 18:24:30 mattdm: its nothing to do with spot 18:24:51 dgilmore yeah but he is in a position to help, I think. 18:24:55 dgilmore: if it misses this time it could be next, or it could be an exception... 18:24:57 err... I left out system-wide there. 18:25:03 * abadger1999 adds that 18:25:12 mattdm: he is not in this 18:25:22 okay 18:25:33 mattdm: current plans may fall through totally and we will have to work a new plan 18:26:06 #proposal Fedora Changes Process submission deadline for system-wide changes is April 7th. Deadline for true standalone changes will be sometime later than that. Changes to how fedora is produced for fedora.next are still due on March 3rd. 18:26:18 abadger1999 +1 18:26:24 abadger1999: +1 18:26:27 +1 18:26:28 sure, +1 18:26:36 (with the understanding that the actual announcement will cover some of the other things discussed blah blah blah) 18:27:01 abadger1999: +1 18:28:05 Were'nt we talking about breaking the tech specs into changes _after_ Mar 3? 18:28:18 Or am I just behind on the conversation? 18:28:21 mitr -- yes? april 7th 18:28:41 +1 18:28:57 mitr: yeah, that's to some extent fine. And very probably going to happen no matter what. 18:29:07 abadger1999: though we wont know changes for how fedora is produced for a long time yet 18:29:13 abadger1999: +1 18:29:23 abadger1999: Agreeing on a deadline that will be ignored "no matter what" is strange 18:29:36 dgilmore I think you are reading that phrase in a more low-level technical sense than is meant 18:29:38 Anyhow, this got +7? already 18:29:42 #agreed Fedora Changes Process submission deadline for system-wide changes is April 7th. Deadline for true standalone changes will be sometime later than that. Changes to how fedora is produced for fedora.next are still due on March 3rd. (+7,0,0) 18:30:09 anything more on this? or move on? 18:30:20 mitr: My feeling is we wnat to have an outline of "We want these new things" on Mar3rd. fesco and wg's work out details of what is needed to implement those new things between then and april 7th. Have some plans with contingency plans by april 7th. 18:30:21 mattdm: well there is a difference between how we produce things and what we produce 18:30:36 I guess abadger1999 meant changes in what we produce 18:30:48 abadger1999: An outline is not a set of Change pages. 18:31:05 mitr: did we ask for Change pages for our March 3rd deadline? 18:31:21 abadger1999 no. a list. 18:31:25 rihgt. 18:31:32 abadger1999: That's how I read that, within the context of the other sentences of the decision. 18:31:40 OK, I'm mistaken, let's move on... 18:31:43 mitr: I think you are being confused by the overloading of the word 'changes' 18:31:50 #topic ticket #1221 Product working group activity reports 18:31:50 .fesco 1221 18:31:50 https://fedorahosted.org/fesco/ticket/1221 18:31:52 nirik: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:32:01 anything anyone would like to note or discuss? 18:32:37 "Biggest topic around Workstation was the plan to use a different installation frontend. That needs to be discussed with the anaconda team, rcm and FESCO by the Workstation WG." 18:32:42 I had one query... jwb: what is meant by workstation using a 'different install frontend' ? 18:32:56 #info cloud WG is holding an online activity day on Friday to get the list of changes/requirements into shape for next week's deadline 18:33:21 #info server is going to have another meeting thursday to work on it's changes. 18:33:24 nirik, unless i can summon mclasen, i will probably have to get back to you on that if you want specifics 18:33:52 ok, fair enough. This is just changes to anaconda defaults/paths? or is it being proposed to write an entirely new installer? 18:34:00 basically i think the desire is to make an install somehow more scoped to the product installation 18:34:19 i've suggested that it be anaconda, with perhaps some work from the WG on a different frontend or plugin to do that 18:34:26 i would expect "frontend" here to mean the UI and possibly the defaults 18:34:27 jwb: beyond different groups and package sets? 18:34:35 but i haven't had time to follow up with everyone on this yet 18:34:41 dgilmore, yes, beyond that 18:34:43 now... 18:34:45 if they meant "replace anaconda as kickstart parser and backend" i think they'd have said that 18:34:58 new anaconda design is very amenable to plugins and other little modifications 18:35:11 fair enough... 'install frontend' makes me worry someone is talking about writing a new installer. 18:35:19 if FESCo wants to enforce anaconda usage across the products to avoid entirely new installers, please say so 18:35:31 i don't think that's the intention here, but you could clarify anyway 18:35:38 I'm pretty sure we have actually said that in the past. 18:35:55 pjones: likewise 18:35:57 jwb: pknisrch has explicitly brought this up as "needs to be discussed by FESCo", so we do 18:35:59 Actually, I'm pretty sure we left that to the Base Design group to assert. 18:36:00 could be. I'm happy saying that. ;) 18:36:05 sgallagh: no, before that. 18:36:07 I think writing a new installer would be so much crazy work that it would be redundant to forbid it 18:36:23 mattdm: +1 18:36:32 mattdm: and yet there have been mockups produced in the past... 18:36:58 mattdm: That's not always stopped people :) 18:37:00 in any case, I think customizing the way anaconda presents things/defaults is a great idea for workstation, and one nice thing having products helps us do. 18:37:28 Anyway, we should probably wait for either Base or Workstation to bring at least a core of a proposal (or a summary of an agreement :) ) 18:37:36 mitr: yeah. 18:38:10 Do we want a separate ticket to track this now, or leave this up to Base/Workstation as well for now? 18:38:34 I just wanted clarification. I can ask/follow on the workstation mailing list for that 18:38:39 I'm also a little bit reluctant to flat out forbid possible areas of innovation. I think it would be better to give requirements ("must support kickstart" or whatever)... and I think it's best for the base wg to do that. 18:38:43 nirik: Please do 18:38:53 sgallagh: We failed to leave that up to Base Design last week for lack of a specific caes... this would be a specific case, though :-) 18:39:20 * nirik is fine letting things move on for a while and get sorted out by the folks we appointed to work on the products. ;) 18:39:32 mattdm: if we say "must support kickstart" and that results in a second implementation of kickstart and now we've got compatibility overhead, I'm going to be mighty pissed off. 18:39:53 pjones true. 18:40:05 that was an off-the-cuff example. 18:40:22 shall we move on? or is there other stuff we wanted to discuss or ask about? 18:40:37 nirik: Mind taking an action item on talking to Workstation for clarification? 18:41:04 #action nirik to follow progress of different install frontend from workstation 18:41:06 ok? 18:41:39 anyone else want to drop some infos for the meeting minutes? 18:41:40 we rejected box grinder as a suitable tool for making fedora because it didnt take a kickstart as input 18:41:56 they added commands in comments in the kickstart 18:42:45 ew. 18:42:46 dgilmore: oh yeah, that was fun. 18:42:46 I think its well understood that we support kickstart at the core andf that it needs to remain compatable 18:43:25 yes. but that was totally a side-track we shouldn't go into now please 18:43:26 #topic ticket #1235 Gnome 3.12 update for F20 18:43:26 .fesco 1235 18:43:26 https://fedorahosted.org/fesco/ticket/1235 18:43:26 18:43:29 nirik: #1235 (Gnome 3.12 update for F20) – FESCo - https://fedorahosted.org/fesco/ticket/1235 18:43:51 I think this should be deferred, based on mailing list discussion 18:43:54 Show of hands: who has been running hughsie's COPR? 18:43:57 yeah, i think so 18:44:00 * sgallagh raises his hand 18:44:02 I'm ok in principal with this, but would want it to go thru a lot of testing. 18:44:08 sgallagh not me -- I'm running rawhide 18:44:10 and we don't know the full scope yeah... 18:44:28 sgallagh: would have to use gnome first 18:44:34 As I said in the ticket, I'm good as long as the extensions effort happens 18:44:44 dgilmore: I use a *heavily* modded GNOME 3 18:44:57 Astonishingly, all of my extensions continued to work from 3.10 18:45:04 That's worth something, at least. 18:45:35 i think making sure extentions continue to work is a must 18:45:43 sgallagh I've got two that don't out of twelve. 18:45:56 if we defer, when do we defer till? 18:46:01 when 3.12 is released? 18:46:04 before that? 18:46:09 KDE update to new major releases, I don't think we can stop gnome, but we need to make sure its well tested and all pushed together 18:46:16 nirik until the SIG wants to reopen it? 18:46:30 nirik: 1) til the desktop SIG actually ask us about this, 2) I'd kind of like to see answers to my comment#1 18:46:31 dgilmore: +1, I agree 18:46:43 most of them should work after bumping the number in json ... ones that connect to dbus and use e4x should get updated to use a string for the xml instead (takes about 30 sec to fix) 18:46:46 dgilmore: KDE have set this policy in advance 18:46:51 but mostly needs testing 18:47:06 proposal: defer this for now, revisit when sig asks us to do so. 18:47:10 mitr: right, which is why we need to make sure that its handled carefully. 18:47:16 nirik: wfm 18:47:18 +1 18:47:20 mitr: I'm not sure that makes much difference 18:47:21 nirik: +1 18:47:23 but I don't think we can stop it 18:47:40 nirik: +1 18:47:41 pjones: Not sure about "much" either 18:47:43 nirik +1 18:47:55 nirik: +1 18:48:28 dgilmore sure we can, but it's better when it doesn't come to that! 18:48:50 mattdm: truth 18:48:51 #agreed defer this for now, revisit when sig asks us to do so (+6,0,0) 18:48:53 dgilmore: No one is trying to bludgeon it in 18:48:53 nirik: +1 18:48:58 #undo 18:48:58 Removing item from minutes: AGREED by nirik at 18:48:51 : defer this for now, revisit when sig asks us to do so (+6,0,0) 18:49:00 In fact, I'm very pleased with how they've gone about this. 18:49:07 #agreed defer this for now, revisit when sig asks us to do so (+7,0,0) 18:49:09 +1 to the proposal, FWIW 18:49:16 #undo 18:49:16 Removing item from minutes: AGREED by nirik at 18:49:07 : defer this for now, revisit when sig asks us to do so (+7,0,0) 18:49:22 #agreed defer this for now, revisit when sig asks us to do so (+8,0,0) 18:49:31 such a handy thing, undo. ;) 18:49:41 I wish it applied to more of life... 18:49:51 #topic ticket #1237 Graceful handling of guideline violating content 18:49:51 .fesco 1237 18:49:51 https://fedorahosted.org/fesco/ticket/1237 18:49:52 nirik: #1237 (Graceful handling of guideline violating content) – FESCo - https://fedorahosted.org/fesco/ticket/1237 18:50:28 I think this is a lot of hypothetical. ;) 18:50:44 #proposal: no FESCo change. The FPC could update the guidelines if they want 18:50:47 I stand by my statement in the ticket. If we've decided it's unacceptable, providing a policy to go around that decision is ridiculous 18:50:58 sgallagh: indeed 18:51:07 Let them build from source if they want desperately their penis-icon (or whatever0 18:51:44 mattdm: +1 18:51:45 mattdm: +1 18:52:18 Counter-proposal: FESCo recommends that no policy change be made to simplify this. 18:52:41 I'm +1 to that too. 18:52:44 I'm -1 to mattdm on this. 18:52:45 mattdm: +1 18:52:47 +1 18:52:54 dgilmore: Which? 18:53:16 I'm 0 to sgallagh's :) 18:53:18 i'm +1 to sgallagh 18:53:38 yay counting! 18:53:49 sgallagh: FPC changing guidelines is always an option, +1 to recommending no changes be made 18:53:53 mattdm: +4/-1, sgallagh: +3 18:53:56 sgallagh: +1 18:54:07 sgallagh: FPC is the right body to handle this in any case; I think we do have some precedent for packaging guidelines to work well with non-Fedora use cases, so there's little reason to _forbid_ this, though why would anyone want to spend time on having such a policy is a mystery to me 18:54:21 so I think that gives sgallagh's +5? 18:54:56 mitr: Was that a +1 to my statement? 18:55:13 sgallagh: That was -1 18:55:30 nirik: it's hard to tell but I think it's +5 if sgallagh is +1 to his own proposal. 18:55:40 I'm +1 to my own, yes 18:56:03 mitr / mattdm: so you object to us telling FPC not to change this? or ? 18:56:04 sgallagh: But I think I'll go with "whatever means FESCo won't spend more time on this" 18:56:14 i'm +1 to mattdm as well 18:56:35 +1 mattdm too. 18:56:38 * nirik notes sgallagh's proposal is 'reccommends' not 'orders' 18:56:47 * sgallagh nods 18:56:50 nirik: I think this is in FPCs jurisdiction, and giving users such a choice is in principle not objectionable to me. I fully expect FPC to refuse. 18:56:51 so, perhaps we can come up with one proposal everyone can agree on? 18:57:09 #proposal: no FESCo change. The FPC could update the guidelines if they want, but FESCo recommends that no change be made 18:57:19 +1 18:57:20 +1 18:57:21 mattdm: +1 18:57:22 +1 18:57:32 nirik: I think we basically just agreed with "No FESCo change. The FPC could update the guidelines if they want. FESCo recommends that no policy change be made to simplify this." 18:57:46 mattdm: +1 18:57:55 +1 myself to make the counting easier :) 18:58:07 dgilmore / notting ? 18:58:14 +1 18:58:49 I'm still for this proposal, but there's some degree to which we maybe want to say that disagreements with FPC rulings need to be less of "mommy says no ask daddy". 18:58:59 +1 18:59:04 #agreed no FESCo change. The FPC could update the guidelines if they want, but FESCo recommends that no change be made (+8,0,0) 18:59:26 #topic ticket #1238 Should Bodhi reset karma to 0 when builds are changed? 18:59:26 .fesco 1238 18:59:26 https://fedorahosted.org/fesco/ticket/1238 18:59:28 nirik: #1238 (Should Bodhi reset karma to 0 when builds are changed?) – FESCo - https://fedorahosted.org/fesco/ticket/1238 18:59:36 +1 to reset here. 18:59:40 t8m was +1 in ticket 18:59:53 it makes sense to me. +1 18:59:55 +1 18:59:57 * mattdm had no idea this wasn't the way it already worked 18:59:58 +`1 19:00:00 mitr was also +1, but is here too. ;) 19:00:11 mattdm: yeah, likewise. 19:00:11 +1 to reset 19:00:14 Yes, +1 19:00:27 -1 (I have reasons) 19:00:40 sgallagh let's hear em! 19:00:43 bodhi needs a lot of work 19:00:49 there's always one person in a crowd. ;) 19:00:49 sgallagh: indeed please share 19:00:58 First of all, we already have a system that rarely gets sufficient karma to begin with. 19:01:13 dgilmore top priority after taskotron and hyperkitty :) 19:01:23 sgallagh: irrelevant, if the karma isn't for the thing on the update. 19:01:27 By resetting positive karma when an update is updated, we're telling people that the time they spent to vote on it was wasted 19:01:59 I can see people who voted negatively being inclined to retest and change to positive if their issue is fixed. 19:02:00 I mean that's unfortunate, but you're making "we can't get enough testing" an argument for ignoring that we haven't got enough testing. 19:02:22 No, I'm using "my testing is ignored, so why bother" as an argument 19:02:31 so, making testers happy is more important than actually producing tested things ? ;) 19:02:34 I think this change will actively reduce the willingness of testers 19:02:52 I don't get why it correlates to "my testing is ignored" 19:02:56 It provides a negative-feedback response to good behavior 19:03:04 testing was useful for previous thing, and now there is a new thing 19:03:09 new thing is different from old thing. 19:03:21 another chance to test! 19:03:26 mattdm: "Nothing I cared about changed, but now I have to update the karma again?" 19:03:28 more badges! 19:03:39 I agree we need to make testing more appealing and plausibly even make it /seem/ more rewarding, but misapplying old tests is a really bad way to do that. 19:03:41 sgallagh: we have no way to know that 19:03:42 sgallagh How do you know nothing you cared about changed? Maybe it is broken now. 19:03:46 There are a LOT of Bodhi updates out there with many packages in them 19:03:50 pjones +1 19:04:08 Do we reset testing to zero if one of the GNOME mega-updates changes one of the lesser-known applications? 19:04:12 i think it needs to be a requirement to reset to 0 if autokarma is used. doesn't need to be overall, but if that makes it simplest.... 19:04:20 sgallagh: we should 19:04:23 yes. 19:04:49 I'd rather see "negative karma is reset to zero" than "all karma is reset to zero" 19:05:05 sgallagh In Glorious Future Bodhi 2, there are more fine-grained reports you can make, and maybe those won't all need to be reset 19:05:07 °_O 19:05:12 +1 to reset 19:05:19 positive karma is the fiction here. 19:05:22 mattdm: right. 19:05:35 negative karma is the part that's not dangerous, even though it might no longer apply. 19:05:51 false positives enable releasing software that's broken. 19:06:11 and paper over things being untested with what looks like positive test feedback 19:06:12 sgallagh: id rather make it easy and rewarding for someone to say yes its still working 19:06:16 Ok, fair point. I was trying to find a compromise, but I think I'm just going to go back to disagreeing with resetting 19:06:22 dgilmore +1,000,000 19:06:30 dgilmore: Sure, but our current system discourages that 19:06:36 anyhow, I guess we agree to disagree and move on? or is there either sides that are wanting to change votes? 19:06:40 Right now, it's generally a *hassle* to set karma even once 19:06:43 * mattdm hands out more badges 19:06:57 If we start telling people "Now you have to do it multiple times for the same update", they're just going to stop bothering. 19:06:58 nirik: mattdm has given you the "agree to disagree and move on" badge. 19:07:02 badge: retested a edited update 19:07:09 lol 19:07:14 :) 19:07:35 i see retest badges 19:07:39 sgallagh: it's worth noting that several of the people in this conversation /thought that was the status quo/ 19:07:47 #agreed FESCo agrees that karma should be reset when packages are edited in an update (+8,-1,0) 19:07:52 Can we please solve the karma-reporting problem first? Maybe work with the desktop folks on a better UI? 19:08:03 sgallagh: there's a gui in review I think? 19:08:20 nirik: I'd love to hear more about that (offline) 19:08:28 https://bugzilla.redhat.com/show_bug.cgi?id=1020839 19:08:35 #topic Next weeks chair 19:08:40 who wants it? 19:08:43 i'll do it 19:09:00 #info notting to chair next week 19:09:02 thanks notting 19:09:06 #topic Open Floor 19:09:12 any items for open floor? 19:10:00 General question for the WGs: Are you in good shape for the deliverable next week? 19:10:21 Answering for Server WG, I think it's going to be tight, but I hope our planned meeting tomorrow gets us there. 19:10:24 #info retester badge idea! https://fedorahosted.org/fedora-badges/ticket/251 19:10:49 sgallagh Cloud WG will be good after our frantic activity day on friday :) 19:11:01 mattdm: now you can get that badge for suggesting a badge. (If you didn't already have it) 19:11:28 I think they only give that one out if your badge is accepted. 19:11:34 nirik _So_ already there. 19:11:35 right. 19:12:03 sgallagh: Thought on that -- it's okay to send a list that doesn't have all the deliverables scoped out... better to have a list and idea of how important it is to your plans for f21 and we can work on how long/who needs to be involved after that. 19:12:25 abadger1999: Fair points 19:12:28 communicate early and often, IMHO. 19:12:34 nirik: +1 19:12:46