FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-03-2011, 05:46 PM
Adam Jackson
 
Default Summary/Minutes from today's FESCO meeting (2011-10-03)

===================================
#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
 
Old 10-05-2011, 09:20 PM
Adam Williamson
 
Default Summary/Minutes from today's FESCO meeting (2011-10-03)

On Mon, 2011-10-03 at 13:46 -0400, Adam Jackson wrote:

> * #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)

to save people the bother of reading the logs, the 'proposal above'
involved allowing critpath updates to be pushed with 0 karma after a two
week wait.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org