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