FESCo-2008-03-20

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* jeremy is here
warren meh
notting is here
jeremyf13 will be here after he grabs lunch real quick
* tibbs here
nirik is here
jwb is here
* f13
warren still fears emotes without an action.
nirikluckily dircproxy is long fixed. ;)
dwmw2fish
f13whoh, a dwmw2
bpeppleok, we can probably get started with something easy.
--- bpepple has changed the topic to: FESCo-Meeting -- Bugzapper's Proposals - https://www.redhat.com/archives/fedora-test-list/2008-March/msg00425.html -- poelcat
dwmw2f13: look no airport code!
bpeppleThe bugzappers had 2 poroposals.
* dgilmore is here
f13dwmw2: crazy!
warrendwmw2, did you just give up and move your residence into a plane?
dwmw2heh, no.
* nirik wonders if that means dwmw2 is now "everywhere". ;)
bpeppleThe first one was to clear out bugs for unsupported versions: http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
jeremynot that different from what's been done in the past afaict
notting+1. mattdm used to do this occasionally
--- bpepple has changed the topic to: FESCo-Meeting -- Bugzapper's Proposals - http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
bpepple+1
jeremy+1
warren+1
f13+1
just so long as we don't have those massivly annoying TV people show up
bpepplef13: ;)
tibbs+1; it's better than just closing all <=FC6 bugs.
nirik+1 from me...
* jwb gets 503
bpeppleok, I see seven '+1', so the proposal has been approved,
* nirik thinks having a known plan helps at least with expectations for reporters... better than ad-hoc doing things each time slightly differently
bpeppleThe second proposal was to apply a consistent process to open Fedora bugs.
--- bpepple has changed the topic to: FESCo-Meeting -- Bugzapper's Proposals - http://fedoraproject.org/wiki/BugZappers/HouseKeeping
jwb+1 to the first one
* jwb is slow
nirik+1 again for the same reasons... we can always adjust if people find problems/issues...
bpepple+1 here also.
notting+1
jwb+1
jeremy+1 in general.  although I have a minor tweak about when to create n+1 tracking bugs, but that's minor at best
warren+1
dgilmore+1
tibbs+1
bpepplealright, I see eight '+1', so this proposal has also been approved.
anything else, or should we move on?
tibbsAlthough I think this might need exceptions for the package review tickets.
bpeppletibbs: yeah, that makes sense. we can pass that along to poelcat.
tibbsWho knows what releases were picked for those.
poelcattibbs: would you see any type of time limit?
nirikyeah, although... pinging those once a release might be nice...
f13+1
nirikthe merge reviews should stick around tho.
poelcatIOW if it is open for X releases w/ no action... close it?
tibbsWell, review tickets shouldn't have any time limit, except by existing policy.
We tend to reap the ones that are waiting on response from the submitters pretty well, but some are just waiting for reviewers.
poelcatfair enough
tibbsAnd there's no reason those shouldn't stay around as long as the submitter still cares.
Although each of those old ones probably demonstrates a failure on Fedora's part.
poelcatwhat 'version' should they keep?
nirikrawhide?
tibbsI don't think it really matters.  rawhide is probably as good as anything else.
tibbsBut then you have to worry about the mass-mover script.
dgilmoretibbs: rawhide sounds best
it should trikle down from there
poelcatit makes it cleaner/easier to manage if there are literally zero bugs for unmaintained releases
well, zero 'open' bugs
bpeppleanything else? or should we move on?
ok, moving on........
--- bpepple has changed the topic to: FESCo-Meeting -- Packages entering Fedora w/o approved packaging guidelines (java, etc) - all
f13-1
tibbsOriginally the board allowed FPC to do this.
dwmw2for now, -1. We really ought to sort out the guidelines rather than blocking for ever
tibbsWe are sorting the guidelines.
f13cleaning up messes is a lot harder than keeping things out until we have something reasonable to measure it by
dwmw2but it's too late for f9 anyway; let's make sure it's sorted by f10
jwbtibbs, "the board" as in the Fedora Board?
dwmw2true
tibbsjwb: Yes.
Way back when.
This java thing is only the first time there's been significant complaint.
jwbwhy did this go to the board?
dgilmoref13: indeed
nirikI just want it to be clear if we are blocking on guidelines or not... and who decides. ;)
tibbsThe board originally constituted the FPC.
dgilmoretibbs: what did the board allow FPC to do?
tibbsThis was before the core-extras merge.
jwboh, that long ago
f13Proposal: If the package is too confusing for reviewers to actually review it without guidelines, it can't come in until we get guidelines.
tibbsdgilmore: block new packages on the acceptance of guidelines
nirikit's worth noting that openoffice extensions are also in the same boat as java... there is one pending package for them and the submitter was happy to wait.
bpepplef13: +1
f13and absolutely -1 on reviewing packages based on Draft guidelines.
dgilmoretibbs: we should block until we have acceptable guidelines
warrenHow likely are the guidelines to be approved and how soon?
nirik+1 to f13's proposal. Who enforces this tho?
nottingf13: +1
tibbsMy only point is that this issue has not been visited by FESCo since FPC moved from being constituted by the Fedora board to being constituted by FESCo.
* nirik guesses it's up to cvsadmins... which is fine with me...
f13warren: java guidelines could be approved at next FPC meeting
warren: lots of good work has gone into it
warrennice
tibbsYes, we have a huge raft of stuff for next Tuesday.
warrenSo this means cvsadmin should wait if we see more of the customary "java team approves its own package" review?
bpeppleok, is there anyone who disagrees with f13's proposal?
nirikwarren: yes, and block F_GUIDELINES
warrenOK
at least I wouldn't be the bad guy there.
tibbsYou can help with being the bad guy if you like.
spot-1, fwiw
bpepplespot: is that to f13's proposal.
nirikI guess I can go back and re-block the java package that started it... they re-approved it and re-requested cvs after I told them to wait.
bpepples/./?/
spotyes.
bpeppleok, since it looks like it's not unanimous, could I get a quick show of hands for f13's proposal?
+1
f13+1
* notting downgrades to 0
tibbs-1
jwbis this only for java, or any random language that doesn't have guidelines?
nirikspot: you have a counter proposal?
jeremy-1.  I don't want to block packages (and potentially new contributors) on the bureaucracy of building up packaging guidelines
dwmw2+1
nirik+1 for f13's proposal, but "too confusing" is subjective.
dwmw2blocked contributors can help with the guidelines :)
bpeppledwmw2: agreed, there would be an incentive to get them worked on.
spotBasically, my counter proposal is this: If the FPC determines that guidelines are needed for a type of packages, we hold all such packages from entering until a basic set of guidelines is approved.
jeremydwmw2: having to dive in and write _guidelines_ for how to package something when it's your first package is hardly an incentive
dwmw2jeremy: we return to the quality vs. quantity debate...
tibbsspot: +1
dgilmorespot: i think thats largely what f13 is saying
dwmw2dgilmore: I thought so too
* bpepple thinks the same thing.
nirikspot: +1 to that...
spotdgilmore: perhaps, but his wording is less clear than mine.
nirikyeah, except the part about FPC deciding... which makes sense to me.
dgilmorespot: i agree that if it needs guidelines it needs to wait until guidelines are approved
jeremyspot: so when does fpc make that decision?
spotwhen we notice review problems. :) we have several of the most prolific reviewers on the FPC
tibbsWe need to formalize how the decision is formalized.
spotand the ones who aren't are in regular contact with us
* jeremy just sees this becoming a convenient way to hole up reviews and discourage new contributors when we already have more than enough ways of doing that ;)
f13usually what happens is a package is encountered and there are missing guidelines to cover how the package shoudl look, so a question is posted to fedora-packaging-list or fedora-devel-list
tibbs"convenient"?
tibbsYou say that as if it is one of our goals to hold up reviews and discourage contributors.
Our mandate is only for packaging quality.
spotjeremy: the problem is that we get poor quality packages for these situations, with files missing or in wrong locations
nirikand little incentive to go back and fix them.
spotprecisely.
tibbsAnd this does cause problems for the whole distro.
dwmw2jeremy has a reasonable concern. I think that in general we should have a time limit on how long the lack of guidelines should hold up a submission
jeremytibbs: I think we're well on our way to the levels of overhead that we've explicitly stated from the beginning that we wanted to avoid :(
tibbsI disagree.
f13jeremy: we're also seeing a lot more of new and insteresting software to package
which weren't considered before as well
tibbsThe problem with the java stuff is that it's so complicated.
f13ditto ocaml
tibbsI can't tell whether it actually needs to be that complicated.
f13hell even mono for that matter, but at least we have /something/ there.
tibbsBut ocaml went in quickly and without too much fuss.
* spot nods
f13tibbs: except it's still not right
(multilib)
spotf13: yes, but its close enough for basic guidelines
f13sure
dwmw2I'm slightly concerned that we'll have to change the ocaml guidelines because they're not complete. But since we have to rebuild the ocaml world so frequently anyway, it's not so much of an issue there
nottingbbia couple of minutes, sorry
jeremyI'm just very concerned because the amount of effort that *I* have to go to now to look over and make sure I'm following every tiny little thing is enough to discourage even me.  and if it's discouraging to me, how bad is it for a new contributor?
spotagain, no one is saying we have to have it perfect, just good enough for general package quality and standardization
dwmw2for things other than ocaml it really is worth getting it right first
dgilmoredwmw2: I hope to have sugar activities  pretty much right first time
dwmw2cool
dgilmorebut they defintely need new guidelines
tibbsSo where are we at?
f13jeremy: there is a fix for that.  Put in real effort to make .spec files less so damn convoluted and free form
tibbsBesides 30 minutes through the meeting.
f13: Can't argue with that.
bpeppletibbs: agreed. we've got plenty of things still left on the agenda.
jeremyf13: are you intentionally trying to derail the conversation?  we have to work with what we have, not be architecture astronauts and pretend we're going to change the world overnight.
* jeremy paints the bike shed red
bpeppleare we at a point to vote on spot's proposal, or do we need to discuss this on the mailing lists?
spotjeremy: there may be ways to make the "checking against guidelines easier", some tooling like "rpmlint" for lang specific guidelines.
f13jeremy: no, I'm not intentially derailing the conversation.  I also don't want FPC to be the brunt of the blame on lengthy guidelines because of the fact that rpm specs are a peice of shit.  You're right, we have to work with the tools we have, and because such, we have lengthy guidelines about what kind of shit you can shove into spec files.
nottingas a counterexample, FPC recently decided they want to have guidelines on init scripts. doesn't mean all packages with init scripts should have been blocked until such guidelines were approved
jeremyf13: I'm not putting the brunt of the blame on fpc.  fesco has continued to approve the things passed up from fpc.  so as much of the blame rests here
spotwell, we've been trying to do that for literally months... :)
jeremyspot: I don't think that tools to check against the guidelines really helps
but, we're way off on a tangent by now
spotjeremy: well, if you have some magic way to make people not submit specs that are horrific, i would love to see it. ;)
jwbsummary:
- waiting for guidelines improves package quality at the potential cost of raising the barrier for entry
yes?
barrier for entry of new packagers
jeremyjwb: arguably, it only potentially improves package quality
jwbthat is the goal of it anyway
so
spoti think with ocaml, we have a tangible example showing that it does improve package quality.
jwbit seems we have to balance between potential quality issues vs. potential packager discouragement
f13the flip side, our barrier of entry for /reviewing/ packages improves when we have accurate guidelines in place
warrenEven as simple as misnaming the package and it getting in the distro because there's no package naming guidelines is a bit painful
f13because without guidelines, nobody wants to review it to begin with
* spot nods
f13spot: theoretically we'll have another example with java, and we have python, and mono, and... hey look, there is a trend here.
jwbf13, i have a counter to that
it's not very productive though
f13heh
spotbpepple: perhaps we should take a vote?
bpepplespot: I'm fine with that.
Let's see a quick show of hands for spot's proposal.
* jeremy is still -1
--- bpepple has changed the topic to: FESCo-Meeting -- Proposal - FPC determines that guidelines are needed for a type of packages, we hold all such packages from entering until a basic set of guidelines is approved.
bpepple+1
dwmw2+1
tibbs+1
nirik+1
f13+1
warren+1
spot+1
dgilmore+1
notting0
jwbpassed
0 fwiw
bpeppleok, I see eight '+1, two '0', and one '-1-".
spot's proposal has been approved.
nottingdoes fesco reserve the right to 'impel' FPC to write a set of guidelines?
bpepplenotting: seems reasonable to me.
spotnotting: technically, i suppose they do.
tibbsFPC generally prefers to work with the packagers to develop guidelines.  These days it's not often that we have sufficient expertise on the committee itself.
bpeppleanything else?  we really need to move on.
tibbsmove on++
--- bpepple has changed the topic to: FESCo-Meeting -- Final Release Schedule (Slip in conjunction w/ latest beta slip?) - all
bpepplef13: you want to lead this?
jwbit's fairly simple really
we've slipped about 3 weeks collectively, but the end date hasn't moved
so it decreases the development/testing time we have for final
f13not quite a full 3 weeks
poelcat19 days of testing lost between alpha and beta + rawhide hasn't exactly been installable on a daily basis
jwbf13, 3 business weeks
bpepplehow far back are we looking to slip?
f13however, we have weekly snapshots after beta, plus we aren't doing feature work which is the large cause of things not being installable.
I personally don't want to slip
at all
I still think it's feasable to reach our original final release schedule
nottingso, as of now there are 13 buisness days until the final freeze
poelcatbut features don't have to be 100% until final devel freeze
nottingand we haven't released the beta yet
f13especially if we tell people that we're *firm* on that date so that they don't feel that they can wait on things.
bpepplef13: do QA have enough time for testing with the slip?
f13notting: beta is freed to mirrors today, rawhide is back in business tonight
jeremyf13: just like we've been "firm" on every date thus far...
* notting looks at wwoods
jeremynotting: he's not around today I don't think
f13jeremy: well, we wanted to have predictable 6 month releases.  We either have those, or we go back to having preditable 6 month slips
* notting mutters something about lurking in meeting channels if you're not available
poelcatf13: what if snapshots fair as well as alpha, beta, and recent rawhide?
* bpepple is also inclined not to slip also, depending on what the QA team thinks.
nottingf13: ? name a date we have previously hit for fedora without a slip.
(sad, but true)
f13poelcat: if they do, we make a decision after the fact about slipping, not planning for failure.
notting: so we sucked before, lets just continue to suck?
nottingf13: no, i'm saying it's a more systemic problem
jwbpoelcat, fwiw i've found beta to be much better than alpha
nottingi do not think we have ever *not* slipped
poelcatf13: but we keep saying 'let's decide later'
jwbit's almost as if we're doing what the terms imply or something
f13notting: yes, one that I'd like to fix rather than just sigh and continue on.
jeremynotting: actually, after we did the initial slip with f8, we kept to it iirc
f13yeah, F8 was far less slippy
nottingf13: well, if we a) know we generally do slip, b) we're already concerned about the date...
f13notting: then we pick better fricking dates.
because I'm tired of not meeting any of them.
* jeremy is mostly just concerned due to the short time we now have between now and final freeze
poelcat advocated longer testing periods, but we said they didn't matter because we had rawhide
f13poelcat: if rawhide has been a disaster leading up to when we're supposed to final freeze, we can make a decision at that time to extend the freeze date and slip.
* notting as well. 10 days between beta and final freeze seems like too little
jeremyf13: better dates don't just fall from the sky...  part of it is what we were talking about yesterday where we don't give any guidance to new packagers about the release process
f13jeremy: nod
jwbcan we move the final freeze and not the release date?
what does that do to QA time?
dgilmoref13: id rather not slip but if we do it should only be 1 week
jeremyjwb: hurts somewhat.  more changes "later"
jwbjeremy, to be honest, new packagers rarely impact things we consider for holding up a release
f13the problem I have with this is if we slip now, and rawhide is still a disaster, we've slipped for no good reason.
poelcathttp://poelstra.fedorapeople.org/schedules/f-9/f-9-releng-tasks.html
nottingjwb: that squishes the time between preview and rc
poelcathow we've done so far: http://poelstra.fedorapeople.org/schedules/f-9/f-9-releng-performance.html
ignore top summary (i know it is wrong)
* f13 can't grok this page
tibbsI was afraid it was just me.
poelcatsorry :)
jwbi think you need to have uber project manager powers
poelcatfor each task... top is planned, followed by actual
* poelcat agrees this isn't the most user-friendly format
poelcatsorry to derail discussion
nottingmaybe revisit next week with QA input?
bpepplef13: one thing to think about, is that if we are going to slip we need to make the decision early enough so marketing, art, etc folks are aware of it.
tibbsWhat's the downside to deciding this later?
warrentibbs, some people just give up thinking they can't complete something in time
bpeppleI know marketing folks stumbled a bit about our pushing the beta release back.
jeremynotting: I'm okay with that.  and maybe also start a general discussion?  (not sure if that helps or hurts, though tbh)
f13bpepple: except that we decide to slip a week now, and then come freeze time, shit has been bad and we have to slip again, thus ruining any benifit of early slip warning.
jwbi'm leaning toward agreeing with f13 here
f13bpepple: sure, that was my fault for not announcing it when we decided it.  I was rather... involved.
warrenhow many days did we lose already from past slips?
poelcat19
jwb19.  we said that at the start
bpepplef13: totally understandable.  I just want to make sure we're taking into account how other aspects of the project will be affected.
poelcatf13: i see where you're coming from now
f13 fab
f1319 is still a bit of a lie
because you're counting time from beta /release/ to final freeze as the development time
when in reality, we're releasing rawhide tonight, so the counter until final freeze starts now, not next tuesday
jwbso 15 then?
which would be my 3 business weeks
nottingsort of. but only for those with bandwidth
warrenThere is merit to both sides of slip/not slip here.
Perhaps a compromise? 15/2
* jeremy thinks that having the conversation when will and/or other QA representation is around is worthwhile
bpepplejeremy: agreed.
jeremy(which, I guess in some ways gives us "let's see what happens when we try to build a snapshot next week" too :-)
f13jeremy: I agree too
yeah, we should talk about the snapshots in the releng meeting next week
'cause we need a plan.
jwbplans are made to be slipped
oops... did i say that outloud?
ok, i think we all agreed on "wait until next week"
f13yep, we can move to the next topic, if there is one
bpepplef13: yeah, we still need to talk about features for a bit.
--- bpepple has changed the topic to: FESCo-Meeting -- Features Completion - http://fedoraproject.org/wiki/Releases/9/FeatureList - poelcat
poelcatis there ever :)
In the interest of time wanted to get FESCo input today on features that are <= 85% complete and/or have not been updated since before beta freeze--basically if there are any known reasons they should be dropped from the 'F9 Accepted List' so our beta announcement is accurate
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/VirtStorage
poelcati pinged all owners privately on all of these... most responded, some did not
tibbsI wonder how much of the stuff in the contingency plan is implemented.
jeremywe have a new libvirt which at least in theory has storage apis
(according to rpm -q --changelog libvirt :)
tibbsHonestly, no updates in two months and still at 25% complete makes me think we should drop this.
bpeppletibbs: I agree.
* jeremy suspects it's not ... all that compelling to most people too
tibbsIs Daniel perhaps on vacation?
f13no, he's just very very busy it seems
(same old song and dance right?)
dgilmoretibbs: i agree it should be dropped
f13he rides the bus with us, but I don't recall seeing him on the bus today
tibbsWhen you're too busy to say you're too busy, that's busy.
f13I could ask him in person about it.
tibbsWhen do we need to make this decision?
poelcatbefore beta would be nice so that PR reflects correct list
f13poelcat: perhaps we can just avoid mentioning these suspect features in any press for now, but not out right remove them from the list?
tibbsWhich means this meeting or on the list.
jeremyf13: that's what I was going to suggest...
poelcatokay, that adds a little more overhead, but I can do it :)
though I think we often refer to the complete feature list
jeremythe two other things that jump out as < 85% to me are PackageKit and Live Persistence
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/LivePersistence
tibbsI don't we should be shy about dropping things  if we need to.  We're pretty much up against the beta deadline.
f13tibbs: yes, but I want the droppings to reflect reality, not just a (not so) innocent lack of a wiki page update
jeremythe main reason that's at < 85% is because I pulled a number out of thin air ;-)   what's missing is some more writing up of docs and also probably a notifier about the fact that any changes you make aren't going to get preserved
f13yeah, if 85% isn't reflected anywhere as the cut off %, I'd be very against dropping things for that reason
tibbsIs this one of those things that has to be right on release because we effectively can't update it?
jeremytibbs: well, we can update docs
which is the big thing missing
this _does_ need testing by more than myself and warren :-)
f13heh
jeremyoh, and f13 :)
nottingsurely dmac will test it
jwbjeremy, point me at the docs and i can test with a 2gig key
warrenI have been using it extensively
f13jeremy: I haven't tested it at all
bpepplejeremy: that should be something that should be fairly easy to get testers for.
warrenjeremy, is it normal for it to *always* playback the journal whenever I startup?
jeremyjwb: the feature page has the basics
jwbok
jeremywarren: I've been noticing that on running systems too... jesse said something about kenrel panics on shutdown before lunch
jeremybpepple: yep!  but we have to have the beta so there are live images available, ...
jeremyhence, chicken, egg, etc
warrenGNOME shutdown fails to shutdown in both normal and live peristence
bpepplejeremy: we could probably publicize it a bit on planet fedora also.
warrenI might have been forcing a shutdown
jeremybpepple: I did!  but plan to again
poelcatready to move to the next one? sounds like this one has a good chance of being in
bpepplepoelcat: agreed.
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/HandwritingRecognizer
* bpepple waits for the wiki to load.
tibbsI received no response to my request for clarification.
f13warren: works sometimes for me, but there is the kernel panic
niriklast updated almost a month ago?
warrenWho was sent e-mail asking for clarification?
nottingiirc, this barely passed initial approval
jwb-1
warrenThey might not have seen the request for clarification if they weren't asked via mail.
tibbsYeah, no updates since we discussed it three weeks ago.
Well, they were responding to the Comments section.
f13kick it to the curb
bpepplewarren: poelcat did send out a request last week for feature owners to update their pages.
poelcatwarren: i sent mail to feature owners
bpepple-1 here also.
tibbsI wanted to see this firm up after we accepted it at the last minute, but nothing has happened.
-1
warrenLet me ask their team lead, I'm guessing he would say, "Yeah this isn't ready to announce as a shiny feature."
* warren nudges juhp
dgilmore says yank it
poelcatanyone opposed to dropping it?
jeremyjust from looking, it looks not ready to really be feature material
* nirik is fine with dropping this one.
warren-1 but let's be clear in the communication that this only means it wont be part of the marketing, not that they should give up on it.
bpepplethey can always push it as a feature for F10.
warren: agreed.
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/PackageKit
nottingkeep it in... for now
(pk)
tibbsI think we need to have this and need to hype it.
* nirik notes the feature page seems to be inaccurate now...
tibbsBut if it's not ready....
bpepple+1 to keeping in for now.
jeremy+1
nirikI'm +1 for keeping it, but we should note that it's being made the default...
tibbsnirik: How is the page inaccurate?
jeremyalthough the page needs some updates.  I'll get with robin to either have him do so this afternoon or do them myself
poelcatwho knows... it hasn't been updated in 1.5 months
jeremy: thanks!
f13+1 for keeping it
nirikit says "be added as an optional package management system, not replace the existing Fedora tools." but it is going to replace them in Beta.
f13nirik: yeah, that got changed
nirikwe should update that asap so Beta docs are misleading, IMHO. ;)
bpepplenirik: agreed.
jwb0
i'm not thrilled with it being default, but it seems to be "the way forward"
nirikalthough I'm sure in some ways it's too late, since docs has lots of pup/pirut stuff.
f13we also reserve the right to fall back to pup/pirut should PK blow up
bpepplepoelcat: anything else for today?
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/K12Linux
poelcatno update since 06-mar
just wanted to make sure
f13warren: isn't that you?
* nirik looks at warren
dgilmorewarren:
tibbsHmmm.
warrenworking actively on it, it works quite well now
dgilmorewarren: please update the status of the wiki
warrenOK
poelcatbpepple: that is mostly it unless people want to tell me about others that should be adjusted
* poelcat will probably raise feature process at FUDCon to tune it a little more
poelcatstill seems like it could be a little more efficient
bpepplepoelcat: the swfec feature should probably be dropped, since I'm not sure it meets the standard for a new feature.
dgilmorepoelcat: thanks for all your work
poelcatand rely less on me beating people over the head to update wiki pages
bpeppleanything else, or should we wrap up for this week?
* warren thinks swfdec shouldn't be default install at all
jwbaren't we 1/2 hour over?
poelcatbpepple: vote to drop swfdec?
bpepplepoelcat: I'm not sure it needs a vote even.
jeremyyeah, if the feature owner wants to drop it, they should be able to :)
poelcatprobably best so it doesn't look i'm making stuff up :)
that too
warrenAre we removing it from default install too?
bpepplewarren: yeah, though I left it on for beta so we could get more testing for upstream.
warrensounds good
dgilmorelets wrap up
bpeppledgilmore: agreed.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!
dgilmorethanks bpepple

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!