19:00:01 <nirik> #startmeeting FESCO (2010-03-23)
19:00:01 * pjones yawns, goes to the bathroom before the meeting
19:00:01 <nirik> #meetingname fesco
19:00:01 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:01 <nirik> #topic init process
19:00:02 <zodbot> Meeting started Tue Mar 23 19:00:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:07 <zodbot> The meeting name has been set to 'fesco'
19:00:09 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:27 <mjg59> Hi
19:00:33 * notting is here
19:00:34 <nirik> hello all
19:00:43 * nirik sees we are missing cwickert
19:00:51 * skvidal is here
19:02:00 <Kevin_Kofler> Present.
19:02:15 <ajax> 
19:02:23 * nirik will wait a minute or two more before starting...
19:04:01 <nirik> ok, I guess we can go ahead and get started...
19:04:10 <nirik> #topic #351 Create a policy for updates
19:04:25 <nirik> I wanted to do a bit of followup here... since we ran out of time last time on this.
19:04:55 * dgilmore is here
19:04:55 <nirik> Is there any folks who would be willing to coordinate on the implementation details?
19:05:11 <nirik> and perhaps come back here to the full group with any additional questions that arise from that?
19:05:11 <notting> the proposal has been added to the wiki at http://fedoraproject.org/wiki/Package_update_acceptance_criteria
19:06:13 <nirik> I would be happy to work on it some, but not sure I have time to follow all the implementation it needs.
19:06:43 <ajax> so it seems like, first, we need to have tests that implement the common criteria.
19:06:50 <nirik> we need autoqa working for section 1.
19:07:12 <nirik> we need a way to list/add/remove things from 'important packages' for section 2.
19:07:23 <nirik> we need proventester criteria to be established
19:07:25 <notting> i can help point people at what needs implemented, but not sure i have much time to *do* implementation
19:07:54 <nirik> much of this is being worked on by other groups...
19:07:56 <Kevin_Kofler> I still don't see what frigging problem those criteria are supposed to solve.
19:08:04 <ajax> Kevin_Kofler: thanks for that.
19:08:12 <Kevin_Kofler> Section 1 makes sense, but is not implementable at this time at all.
19:08:23 <ajax> anyone in QA or the peanut gallery know if we have tests for the common criteria?
19:08:27 <Kevin_Kofler> Section 2 and 3 are just a PITA.
19:08:29 <wwoods> Kevin_Kofler: your objection to the idea has been noted many times now, thank you
19:08:34 <wwoods> I'm working on the depcheck test now, upgrade path is (IIRC) part of rpmguard
19:08:35 <nirik> but I think it would be good to have some fesco folks provide input on what we want, and help make sure the people working on these bits can do what we are looking for.
19:08:37 <notting> Kevin_Kofler: yes, and your vote on those sections was recorded.
19:08:38 <wwoods> the conflicts test already exists
19:09:01 <wwoods> installation test is being worked on by psss/kparal in the new tps branch of autoqa
19:09:26 <notting> tps branch?
19:09:30 <wwoods> there's some technical details to work out - how/whether to allow the autoqa user to move packages between tags, etc
19:09:32 <ajax> "test package sanity", i assume...
19:09:39 <nirik> wwoods: cool. So realistically how far out are we looking before we could have autoqa running on updates?
19:09:41 <wwoods> notting: just a git branch in the autoqa repo named 'tps', but yeah
19:09:46 <nirik> this cycle? next?
19:10:33 <wwoods> nirik: having those four tests running? we should have that stuff working before F14 Alpha
19:10:43 <nirik> wwoods: aweseme.
19:10:47 <nirik> awesome even.
19:10:54 * cwickert has been in the wrong chan, sry
19:10:58 <wwoods> I'm hoping probably have it all working in a month or two but there's always more details than you expect
19:11:14 <wwoods> err. s/hoping probably/hoping we'll/
19:11:50 <Kevin_Kofler> Famous last words. ;-)
19:11:54 <nirik> yeah. I think the big other items we wanted we will need to touch base with lmacken on. Namely how can we list/add/remove important packages, and can we tell when something has spent a week in testing easily.
19:12:22 <wwoods> yeah. turns out it takes time to actually solve problems.
19:12:46 <nirik> I guess since no one else is hopping to do it I can talk with lmacken and abadger2001 and see what it looks like for pkgdb/bodhi on those items.
19:13:25 <nirik> #action nirik will talk with bodhi/pkgdb developers about implementation desires for this policy.
19:13:29 <ajax> the "important" package set should probably be a list we generate continuously
19:13:30 <notting> as a followup proposal, we could just redefine critical path to be the criteria from the proposal
19:14:14 <nirik> notting: that would be probibly be easiest, but it might be confusing people who expect it to be what it is now.
19:14:34 <wwoods> I'd prefer the Important Packages be defined similarly to current critpath, but as a superset
19:14:51 <wwoods> there are slightly different test requirements for the things listed outside critpath there
19:14:55 * nirik isn't sure how hard that is to implement. will ask.
19:15:08 <notting> wwoods: are there, in this proposal?
19:15:13 <notting> nirik: it's just generating another list
19:15:21 <notting> the issue is getting it pushed into bodhi at the right places
19:15:24 <wwoods> right - just another comps group, practically
19:15:27 <Kevin_Kofler> I think critpath should be redefined to match that list of packages.
19:15:30 <nirik> notting: well, yeah, but does bodhi have setup for that...
19:15:37 <nirik> displaying it, etc.
19:15:46 <Kevin_Kofler> It doesn't make sense to be anal about updates for KDE, but happily ship the release with a broken KDE!
19:15:51 <wwoods> notting: yes - the 'important' package list is: critpath + desktops + package update GUIs + desktop apps
19:16:02 <Kevin_Kofler> If it's critical for updates, it's also critical for releases.
19:16:06 <wwoods> GUI testing is kind of a different beast
19:16:29 <notting> wwoods: but some GUI stuff is already in critical path
19:16:36 <wwoods> critpath was defined in such a way as to avoid the need for most functional testing;
19:16:54 <wwoods> the fact that GDM comes up at all is sufficient to assume e.g. X+gdm are working
19:17:07 <pjones> Kevin_Kofler: I'm not sure that's true - it makes sense to require that updates in general are less broken than whatever came before them
19:17:08 <wwoods> doing similar smoketesting for e.g. firefox is much more involved
19:17:40 <wwoods> it's really not too much to ask to keep critpath as-is and have this proposal define a new set that's a superset, is it?
19:17:53 <ajax> cart, horse.
19:18:03 <Kevin_Kofler> If we want to keep critpath as is, we should also have this proposal use critpath as is.
19:18:22 <Kevin_Kofler> But the added packages are the things users really want to use.
19:18:23 * cwickert notes that the critical path must be fixes, there are still some Xfce packages in there that are not critical path
19:18:29 <wwoods> Kevin_Kofler: you have missed the point. there's other uses of critpath outside this proposal
19:18:32 <Kevin_Kofler> They don't care if X comes up, but no browser works.
19:18:40 <wwoods> I'd like to not have to change the other QA uses of critpath
19:18:45 <Kevin_Kofler> Shipping a release in that state is broken.
19:18:53 <notting> wwoods: aha, that's what i'm asking - what other QA uses of critpath are there?
19:19:04 <Kevin_Kofler> If you don't want to do functionality tests for releases, then why do them for updates?
19:19:10 <nirik> ok, we are at 15minutes. ;)
19:19:11 <wwoods> it features in RATS: https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan
19:19:17 <nirik> votes to keep going on this topic?
19:19:30 <wwoods> and ISTR there's other places we were using it for the installation test plans
19:19:40 <pjones> I'll happily vote to talk about anything else.
19:19:59 <mjg59> I'm not convincd that this conversation is progressing usefully
19:20:01 <ajax> i think we know things that need working on now, yes.
19:20:08 <mjg59> It would seem better to take this to email now
19:20:16 <wwoods> sure.
19:20:18 <nirik> I'd be happy to talk with bodhi/pkgdb devs and we can talk more on this next week?
19:20:25 <ajax> perfect.
19:20:27 <dgilmore> nirik: -1
19:20:39 <nirik> dgilmore: ?
19:20:43 <cwickert> dgilmore, -1 on what?
19:20:45 <dgilmore> to continuing
19:20:58 <nirik> ah, right.
19:20:59 <dgilmore> the conversation
19:21:08 <nirik> thanks for the info wwoods. We will get something worked out.
19:21:11 <Kevin_Kofler> +1 to continuing, the point about the definition of what's critical is still undecided.
19:21:16 * cwickert is happy with the current proposal, so no further discussion needed IMO
19:21:24 <cwickert> -1 to contine
19:21:40 <nirik> Kevin_Kofler: how about we gather more info and talk about it next week?
19:21:47 <ajax> i count -5 to continue (pjones, mjg59, dgilmore, cwickert, me)
19:21:51 <nirik> #topic #357 New Sponsor Request: Matthew Booth
19:21:55 <notting> we can proceed with the two groups separate.
19:21:55 <nirik> .fesco 357
19:21:58 <zodbot> nirik: #357 (New Sponsor Request: Matthew Booth) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/357
19:22:33 <Kevin_Kofler> Not a whole lot of feedback there.
19:22:42 <Kevin_Kofler> But what was there was all positive.
19:22:43 <nirik> feedback on the sponsors list was positive, but not much of it. ;)
19:22:54 <dgilmore> +1 from me
19:23:03 <dgilmore> dedicated java folks are hard to find
19:23:05 <cwickert> +1
19:23:06 <ajax> i generally trust overholt's judgement, +1
19:23:16 <pjones> ditto ajax, +1
19:23:18 <nirik> I am +1 on this... I would like to see more java folks, and from looking at his reviews he's done a reasonable job.
19:23:20 <notting> seems like a good java guy. +1
19:23:22 <Kevin_Kofler> +1 from me too, I'll also trust Overholt here, as he knows his fellow Java contributors best.
19:23:29 <mjg59> +1
19:23:45 <nirik> #agreed Matthew Booth approved as sponsor.
19:23:54 <nirik> #topic #356 'distribution' vs 'general' in bugzilla
19:23:59 <nirik> .fesco 356
19:24:00 <zodbot> nirik: #356 ('distribution' vs 'general' in bugzilla) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/356
19:24:07 <nirik> notting: you want to talk about this one?
19:24:16 <notting> sure
19:24:25 <ajax> i don't get why these are separate at all?
19:24:32 <notting> we used to only have distribution
19:24:38 <pjones> they sure seem the same to me
19:24:39 <notting> general got created a few releases ago, not sure why
19:24:40 <dgilmore> im ok with this
19:24:50 <dgilmore> i do wonder if we can make general first in the list
19:24:54 <dgilmore> so its easier to find
19:24:59 <dgilmore> but thats outside of this
19:25:02 <ajax> with javascript all things are possible
19:25:08 <pjones> the criteria in the proposal doesn't make things clearer to me, either
19:25:16 <nirik> does anyone police/triage these?
19:25:47 <Kevin_Kofler> I vote +1 to the proposed policy.
19:25:47 <pjones> dgilmore: but even if we can do that, how's that better than making it just "distribution" and putting it first in the list?
19:25:47 <nirik> why not just do a 'general' one?
19:26:01 <pjones> (or just "general", whichever)
19:26:17 <notting> distribution gets assigned to me, so i shuffle them off to other people whenever possible
19:26:18 <Kevin_Kofler> I think these are 2 different things.
19:26:35 <dgilmore> pjones: general  == i dont what its for, distribution would be something specific.  but i could go either way
19:26:38 <pjones> Kevin_Kofler: the language in the proposal doesn't seem to make them two different things
19:26:41 <Kevin_Kofler> "I don't know what's at fault" vs. "I know this is not about a specific package, but the distribution as a whole".
19:26:55 <gholms> Maybe "general" isn't the right word.
19:26:57 <Kevin_Kofler> pjones: To me it clearly does.
19:27:05 <ajax> "unknown" might be better than "general"
19:27:06 <Kevin_Kofler> gholms: Yeah, maybe "unknown" is better?
19:27:16 <pjones> dgilmore: and yet the first statements in each are "Bugs related to Fedora which do not apply to any specific components." and "Bugs that are not tied to a specific component."
19:27:19 <pjones> these say the same thing.
19:27:35 <pjones> so if we're doing this, a) unknown is better than general, and b) take that part out of "distribution"
19:27:40 <nirik> well, I think if we are just changing the descriptions, I'm fine with whatever notting wants to change them to.
19:27:44 <gholms> Either "(unknown)" or "(unsure)", perhaps?
19:28:07 * pjones hatches a plan to reassign anaconda bugs to "unknown" on a constant basis ;)
19:28:13 <notting> pjones: i can rewrite the 'distribution' one to 'Bugs related to Fedora as a whole'?
19:28:26 <pjones> notting: that makes more sense
19:28:58 <Kevin_Kofler> notting: +1
19:29:02 <pjones> notting: but that sounds awfully much like what "general" would mean, so I still also think "general" is a shitty name
19:29:16 <notting> i wonder if it's possible to figure out who created general, and why
19:30:01 <pjones> I'm not sure "unknown" really would serve a purpose; it's not like the people who file bugs incorrectly against anaconda, X, and kernel are going to stop doing that.  usually they don't know that they don't know.
19:30:26 <nirik> also 0xFFFF gets most of the unsure ones. ;)
19:30:35 <dgilmore> pjones: right.  i get random weird things filed against fedora-packager all the time
19:30:40 <Kevin_Kofler> nirik: Yeah.
19:30:53 <Kevin_Kofler> We should get "general" renamed to "00unknown".
19:30:59 <pjones> right.  so having something with a good triager be first in the list seems more important than anything else
19:31:07 * nirik gets konsole, vty, bash and gnome-terminal bugs against "Terminal" all the time. ;)
19:31:15 <notting> Kevin_Kofler: nah, just javascript-it to the top
19:31:27 <pjones> js it to the top, of course.  but "general" is still a terrible name.
19:31:37 <nirik> Unspecified?
19:31:53 <pjones> I dunno, I'm still of two minds on the whole thing
19:32:10 <pjones> having a specific place to put things you're not sure about seems like it just leads to having another thing people need to look at.
19:32:13 <Kevin_Kofler> Except a lot of "0xFFFF" bugs are due to the JS screwing up.
19:32:15 <cwickert> nirik, rename Terminal to xfce4-terminal like other distros?
19:32:25 <Kevin_Kofler> So it'd be better to put the stuff to the top without relying on JS.
19:32:30 <notting> Kevin_Kofler: no, we don't have any JS there now
19:32:34 <nirik> cwickert: but it's not. There was/is a xfce4-terminal, which Terminal is not. ;)
19:32:48 <Kevin_Kofler> We do, the combobox is only added by some AJAX.
19:32:53 <pjones> notting: we don't have any js in the sorting - we do have some in "does the list show up" - but I'm not sure how that can lead to 0xffff getting selected
19:33:01 <nirik> I would wonder if we couldn't get bugzappers to trage a unsorted component too.
19:33:07 <notting> i assume that's just people picking the first thing in the list
19:33:12 <cwickert> I think we need the "general" for tracker bugs
19:33:15 <pjones> Kevin_Kofler: that's true for reassigns, I don't think that's true for new bugs, is it?
19:33:23 <halfline> any time i go to a bug it shows 0xFFFF in the list for a few seconds
19:33:25 <pjones> cwickert: and why isn't "distribution" a good place for those?
19:33:25 <Kevin_Kofler> pjones: When the list is created, at least Konqueror first selects 0xFFFF, only once it's fully loaded, it selects the intended component.
19:33:25 <notting> cwickert: we've used distribution for tracking bugs in the past
19:33:28 <halfline> then it changes to the right component
19:33:35 <pjones> Kevin_Kofler: ah.
19:33:37 * skvidal is not going to be here for a bit
19:33:38 <skvidal> sorry
19:33:47 <Kevin_Kofler> Several times, things accidentally got reassigned to 0xFFFF.
19:33:59 <nirik> yeah, when the list is slow to load. ;(
19:34:01 <cwickert> pjones, IMO distro is the whole thing
19:34:12 <Kevin_Kofler> Also due to bugs in Konqueror, Arora or other browsers, but I think those have been resolved since.
19:34:15 <Kevin_Kofler> Still, it's fragile.
19:34:38 <cwickert> for example I hatve a LXDE tracker bug. distribution seems wrong to me as it doesn't deal with the whole distribution
19:34:39 <pjones> cwickert: perhaps I should ask: what /functional/ difference will that make?  we'll have tracker bugs that need to be essentially ignored in one list, not in the other.  so?
19:35:05 <cwickert> pjones, no functional difference
19:35:18 <pjones> so if there's no functional difference, why do it?
19:35:20 <Kevin_Kofler> We just arbitrarily assign our KDE tracker bugs to kde-settings.
19:35:44 <cwickert> pjones, ok, you are right, I'm convinced
19:36:08 <nirik> so, where are we?
19:36:18 <pjones> I'm really thinking we should just have "distribution".  And it should be JSed to the top.
19:36:40 <nirik> and perhaps get some bugzappers to triage it? unless notting really enjoys it. ;)
19:36:47 <pjones> not a bad idea
19:36:59 * gholms rings the 15 minute bell  ;)
19:37:00 <nirik> althought it might be hard to figure out where some things go.
19:37:02 <Kevin_Kofler> I think we should have 00unknown (or some other characters that sort to the top + "unknown") and distribution.
19:37:13 <nirik> gholms: your clock is off I think... 2 min left here.
19:37:22 <notting> does space sort first?
19:37:28 <pjones> sure, but if it's difficult to figure out where things go, either a) somebody with more experience needs to look at it, or b) distribution is probably good enough
19:37:42 <ajax> notting: yes, it does.
19:37:45 <cwickert> +1 for "distribution" and removing "general"
19:37:48 <ajax> it's asciibetical
19:37:50 <pjones> notting: should, if it's accepted input.
19:37:56 <gholms> nirik: Turns out I'm just bad at math; sorry.
19:38:01 <pjones> LC_COLLATE appears to be "C" here.
19:38:04 <nirik> gholms: no worries. ;)
19:38:09 <notting> of course, that doesn't mean that some other part of bz won't explode if we try that
19:38:12 <pjones> (oh god - that's not browser-determined, is it?)
19:38:34 <nirik> I'm fine with deleting general and moving distribution to the top
19:38:41 <pjones> we should find out if " distribution" works and combine the two to it if it does.
19:38:44 * notting is +1 to that
19:39:06 <dgilmore> im good with combing into distribution
19:39:06 <pjones> and then have triagers look at it.
19:39:06 * nirik notes we are now at 15min, but I guess we can finish voting?
19:39:34 <ajax> +1 to deleting general, and to renaming to %20distribution if possible.
19:39:45 <nirik> ok, any objections to that plan? notting: you willing to make it so?
19:39:56 * Kevin_Kofler votes -1 to nirik's proposal, these are really 2 different things and should have separate components.
19:40:04 <pjones> +1 to folding general into distribution, also +1 to either renaming to %20distribution or to js sorting, whichever is practical.
19:40:22 <notting> let me just double check
19:40:23 <dgilmore> +1
19:40:26 <notting> with QA
19:40:27 <dgilmore> just to be clear
19:41:24 <nirik> ok, I think thats enough votes to pass.
19:41:24 <cwickert> another +1 for the record
19:41:29 <mjg59> +1 for that
19:41:47 <ajax> +1
19:41:58 <nirik> #agreed will remove general and try and get distribution to sort to the top of the list.
19:42:07 <nirik> #topic #358 Proposal: abolish FESCo ratification requirement for FPC guidelines
19:42:12 <nirik> .fesco 358
19:42:17 <zodbot> nirik: #358 (Proposal: abolish FESCo ratification requirement for FPC guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/358
19:42:20 <nirik> Kevin_Kofler: care to talk about this one?
19:43:00 <Kevin_Kofler> So the proposal here is to eliminate a bureaucratic roundtrip for a pure formality.
19:43:18 <Kevin_Kofler> Instead, when FPC votes a guideline, it should be automatically considered ratified.
19:43:26 <pjones> FPC seems to hate this - I think it's a case where we should move the line that determines if they ask us or not
19:43:28 <Kevin_Kofler> If there are any concrete objections, they can always be escalated to us.
19:43:31 <Kevin_Kofler> FYI, rdieter told me in #fedora-kde that he likes this proposal.
19:43:40 <notting> are spot, tibbs, and other representatives of FPC here?
19:43:42 <dgilmore> -1 to this as FPC wants it and i think its helpful to get FPC changes some airtime and publicity
19:43:44 <Kevin_Kofler> And abadger1999 didn't look completely opposed either from the Trac ticket.
19:43:56 <Kevin_Kofler> So it's not true that FPC is against this proposal as a whole.
19:43:58 <notting> i rememer the last time this came up FPC wanted things to come to a FESCo vote
19:44:20 * spot looks up
19:44:45 <cwickert> I think there always should be a body to control the others. e.g. we are controlled by the board and we should control FPC
19:44:48 * nirik doesn't care much... I'm happy to look over the changes. They are usually fine...
19:44:51 <Kevin_Kofler> I think FPC is perfectly capable of handling guidelines on their own without this useless extra step.
19:45:00 <Kevin_Kofler> So a more efficient process would be better for everyone.
19:45:09 <mjg59> FPC have suggested that they don't want final say on everything
19:45:09 * spot is a fan of checks and balances
19:45:15 <cwickert> I think all the discissions about packaging changes are very trivial and usually don't take much time
19:45:21 <cwickert> so why not continue as is?
19:45:23 <Kevin_Kofler> For us, it would mean fewer boring routine items with extremely predictable outcome on our meeting table.
19:45:23 * rdieter doesn't feel strongly either way, whether FESCo would rather explictly ack things, or would rather nack things , whichever is deemed more efficient
19:45:31 <mjg59> I'm fine with suggesting that FPC should have the option of choosing what they want to pass up to us
19:45:41 <cwickert> rdieter, you are right, more efficient
19:45:56 <cwickert> mjg59, good idea
19:46:02 <Kevin_Kofler> It's certainly more efficient to let FPC do things on their own, isn't it? :-)
19:46:07 <ajax> if we weren't explicitly in the approval loop, i'd at least want notification that new guidelines were added.  which doesn't really save me any time.
19:46:08 <mjg59> spot: Do you think FPC are capable of self-policing reasonably in that respect?
19:46:29 <Kevin_Kofler> ajax: They'd be posted on fedora-devel-announce which you're supposed to read as a maintainer anyway. :-)
19:46:30 <pjones> I don't think the fact that something is usually boring is a great reason for us to stop doing it, honestly.
19:46:33 <spot> mjg59: well, in the past, FESCo has rejected items we have approved.
19:46:57 <mjg59> spot: Do you have the feeling that FPC would know which items would be potentially rejected by FESCo?
19:47:06 <spot> mjg59: sometimes, but not always.
19:47:24 <mjg59> spot: Ok, in that case I'd prefer that they continue to go through FESCo
19:47:25 <pjones> okay, so that indicates that we should probably stay in the loop
19:47:32 * spot is only predictable psychic on tuesdays. ;)
19:47:32 <Kevin_Kofler> If people object to a guideline, whether they're FESCo members or just random maintainers, they should just file their objection in the FESCo Trac.
19:47:34 <Kevin_Kofler> Then we can vote on it.
19:47:42 <mjg59> The length of time that we spend on FPC stuff is pretty insignificant compared to most of the rest
19:47:44 <pjones> Kevin_Kofler: it's only more efficient if we always agree with them, which we don't.
19:47:45 <nirik> I think the orig setup was not that fesco voteed on each, but that fesco had a chance to veto
19:47:47 <Kevin_Kofler> But by default, guidelines passed by the FPC should be considered valid.
19:47:55 <Kevin_Kofler> I don't see why FESCo needs to micromanage everything.
19:48:03 <Kevin_Kofler> We have better things to do with our time.
19:48:04 <mjg59> Kevin_Kofler: Because FPC are asking us to
19:48:14 <pjones> Kevin_Kofler: FPC are asking us to monitor what they do, basically.
19:48:22 <pjones> it isn't a big burden on us, so why not do it?
19:48:33 <ajax> i'm flattered that they think my opinion is trustworthy ;)
19:48:41 <Kevin_Kofler> And not having the roundtrip would make guidelines pass much faster and make it easier to handle documentation, because we currently just send things back to FPC for them to document them.
19:48:55 <Kevin_Kofler> If they handle the process from start to end, documenting becomes an obvious step.
19:49:03 <cwickert> right, most FPC things are easy and *if* they are contriversial, they will come up to us anyway
19:49:08 <spot> the main reason i'm not sure a "valid until FESCo NACKs" approach is sensible is in the situation where FESCo does NACK, we might end up forcing packagers to undo what we just told them was okay
19:49:22 <pjones> spot: or even required
19:49:28 <spot> pjones: yep.
19:49:30 <mjg59> Kevin_Kofler: FPC aren't asking for this, so I think the impact on their workload isn't worth worrying about
19:49:33 <Kevin_Kofler> IMHO NACKing is just something to do in exceptional cases.
19:49:44 <mjg59> Kevin_Kofler: We do only NACK in exceptional cases
19:49:53 <mjg59> The problem is identifying exceptional cases in advance
19:49:56 <pjones> Kevin_Kofler: but they're asking us to review each change.
19:49:59 <mjg59> spot's concerns seem reasonable
19:50:09 <pjones> (and for apparently good reasons.)
19:50:24 <Kevin_Kofler> I think there's way too much routine stuff in our meetings.
19:50:39 <Kevin_Kofler> We should discuss only the really important items, not routine items.
19:50:42 <ajax> i think i'm -1 on this.  i'd be fine with not doing the review, but if fesco's input is solicited, we should give it.
19:50:50 <Kevin_Kofler> A routine item is indicative of a broken process.
19:51:00 <notting> i'm -1 as well, as the FPC lead is requesting the review.
19:51:08 <mjg59> -1 for the same reason
19:51:10 <pjones> Kevin_Kofler: the trouble seems to be that they're not always routine, and predicting those cases is nontrivial.
19:51:12 <Kevin_Kofler> I'm obviously +1 to my own proposal.
19:51:13 <pjones> I'm -1 on this as well.
19:51:23 <nirik> is there some way we could improve workflow here? Would it help if I pinged spot/FPC after a fesco meeting with approvals?
19:51:24 <Kevin_Kofler> How about we ask FPC to vote on what their official position is?
19:51:29 <notting> if we want to change our review process (give a couple of minutes for people to raise objections, otherwise blanket approval?), that's a separate item
19:51:33 <Kevin_Kofler> Rather than just listening to spot alone?
19:51:49 <tibbs> As I indicated in the trac ticket, I would be happy with a loosening of the stuff we need to pass up to FPC, but I don't think I'd want to bypass FESCo review entirely.
19:51:50 <pjones> How about we try to collect votes on trac for these in general, so we don't need to discuss them at meetings?
19:52:16 <pjones> that is, we switch to putting individual FPC changes in as trac tickets so we can vote on them there individually.
19:52:18 <nirik> pjones: we have tried that in the past, with limited success, but we can try again.
19:52:29 <mjg59> For routine items, people should have read them before the meeting and the time consumed at the meeting should be minimal
19:52:37 <pjones> nirik: yeah, it has the downside that we've actually got to be responsible for it to work.
19:52:41 <Kevin_Kofler> I'd like to see a much more decentralized Fedora, with packaging in the hand of FPC, features in the hands of the SIGs implementing them etc.
19:53:07 <pjones> Kevin_Kofler: and that's fine, but spot has asked us to review their changes formally.
19:53:11 <Kevin_Kofler> And FESCo discussing only global project policy in our meetings, not routine "approve X" items.
19:53:34 <pjones> Kevin_Kofler: are you seeing what I'm saying to you?  is your irc client working correctly?
19:53:46 <Kevin_Kofler> I'm seeing it.
19:53:53 <nirik> so we are at -4 / +1 I think?
19:53:58 <Kevin_Kofler> But what spot is saying is not even an official FPC position.
19:53:59 <mjg59> Yup
19:54:07 <cwickert> -1
19:54:09 <spot> Kevin_Kofler: you are mistaken. I speak for FPC. :)
19:54:18 <Oxf13> spot /is/ the FPC
19:54:18 <cwickert> now we are at 5 i think
19:54:25 <pjones> spot is FPC's designated human.
19:54:29 <Kevin_Kofler> :-)
19:54:32 <pjones> Okay, we're at -5, the vote fails.
19:54:37 <pjones> the motion fails, rather.
19:54:40 <Kevin_Kofler> I'd rather FPC actually votes on their official position.
19:54:50 <notting> that ... would not be a fesco item.
19:54:51 <ajax> feel free to propose it to them for their next meeting.
19:54:55 <pjones> you want to both not micromanage FPC and micromanage them at the SAME TIME?
19:54:58 <spot> if FESCo would prefer that we separate the items into separate tickets so that they can be voted outside of the meeting, we'd be happy to do that
19:55:05 <Oxf13> Kevin_Kofler: you want decentralization, and then you want to dictate how they do things?
19:55:07 <nirik> #agreed this proposal is not approved.
19:55:11 <mjg59> spot: It's probably worth a go
19:55:25 <nirik> spot: I think thats worth a try.
19:55:27 <mjg59> We'll see if we can be useful enough to make it work
19:55:31 <nirik> I can try and badger people to vote.
19:55:48 <nirik> #topic Fedora Engineering Services Tickets/Updates
19:55:48 <spot> okay. not a problem. we'll start that with the next round of approvals.
19:56:19 <nirik> I don't have much here, but wanted to just bring up the list for people to look at.
19:56:22 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
19:56:32 <nirik> no new tickets closed. one new ticket added.
19:56:36 <nirik> some new folks signing up.
19:56:42 <nirik> mmcgrath: you around for a status update?
19:57:05 <mmcgrath> nirik: yeah
19:57:07 <mmcgrath> ticket 10 is done
19:57:14 <mmcgrath> the others are progressing
19:57:17 <mmcgrath> got some more deps fixed
19:57:23 <nirik> I'm thinking we need to break these tickets up more, as some of them are large or get little progress.
19:57:49 <mmcgrath> I've been doing that a bit, I broke out broken deps one into a f12 ticket
19:58:16 <nirik> cool. I was hoping we would have more completed each week, etc... but I know it's hard sometimes.
19:58:31 <mmcgrath> well, it's the amount of work that needs to get done
19:59:15 <nirik> yeah.
19:59:30 <nirik> ok, anyone have anything further here? do think of new tickets...
20:00:05 <nirik> #topic Open Floor
20:00:29 <nirik> anyone have anything for open floor?
20:00:38 * gholms raises hand
20:00:45 <nirik> gholms: go ahead.
20:00:50 * skvidal just wanted to say sorry for not being around - been working on other things and didn't have time to get back to this
20:01:21 <gholms> If I own a package that will be used to create Fedora's EC2 images, does that make it critpath-worthy?
20:01:43 <gholms> Since it's only of significance to one SIG, I figured I would ask.
20:01:48 <notting> ... possibly.
20:01:51 <ajax> EC2 images aren't considered primary release artifacts, i believe?
20:02:12 <nirik> side note: ajax: have you had a chance to look at https://fedorahosted.org/fesco/ticket/225 ?
20:02:22 <notting> don't think EC2 is primary as of now
20:02:41 <ajax> nirik: i have, and it's sticky.  i'm not sure i have an opinion yet.
20:02:42 <nirik> yeah, I would think it would depend... if we decide ec2 is a primary deliverable we should probibly add those packages.
20:02:49 <nirik> ajax: ok.
20:03:21 <gholms> EC2 didn't make the F13 feature list, so if anything were to change in that regard it would be at least F14 time frame.
20:03:37 <nirik> dgilmore: can we close https://fedorahosted.org/fesco/ticket/298 now?
20:03:42 <ajax> nirik: axel's changes are in good spirit and faith, but mediawiki is kind of vile.  (you're all shocked.)
20:04:03 <ajax> nirik: still unsure what the right move is, but i'm meditating on it.
20:04:03 <nirik> indeed.
20:04:15 <notting> gholms: i wouldn't worry about it for critpath right this second. if we decide to have EC2 as a primary deliverable, we can change that
20:04:19 <nirik> ok, cool. Just add 'meeting' keyword back when ready to move forward on it.
20:04:27 <ajax> nirik: will do.
20:04:28 <gholms> Whew
20:04:52 <Kevin_Kofler> Re gholms's item, I agree with what was said (it can be considered as critical if it becomes a primary deliverable, but not now).
20:06:16 <nirik> ok, I guess if nothing else we can close out the meeting. I could ping about more old tickets if people have the time I guess...
20:07:15 * nirik will close out the meeting in a minute if nothing else comes up.
20:08:05 <nirik> ok. Thanks for coming everyone!
20:08:16 <nirik> #endmeeting