=================================== #fedora-meeting: FESCO (2010-03-23) ===================================

Meeting started by nirik at 19:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-03-23/fesco.2010-03-23-...

Meeting summary --------------- * init process (nirik, 19:00:01)

* #351 Create a policy for updates (nirik, 19:04:10) * ACTION: nirik will talk with bodhi/pkgdb developers about implementation desires for this policy. (nirik, 19:13:25)

* #357 New Sponsor Request: Matthew Booth (nirik, 19:21:51) * AGREED: Matthew Booth approved as sponsor. (nirik, 19:23:45)

* #356 'distribution' vs 'general' in bugzilla (nirik, 19:23:54) * AGREED: will remove general and try and get distribution to sort to the top of the list. (nirik, 19:41:58)

* #358 Proposal: abolish FESCo ratification requirement for FPC guidelines (nirik, 19:42:07) * AGREED: this proposal is not approved. (nirik, 19:55:07)

* Fedora Engineering Services Tickets/Updates (nirik, 19:55:48) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 19:56:22)

* Open Floor (nirik, 20:00:05)

Meeting ended at 20:08:16 UTC.

Action Items ------------ * nirik will talk with bodhi/pkgdb developers about implementation desires for this policy. -- 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