=================================== #fedora-meeting: FESCO (2011-10-03) ===================================
Meeting started by ajax at 17:00:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-03/fesco.2011-10-03-17.00.log.html . Meeting summary --------------- * init process (ajax, 17:00:30) * #663 Late F16 Feature Java7 (ajax, 17:01:51) * ACTION: ajax to follow up with rel-eng (ajax, 17:05:04) * #667 Request to fix CRITPATH update process (ajax, 17:06:03) * AGREED: critpath package rules to be modified per sgallagh's proposal above (ajax, 17:14:09) * ACTION: nirik to file bodhi ticket for critpath change (ajax, 17:15:45) * #671 Packages packaging yum repo files? (ajax, 17:16:18) * ACTION: mjg59 to close out #671 per last week's discussion (ajax, 17:17:31) * Next week's chair (ajax, 17:18:18) * ACTION: t8m to chair next week's meeting (ajax, 17:19:00) * Open Floor (ajax, 17:19:05) * ACTION: mjg59 to get data on proven/normal karma on updates (ajax, 17:38:24) Meeting ended at 17:43:37 UTC. Action Items ------------ * ajax to follow up with rel-eng * nirik to file bodhi ticket for critpath change * mjg59 to close out #671 per last week's discussion * t8m to chair next week's meeting * mjg59 to get data on proven/normal karma on updates Action Items, by person ----------------------- * ajax * ajax to follow up with rel-eng * mjg59 * mjg59 to close out #671 per last week's discussion * mjg59 to get data on proven/normal karma on updates * nirik * nirik to file bodhi ticket for critpath change * t8m * t8m to chair next week's meeting * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * ajax (54) * mjg59 (41) * nirik (36) * t8m (32) * sgallagh (27) * pjones (14) * drago01 (13) * notting (13) * dledford (11) * zodbot (8) * mmaslano (6) * gholms (3) * cwickert (0) --- 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 - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
