16:59:59 <mjg59> #startmeeting FESCO (2011-09-26)
16:59:59 <zodbot> Meeting started Mon Sep 26 16:59:59 2011 UTC.  The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:02 <mjg59> #meetingname fesco
17:00:02 <zodbot> The meeting name has been set to 'fesco'
17:00:04 <mjg59> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
17:00:04 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:00:08 <mjg59> #topic init process
17:00:11 <pjones> I'm not here at all.
17:00:14 <mjg59> notting gives his apologies
17:00:17 <nirik> morning folks.
17:00:23 <pjones> I'm there.  If I was here, you'd be able to see me.
17:00:28 <ajax> i am everywhere, i am legion.
17:00:43 <sgallagh> I am that which is.
17:00:43 <mmaslano> hi
17:00:58 * sgallagh wonders if that was too grandiose.
17:00:58 <mjg59> Ok well we've got quorum
17:00:58 <pjones> sgallagh: you're claiming deity status now?
17:01:12 <pjones> I mean, sure, why not.
17:01:14 <mjg59> Missing t8m and cwickert1?
17:01:27 <sgallagh> pjones: I figure if I'm going to have delusions, I might as well go for the truly satisfying ones.
17:01:43 <ajax> i endorse this strategy
17:02:14 <mjg59> I'll give them a minute or so
17:02:30 <mjg59> dledford_office: Around?
17:02:34 <pjones> sgallagh: I've always found delusions of omnipotence to be a bit of a letdown all said.
17:02:36 <dledford_office> mjg59: yep
17:03:28 <mjg59> Ok, let's get started
17:03:32 <mjg59> #topic #667 Request to fix CRITPATH update process
17:03:32 <mjg59> .fesco 667
17:03:34 <zodbot> mjg59: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
17:03:43 <mjg59> dledford_office: You had some proposals here
17:03:46 <sgallagh> pjones: Right now I'm deluding myself mostly with regards to immortality. I've yet to be proven wrong.
17:03:54 <dledford_office> mjg59: yes, I put them into the ticket
17:04:04 <pjones> sgallagh: we're not going to employ the scientific method here, right?
17:04:13 <sgallagh> dledford_office: I fail to see any advantage to your proposal.
17:04:19 <mjg59> And nirik was going to see what happened in the proventester meeting
17:04:28 * nirik only skimmed dledford_office's post, need to re-read for attention.
17:04:34 <sgallagh> You're advocating adding MORE bureaucracy to a policy that's already crushed under the weight of the existing bureaucracy.
17:05:20 <nirik> yes, we had a proventester meetup on wed last week. A few folks showed up and we talked about testing and such. I'm not sure how much practical difference it's made, but we agreed to meet again this week... and several folks tested f14 updates and got them passed...
17:06:02 <mjg59> nirik: Ok, so some progress
17:06:06 <mmaslano> nirik: sounds good
17:06:09 <dledford_office> sgallagh: I'm advocating splitting up the critpath list based upon destination, and the second proposal is about allowing alternate criteria for approval to be possible on a case by case basis.  For example, given a specific hardware enablement package, it would be possible to alter the approval process to be +1 AutoQA when the autoqa hardware test is in place.
17:06:26 <nirik> we got derailed some in talking about how to change the policy, which is not the place for that discussion. This meeting would be. ;)
17:07:07 <mjg59> Making critpath smaller is obviously an option
17:07:08 * nirik re-reads dledford_office's proposal
17:07:16 <mjg59> And would make certain things easier
17:08:04 <sgallagh> Right, but he's talking about setting up different CRITPATH categories and having separate policies for each of them.
17:08:39 <ajax> man, linebreaks would be nice.
17:08:50 <mjg59> sgallagh: On a day to day basis, that shouldn't result in any more bureaucracy
17:09:12 <dledford_office> Indeed, there is a setup cost, but no runtime cost to splitting up the critpath categories
17:09:59 <pjones> yeah, the cost is at least one-time.
17:10:07 <dledford_office> Additionally, there would be a setup cost to creating specific test approval descriptions on specific packages, but each package that you can automate reduces the run time cost of the critpath process.
17:10:34 <dledford_office> The idea behind that is to allow us to slowly define tests over time and incrementally change the system instead of having to do it all at once.
17:10:44 <mjg59> dledford_office: Well I'm certainly personally not going to object to this being investigated
17:11:13 <mjg59> dledford_office: But in terms of implementation it's probably going to involve some time working with the infrastructure
17:11:22 <pjones> tem
17:11:23 <pjones> team
17:12:15 <dledford_office> mjg59: I agree, I don't know the ins and outs of bodhi, so I couldn't speak to the effort required to implement my proposal.  However, I would assume there is at least *some* tie in between bodhi and comps.xml (even if manual at the moment) or else bodhi wouldn't know the list of critpath packages.
17:12:16 * nirik worries about additional complexity here too.
17:13:09 <pjones> dledford_office: I certainly wouldn't vote to approve this without input from lmacken.  That said, it may be worth looking in to.
17:13:10 <nirik> also, how many folks are likely to be in several groups... ie, will this grow our existing pool of testers? or just allow them to target more on testing...
17:13:40 <pjones> nirik: aren't both advantageous in general?  (though the latter does have some drawbacks)
17:14:38 <nirik> sure, except if we just spread out our existing testers we might make it more complicated for them... 'what test was I needing to do for X' oh wait, that was Y I was testing for hardware, etc.
17:15:07 <pjones> hm.
17:15:52 <dledford_office> nirik: something I thought of that I didn't put into the ticket (because I thought of it after hitting submit) was the ability to have a textual description of testing requirements for a given package attached to the package just like the critpath approval requirements, and that textual description could be copied into the ticket automatically by bodhi.
17:16:10 <nirik> dledford_office: there's a provision to have a link to test plans...
17:16:23 <dledford_office> nirik: If you wanted to really make it slick, you could tag each item in the description with a number, and testers could then +1 a specific test if they wanted.
17:16:56 <dledford_office> nirik: yes, but are general test plans and critpath specific test plans always going to be the same?
17:17:02 <abadger1999> dledford_office: So currently, notting wrote  script tht cn be run when the repo is composed that figures out the critpath list and enter the info into pkgdb
17:17:09 <pjones> dledford_office: that's not that great
17:17:15 * nirik looks for a link
17:17:18 <abadger1999> dledford_office: From there, bodhi pulls the list and uses it to mke decisions.
17:17:46 <pjones> dledford_office: much of the time an update release, while it could benefit from a standard test, mostly needs a specialized test to test the change.
17:17:52 <abadger1999> dledford_office: So it's probbly mash, that script, pkgdb, and bodhi tht will need code chnges for this.
17:18:55 <dledford_office> abadger1999: unless you modify bodhi to read comps.xml directly, in which case the others are simply "remove the existing stuff" and all the work happens in bodhi
17:19:00 <nirik> pjones: well, not for critpath... but yeah, ideally.
17:19:04 <abadger1999> dledford_office: that won't work
17:19:25 <sgallagh> I can't help but ask myself why this is even an issue. Shouldn't we just rely on the package maintainer to beg on the test or devel lists if their updates are going untended?
17:19:30 * gholms rings the 15 minute bell
17:19:30 <abadger1999> dledford_office: b/c it's not sinmply reading comps.xml; it's also generating dependent packages.
17:19:47 <abadger1999> dledford_office: So it really needs to be triggered by new repositories being created.
17:20:11 <pjones> sgallagh: to some extent that's problematic because people have a tendency towards being shy in that way
17:20:21 <dledford_office> pjones: that's not how it works today...my updates sat in testing for 43 days, about 39 of which were *after* the specialized tests confirmed the specific changes.
17:20:48 <abadger1999> dledford_office: Although, alternate additional idea: also modify critpath to *not* do dependencies.
17:21:11 <nirik> proposal: consider proposal and talk with stakeholders, revisit next week?
17:21:20 <mmaslano> nirik: yes
17:21:22 <dledford_office> abadger1999: mostly agree, but you might need to do a manual list of dependencies, scan the list, and select some more packages that are actually important if you did that
17:21:42 <sgallagh> abadger1999: I agree, we should probably avoid dependencies and require that if anyone feels one belongs in CRITPATH, add it explicitly.
17:22:29 <dledford_office> sgallagh: I *did* beg on the list, and no one did a damn thing.  So my packages sat in testing for 43 days while people had known broken mdadm packages and we had known and verified fixes.  If that's going to be the process, then you can take mdadm, I'm done with it.
17:22:57 <nirik> dledford_office: remind me which release this was? 14?
17:23:03 <dledford_office> f15/f16
17:23:07 <mmaslano> dledford_office: I agree, beging doesn't help if your package is not popular or easy to test
17:23:28 <mjg59> Votes on nirik's proposal?
17:23:30 <dledford_office> than I propose a resolution: begging is not an answer
17:23:33 <sgallagh> dledford_office: I was asking a question, not trying to pick a fight. The answer to my question was, apparently: because the list doesn't always come through.
17:23:39 <pjones> mjg59: +1
17:24:03 <mjg59> .
17:24:07 <mjg59> ..
17:24:08 <mjg59> ...
17:24:12 <mjg59> ....
17:24:16 <mjg59> .....
17:24:17 <pjones> lots of consensus here.
17:24:19 <ajax> +1 to nirik's
17:24:25 <mjg59> ......
17:24:28 <sgallagh> mjg59: +1 to nirik as well
17:24:39 <mjg59> +1
17:24:54 <mjg59> So I think that's passed. nirik, you willing to bring this up with the appropriate people?
17:25:16 <pjones> taking nirik's +1 as given, yeah, that's 5.
17:25:18 <nirik> well, that would be abadger1999 / lmacken / notting I guess. sure...
17:25:20 * abadger1999 notes we really didn't discuss dledford_office's proposal #2
17:25:32 <mjg59> abadger1999: I think much the same conversation would have to happen
17:25:36 <mjg59> There's infrastructure changes that would be required
17:25:40 <mjg59> Let's determine the feasability
17:25:51 <pjones> yeah, we need infrastructure input on /both/ of them.
17:26:27 * nirik likes the idea of the second proposal off hand.
17:26:31 <mjg59> nirik: Can you cc: dledford into the discussion too?
17:26:50 <nirik> mjg59: I would propose the discussion happen in the ticket.
17:26:55 <mjg59> nirik: Works for me
17:27:25 <mjg59> Ok, lets move on
17:27:31 <mjg59> #topic #663 Late F16 Feature Java7
17:27:32 <mjg59> .fesco 663
17:27:36 <zodbot> mjg59: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663
17:27:48 * dledford_office bows out (thanks guys)
17:28:16 <mjg59> There's an open rel-eng ticket on fixing this up, but I didn't see if it got resolved
17:28:24 <nirik> I think we could close this now... the rel-eng ticket hasn't been acted on (and could just be by a provenpackager)
17:28:57 <mjg59> nirik: Do we need to make sure it blocks?
17:29:20 <dbhole> dgilmore was going to take a look into this
17:29:21 <nirik> dunno.
17:29:21 <dbhole> dgilmore: ^
17:29:37 * nirik expects it will get done at some point
17:29:48 <mjg59> nirik: Well, ideally that some point would be before we release :)
17:29:57 <nirik> indeed.
17:30:15 <nirik> dgilmore is traveling, and working on getting beta out. So I expect it will be after that.
17:30:34 <mjg59> Ok. Let's leave it open until next week just to make sure that we don't end up missing it somehow?
17:31:39 <nirik> sure .
17:31:47 <dbhole> Please note that I will not be here next week, just a heads up
17:31:50 * dbhole will be at JavaOne
17:31:54 <mjg59> dbhole: No problem
17:32:00 <pjones> dbhole: sounds exhausting.
17:32:06 <dbhole> :)
17:32:11 <mjg59> dbhole: Commiserations
17:32:16 <mjg59> Ok.
17:32:19 <mjg59> #topic #671 Packages packaging yum repo files?
17:32:20 <mjg59> .fesco 671
17:32:21 <zodbot> mjg59: #671 (Packages packaging yum repo files?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/671
17:33:00 <nirik> +1 to abadger1999's proposal
17:33:08 <mjg59> I'm going to say that any repo file provided in /etc/yum.repos.d by a package in Fedora should only refer to packages in Fedora
17:33:12 <sgallagh> Nobody should be packaging yum repo files except fedora-release.
17:33:32 * abadger1999 notes that the FPC discussed this, ran out of time and is continuing to work on it in their ticket.
17:33:32 <mjg59> Because even if it's disabled by default, there should be the same QA expectations
17:33:35 * abadger1999 finds ticket link
17:33:43 <ajax> sgallagh: uh, mock.
17:34:02 <mjg59> Yeah I don't think explicity enumeration is a great plan
17:34:05 <abadger1999> https://fedorahosted.org/fpc/ticket/106
17:34:05 <sgallagh> ajax: ok, fair enough.
17:34:46 <pjones> mjg59: is a package on fedorapeople "in Fedora"?
17:34:53 <mdomsch> I'd have sworn there was a policy against including additional repository configs in fedora-distributed packages
17:35:09 <mdomsch> else 'rpmfusion-repository' etc would have landed ages ago
17:35:09 <pjones> mdomsch: it's certainly been discussed many times
17:35:18 <ajax> toshio's proposed text in the ticket sounds fine.  there are some gray areas, but.
17:35:18 <mdomsch> liekwise dell-firmware
17:35:23 <abadger1999> It's continuing to be discussed because spot wants to work out more of the Legal concerns (for instance, we couldn't point at repositories that have non-free-patented content even in documentation)
17:35:27 <gholms> mdomsch: If there was then we'd better remove epel support from mock.
17:35:33 <mjg59> pjones: No
17:35:48 <pjones> mdomsch: well, both of those could reasonably be excluded because they point to repos of packages that aren't /suitable/ for inclusion.
17:36:01 <nirik> proposal: let FPC come up with a guideline here... ratify it/provide input to them?
17:36:01 <pjones> mdomsch: without even thinking about the broader issue
17:36:14 <mdomsch> pjones: noted
17:36:17 <abadger1999> mdomsch: Yeah, I linked to the past email discussions I found in the ticket -- looks like fesco/fpc members decided on a policy but we never wrote it down o nthe wiki.
17:36:36 <pjones> abadger1999: a+
17:36:38 <mjg59> Yeah I'm happy with FPC deciding exactly what the forbidden criteria are and if they thing it's needed have a "Ask FESCO for exceptions" clause
17:36:45 <mdomsch> gholms: that's a whole other discussion to be had, over many beers
17:37:09 <gholms> mdomsch: ;)
17:37:15 <mjg59> #proposal: Accept proposed wording
17:38:16 <sgallagh> +1 to abadger1999's proposal
17:38:25 <nirik> mjg59: might that short circut whatever FPC decides?
17:38:35 <pjones> eh, I'm vaguely -1 .  I'd rather hand this to FPC, whose job it really is.
17:38:37 <nirik> if they determine that forbidden stuff shouldn't even be in docs?
17:38:49 <mjg59> Ok
17:38:56 <mjg59> In that case, defer to FPC?
17:39:10 <pjones> +1 to deferring to FPC
17:39:26 <mmaslano> +1 thats job for FPC
17:39:36 <ajax> aye
17:39:40 <nirik> +1
17:40:31 <mjg59> +1
17:40:32 <mjg59> Ok
17:40:45 <mjg59> #agreed defer wording to FPC
17:40:57 <mjg59> Ok
17:41:01 <mjg59> #topic Next week's chair
17:41:24 <mjg59> Who wants to be next week's victim?
17:42:24 <ajax> i haven't in a while, sure
17:43:03 <mjg59> Ok
17:43:09 <mjg59> #agreed ajax will chair next week
17:43:12 <mjg59> #topic Open Floor
17:43:17 <mjg59> Anyone got anything to bring up?
17:43:34 <ajax> not i
17:43:46 * nirik has not
17:44:32 <gholms> [A tumbleweed drifts past]
17:44:43 <sgallagh> [a wolf howls in the distance]
17:45:08 <gholms> [Everyone falls silent and stares]
17:45:48 <mjg59> Ok
17:45:53 <mjg59> Sounds like we're done
17:45:55 <mjg59> #endmeeting