17:00:30 <ajax> #startmeeting FESCO (2011-10-03)
17:00:30 <zodbot> Meeting started Mon Oct  3 17:00:30 2011 UTC.  The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:30 <ajax> #meetingname fesco
17:00:30 <ajax> #chair ajax notting nirik cwickert mjg59 mmaslano t8m pjones sgallagh
17:00:30 <ajax> #topic init process
17:00:30 <zodbot> The meeting name has been set to 'fesco'
17:00:30 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:00:40 * nirik is around.
17:00:44 <pjones> hello.
17:01:13 * notting is here
17:01:14 * sgallagh is here more or less (busy day)
17:01:17 <mjg59> Here (obv)
17:01:22 <mmaslano> hi
17:01:46 <ajax> right, that's enough for quota, let's dive in.
17:01:51 <ajax> #topic #663 Late F16 Feature Java7
17:01:53 <ajax> .fesco 663
17:01:54 <zodbot> ajax: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663
17:02:22 <nirik> this is pending the rebuild of some packages.
17:02:27 <mjg59> Yeah
17:02:39 <mjg59> Given there's a rel-eng ticket I guess it'll be done
17:02:41 <nirik> Hopefully dgilmore can get to it later this week... he's been traveling/at fucon/getting beta done.
17:03:28 <ajax> do we need someone to keep an eye on this or shall we assume rel-eng is on the job?
17:03:56 <mmaslano> did rel-eng promised to do it?
17:03:58 <nirik> we can leave it on the agenda but defer?
17:04:34 <ajax> mmaslano: well, no, but nobody promises to do anything.
17:04:47 <ajax> i'll poke rel-eng on the ticket, we'll come back next week.
17:05:04 <ajax> #action ajax to follow up with rel-eng
17:05:18 <ajax> anything else on this?
17:05:33 <t8m> Hi, I'm sorry for being late
17:05:49 * nirik has nothing more on this topic
17:05:52 <ajax> t8m: np, didn't miss much yet
17:05:59 <ajax> next up
17:06:03 <ajax> #topic #667 Request to fix CRITPATH update process
17:06:03 <ajax> .fesco 667
17:06:05 <zodbot> ajax: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
17:06:22 <t8m> heh, now the fun begins :)
17:06:23 <nirik> so, should we revisit the timeout proposal? or is everyone set on their votes?
17:06:30 * sgallagh continues to be in favor of the "Allow it after two weeks if there is no negative karma"
17:06:44 * t8m too
17:06:49 * mmaslano too
17:06:55 * nirik is also +1 for that. I think toshio's reasoning made sense.
17:07:11 <mjg59> I don't think there's any new reasoning
17:07:22 <ajax> mjg59: i don't think there is either
17:07:43 <pjones> no reason to think anything has changed.
17:07:47 <ajax> i'm going to +1 that as well just so i can stop hearing about this
17:07:50 <mjg59> If this needs to be fixed then we need to fix it properly
17:08:15 <t8m> If I count right this means +5 now?
17:08:15 <nirik> mjg59: yes, but in the mean time we are frustrating maintainers and our users...
17:08:15 <ajax> i don't disagree
17:08:17 <mjg59> Rather than just satisfying the noisiest (and I don't mean that in a bad way) people without actually fixing the other cases that are being caught
17:08:44 <ajax> but i think adding the timeout here does get us to a less bad place
17:08:50 <ajax> even though it's still manifestly broken
17:08:57 <t8m> I do not think adding the timeout prevents us to fix the problems
17:08:57 <nirik> it's a band aid.
17:09:07 <mjg59> t8m: It doesn't prevent us. It just means that we won't bother.
17:09:10 <mjg59> But, eh.
17:09:11 <dledford> What's the "proper" fix?
17:09:12 <notting> i would like to track how many updates time out
17:09:14 <nirik> but sometimes you have to stem the blood flow so you can fix the injury. ;)
17:09:23 <nirik> notting: +1
17:09:37 <mjg59> dledford: Making sure that these packages actually get appropriately tested, whether by people or by automated infrastructure
17:09:46 <sgallagh> Actually, I'd like to amend the proposal for clarity: #proposal CRITPATH packages can go to stable if they either receive no negative karma after two weeks, or they receive the appropriate positive karma. If there is negative karma, it must be negated by proventester positive karma.
17:10:08 <ajax> +1
17:10:09 <gholms> That last sentence is hard to parse.
17:10:16 <notting> sgallagh: isn't the second sentence a no-op?
17:10:23 <ajax> s/negated/canceled/ i think?
17:10:24 <pjones> negative, negative.
17:10:27 <gholms> "counteracted", perhaps?
17:10:33 <dledford> mjg59: Well, automated infrastructure is on hold because of other work to do, and treating a volunteer project like it's a paid job and we can simply wave a magic wand and tell people to test and they will is unrealistic.
17:10:35 <sgallagh> Sure, poor choice of words
17:10:39 <notting> sgallagh: i.e., if they get negative karma, the first condition fails, so they're stuck on relying on getting the appropriate karma anyway
17:10:59 <t8m> notting, +1
17:11:10 <sgallagh> notting: A fair point\
17:11:16 <mjg59> dledford: I don't disagree
17:11:23 <sgallagh> I suppose I was trying to overclarify
17:11:51 <ajax> anyway, rough consensus?
17:11:53 <nirik> so, implementing this would need bodhi changes, correct? or...
17:11:56 <sgallagh> #proposal CRITPATH packages can go to stable if they either receive no negative karma after two weeks, or they receive the appropriate positive karma, which includes at least one proventester.
17:12:15 <t8m> sgallagh, +1
17:12:19 <nirik> do we want to ask people who want to do this to ping/file a ticket so we can more easily trac it.
17:12:21 <notting> nirik: yes. although it already has the concepts of karma & timeouts, so ideally it's just a rules tweak
17:12:51 <nirik> notting: yeah.
17:12:55 <gholms> nirik: That was pun-tastic. (Sorry)
17:12:55 <ajax> +1 (again) to sgallagh's proposal
17:12:57 <nirik> sgallagh: +1
17:13:22 <mmaslano> +1 to sgallagh
17:13:33 <nirik> dledford: this change would at least help you, correct?
17:13:40 <dledford> nirik: absolutely
17:13:46 <notting> not a huge fan, but we're not making progress on the proper fix yet. +1 to bandage the patient.
17:14:09 <ajax> #agreed critpath package rules to be modified per sgallagh's proposal above
17:14:37 <t8m> what about the self votes proposal?
17:14:41 <nirik> so, we need a bodhi ticket and then updating the updates_policy on the wiki once the bodhi change is live and announcing it then.
17:14:49 <sgallagh> t8m: I think that's a separate issue
17:15:13 <t8m> sgallagh, yes, but we can discuss it here - or is there separate open ticket for that?
17:15:13 * nirik guesses he could file the bodhi ticket and update things once it's done.
17:15:25 <ajax> nirik: if'n you don't mind, that'd be great.
17:15:32 <nirik> can do
17:15:45 <ajax> #action nirik to file bodhi ticket for critpath change
17:15:45 <sgallagh> t8m: I don't think there's a ticket currently, but let's save that for the Open Discussion
17:15:53 <ajax> indeed.
17:16:04 <t8m> sgallagh, OK
17:16:18 <ajax> last item
17:16:18 <ajax> #topic #671 Packages packaging yum repo files?
17:16:18 <ajax> .fesco 671
17:16:20 <zodbot> ajax: #671 (Packages packaging yum repo files?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/671
17:16:52 <nirik> I thought we decided to let FPC poke at this? or?
17:16:57 <mjg59> Sorry
17:17:01 <mjg59> I think I forgot to close it
17:17:08 <pjones> yeah
17:17:10 <mjg59> My fault
17:17:17 <ajax> tsk!
17:17:31 <ajax> #action mjg59 to close out #671 per last week's discussion
17:18:12 <ajax> well that was pleasantly quick
17:18:18 <mmaslano> mjg59: and you forgot send meeting minutes from last week
17:18:18 <ajax> #topic Next week's chair
17:18:23 * nirik notes https://fedorahosted.org/bodhi/ticket/642 is the bodhi ticket for the critpath change.
17:18:31 <ajax> nirik: thanks!
17:18:45 <t8m> ajax, I can do it
17:18:52 <ajax> t8m: excellent
17:19:00 <ajax> #action t8m to chair next week's meeting
17:19:05 <ajax> #topic Open Floor
17:19:23 <t8m> OK then for the self-vote in bodhi proposal
17:19:29 <sgallagh> I may not be around next week.
17:19:54 <nirik> I'd like to thank everyone who worked hard to get F16 beta out this week. Much hard work and testing. ;)
17:19:57 <sgallagh> t8m: I'm inclined to allow the "vote on someone else's behalf"
17:20:08 <sgallagh> Yes, excellent work!
17:20:11 <t8m> #proposal A self vote in bodhi is allowed if you vote on someone else's behalf.
17:20:25 <nirik> t8m: why couldn't they vote themselves?
17:20:26 <sgallagh> Amended: With a comment to that effect.
17:20:35 <ajax> seems... gameable, but sure.
17:20:48 <t8m> nirik, they do not have the bodhi account and they don't bother to create one?
17:20:51 <sgallagh> nirik: Not everyone wants to join FAS just to add karma for a single package
17:20:59 <t8m> I know that's a little bit lazy.
17:21:10 <ajax> bodhi has anonymous karma though
17:21:14 <t8m> sgallagh, +1 with the amendment
17:21:19 <nirik> so, does this happen much? is this going to help us any?
17:21:22 <t8m> ajax, which is not counted
17:21:26 <sgallagh> ajax: anonymous karma is useless from a karma perspective
17:21:39 <ajax> (then why have it, i wonder)
17:21:41 <nirik> also, note there is a ticket to make bodhi not allow the maintainer to +1 their own update. We would have to drop that.
17:21:55 <t8m> nirik, sometimes people just comment in the bz
17:21:55 <sgallagh> I've said before, in general self-karma doesn't have any negative effect, because the maintainer could always opt to just reduce the karma requirement
17:22:06 <dledford> What about doing an auto +1 to karma when a bug listed in the ticket goes from ON_QA to VERIFIED?
17:22:07 <drago01> the negative karma thing is broken though "it does not fix $unrelated bug"
17:22:09 <notting> ideally, all you'd need is a email + passwd
17:22:14 <notting> but that would require FAS changes
17:22:15 <drago01> -> update sits there forever
17:22:23 <drago01> the timeout is no real fix imo
17:23:03 <nirik> dledford: not a bad idea, we don't have any process in place to do that currently tho...
17:23:08 <drago01> we could allow the maintainer to mark karma as invalid .... but that can be abused
17:23:53 <dledford> nirik: We have at least minimal integration, a bodhi tickets puts the bug into ON_QA when the package hits testing, so this would just need to be either a cron job that checks bug state or a reverse trigger in bugzilla that updates bodhi.
17:23:57 <t8m> sgallagh, not in the case of the hard limit requirement as in case of critpath
17:24:18 <sgallagh> t8m: Valid point
17:24:31 <nirik> dledford: yeah, may not be too bad... not sure.
17:24:47 <t8m> so any votes for the proposal?
17:24:50 <nirik> of course when it goes to verified, the same person might go and +1 it... leading to 2.
17:24:56 <sgallagh> t8m: Perhaps "allow maintainers to +1 their own tickets, but proventester +1 must NOT be the submitter"?
17:25:22 <mjg59> Why would the maintainer have uploaded the package if they hadn't tested it?
17:25:30 <sgallagh> mjg59: Happens all the time
17:25:37 <ajax> mjg59: have you _seen_ the glibc updates?
17:25:47 <sgallagh> mjg59: Test on F15, submit the same update for F14 assuming it works too
17:25:59 <mjg59> I'm fine with allowing maintainers to +1 their own update providing the karma requirements also increase by 1
17:26:08 <t8m> mjg59, he could regression test it but perhaps the bug that was the cause of the update is not reproduceable for him?
17:26:18 <mjg59> But the values we set were based on the assumption that the update was, you know, actually tested.
17:26:25 <t8m> mjg59, yeah and the old release updates
17:27:14 <notting> mjg59: but in that case, what's the point?
17:27:38 <mjg59> notting: Our requirements then match reality rather than what we originally implemented?
17:27:47 <mjg59> The point of not allowing the maintainer to +1 is that the maintainer has presumably already tested
17:28:15 <ajax> which they certainly ought to have.
17:28:18 <mjg59> So letting them +1 would be them saying "I've tested this thing that I tested"
17:28:20 <dledford> nirik: for the +2 update scenario, you could have karma from the same person as the bug reporter (assuming an automatic karma from the bug going to VERIFIED) ignored for counting purposes.
17:28:29 <notting> mjg59: i just mean that your proposal is entirely equal to 'not allow maintainers to +1', which is much simpler
17:28:43 <notting> also, that we now appear to be discussing entirely disparate proposals at once
17:28:50 <mjg59> notting: Well, it distinguishes the case where the maintainer (a) doesn't test and (b) doesn't even pretend to have tested
17:29:40 <sgallagh> In general, I'm opposed to any proposal that adds more effort to the maintainer for little-to-no visible gain
17:29:48 <t8m> Well I would like the proposal if we hadn't the problem with already too strict requirements.
17:29:59 <pjones> t8m: that's not the problem.
17:30:03 <t8m> sgallagh, +1
17:30:10 <sgallagh> #proposal Leave things as they are and handle individual abuse cases if-and-when they come up
17:30:19 <t8m> pjones, yeah and what is?
17:30:25 <pjones> t8m: not enough testing!
17:30:43 <nirik> I think we are trying to increase our testing pool from our maintainers testing their own packages, which seems bad.
17:30:52 <t8m> pjones, no, not enough testers giving karma points in updates is the problem
17:30:55 <pjones> trying to solve it by changing the way we count the testing doesn't make more testing happen.
17:31:05 <t8m> pjones, we simply do not know if we have enough real testing or not
17:31:09 <pjones> it doesn't solve that problem either!
17:31:45 <t8m> pjones, it does if you allow giving the vote only on behalf of someone who doesn't have FAS account
17:31:48 <mmaslano> pjones: waiting for testers didn't help either
17:31:59 <mjg59> Well it comes down to this
17:32:00 <drago01> pjones: so we need to somehow encourage people to do more testing but ... how
17:32:05 <mjg59> Is it better to have no updates or untested updates
17:32:08 <pjones> mmaslano: no, but that's not exactly something we're proposing either.
17:32:14 <t8m> drago01, actually we do not know that
17:32:26 <drago01> mjg59: depends on the actual update
17:32:30 <t8m> drago01, we need to encourage them to give karma points after they tested
17:32:31 <mjg59> We've tried the untested updates approach
17:32:35 <mjg59> It didn't work out so well
17:32:36 <pjones> mjg59: and the answer is: in almost all cases, the former.  in critical security updates - eh, hard to say.
17:32:49 <drago01> or better what pjones said
17:32:59 <mjg59> Yeah. There's definitely a problem here.
17:33:22 <nirik> yeah, but adding more work on maintainers seems like the wrong place to be trying to fix this.
17:33:23 <dledford> mjg59: That's not quite accurate, a more correct summation would be: Is it better to have untested by proventester updates or no updates.  At least in my case, if all the people testing gave karma I would hit the number, but would still be blocked by the proventester requirement.
17:33:38 * sgallagh notes that there's an unvoted proposal out there.
17:33:46 <mjg59> dledford: Well right that's certainly one possible issue
17:33:55 <mjg59> Maybe the proventester distinction isn't actually useful
17:34:02 <mjg59> We don't have any mechanism for determining that at the moment
17:34:03 <nirik> sgallagh: several.
17:34:22 <mjg59> Can we mine bodhi and find out how many updates had postive karma but negative proventester karma?
17:34:27 <dledford> mjg59: And there comes a point where, statistically speaking, more testing by non-proventester testers is in fact better than a single proventester's testing.
17:34:35 <mjg59> Because if that number is small then maybe we are taking the wrong approach here
17:34:55 <mjg59> We were supposed to try to work out metrics on this. That seems like an obvious one.
17:35:03 <drago01> mjg59: is it really about negative proventester karma or *no* proventester karma?
17:35:09 <mjg59> drago01: Negative.
17:35:17 <notting> mjg59: we can, but not in this meeting
17:35:26 <mjg59> drago01: ie, how many times has a proventester found a package to be broken when other testers have said it's fine
17:35:35 <pjones> drago01: the question is "how good is !proventester karma"
17:35:35 <drago01> mjg59: ah ok
17:35:45 <nirik> so, where do we go here? vote on the several proposals? I fear we are going in circles.
17:36:19 <mjg59> I'm somewhat moved by the argument that proventester karma is an unnecessary blocker
17:36:25 <mjg59> But we should get numbers on that
17:36:25 <pjones> nirik: well, we have found a case where there's a clear policy change we can make after measuring something.  let's measure it, and vote on the proposed change depending on the result?
17:36:26 <drago01> mjg59: that depends on the package the situation though ... it might be broken in the proventester's configuration but not on the "non proven" tester's
17:36:37 <mjg59> drago01: Right but that's still valuable
17:36:39 <drago01> ./package/package and/
17:36:44 <pjones> drago01: that converges on the same thing
17:36:55 <nirik> sure, if folks want to gather more info thats great.
17:37:12 <mjg59> Who would be able to get that information?
17:37:18 <drago01> yeah without data this is going nowhere
17:37:33 <ajax> well, anyone with a copy of wget, but there's probably more practical methods.
17:37:43 <drago01> mjg59: assuming it is stored in a database ... no technical reason why we couldn't
17:37:45 <mjg59> ajax: Yeah exactly
17:37:52 <mjg59> Ok. How about I talk to Luke?
17:38:03 <ajax> sounds like a plan
17:38:09 <t8m> nice
17:38:24 <ajax> #action mjg59 to get data on proven/normal karma on updates
17:38:28 * nirik is fine with that.
17:38:37 <mjg59> lmacken: Oh hey perfect timing. Don't go anywhere.
17:38:53 <ajax> and that's >15 minutes on that topic so i'm fine with moving on...
17:38:59 * t8m too
17:39:06 <ajax> anything else from anybody else?
17:39:09 <sgallagh> +1 to move on
17:39:54 * nirik has nothing.
17:39:56 * ajax will close in a minute if there's nothing further
17:39:58 <sgallagh> ditto
17:40:13 <dledford> ticket #674
17:40:43 <sgallagh> .fesco 674
17:40:47 <zodbot> sgallagh: #674 (Need Jes Sorenson added to one of the packager groups) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/674
17:41:09 <nirik> dledford: yeah, I can take care of that after the meeting (unless notting beats me to it)
17:41:14 <notting> nirik: go for it
17:41:17 <pjones> yeah, this doesn't even need a vote.
17:41:18 <mjg59> No objections
17:41:21 <dledford> Thanks ;-)
17:41:29 <ajax> oh, so that's what he's working on now.
17:42:00 <dledford> Yeah, he's been brought in to help me with RAID stuff, and I'm having him help in both Fedora and RHEL.
17:42:27 * ajax repeats the "close in one minute" warning bell
17:42:32 <sgallagh> +1 to adding him to packagers
17:43:37 <ajax> #endmeeting