Summary/Minutes from today's FESCO meeting (2011-10-03)

Adam Jackson ajax at
Mon Oct 3 17:46:01 UTC 2011

#fedora-meeting: FESCO (2011-10-03)

Meeting started by ajax at 17:00:30 UTC. The full logs are available at

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,

* #671 Packages packaging yum repo files?  (ajax, 17:16:18)
   * ACTION: mjg59 to close out #671 per last week's discussion  (ajax,

* 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,

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
   * (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
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 -
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 -
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 
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 
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 -
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 
17:18:18 <ajax> #topic Next week's chair
17:18:23 * nirik notes 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 
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 
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 -
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

More information about the devel mailing list