3:54 p.m.
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on
irc.freenode.net.
NOTE: The Meeting Time has CHANGED. See above.
= Followups =
#351 Create a policy for updates
= New Business =
#357 New Sponsor Request: Matthew Booth
#356 'distribution' vs 'general' in bugzilla
#358 Proposal: abolish FESCo ratification requirement for FPC guidelines
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic.
kevin
3:10 p.m.
New subject: Minutes/Summary for 2010-03-23 FESCo meeting
===================================
#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-...
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
3:24 p.m.
New subject: Minutes/Summary for 2010-03-23 FESCo meeting
On Tue, Mar 23, 2010 at 1:10 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
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
So, autoqa is going to be sending us TPS reports? Excellent. I trust
you saw the memo on this?
-Chris
--
Chris Weyl
Ex astris, scientia
3:27 p.m.
New subject: Minutes/Summary for 2010-03-23 FESCo meeting
On Tue, 23 Mar 2010 13:24:26 -0700
Chris Weyl <cweyl(a)alumni.drew.edu> wrote:
So, autoqa is going to be sending us TPS reports? Excellent. I
trust
you saw the memo on this?
Yes, and we are going to need you to come in on saturday... ;)
kevin
5:08 a.m.
New subject: Minutes/Summary for 2010-03-23 FESCo meeting
On Tue, 2010-03-23 at 14:27 -0600, Kevin Fenzi wrote:
On Tue, 23 Mar 2010 13:24:26 -0700
Chris Weyl <cweyl(a)alumni.drew.edu> wrote:
> So, autoqa is going to be sending us TPS reports? Excellent. I trust
> you saw the memo on this?
Yes, and we are going to need you to come in on saturday... ;)
If anyone's interested, I found some real TPS reports a while back. I
presume they were made by freeze framing the movie.
Jon.
5173
days inactive
5175
days old
4 comments
3 participants
participants (3)
-
Chris Weyl -
Jon Masters -
Kevin Fenzi