| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo 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 | ||
| jeremy | f13 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. | ||
| nirik | luckily dircproxy is long fixed. ;) | |
| dwmw2 | fish | |
| f13 | whoh, a dwmw2 | |
| bpepple | ok, 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 | ||
| dwmw2 | f13: look no airport code! | |
| bpepple | The bugzappers had 2 poroposals. | |
| * dgilmore is here | ||
| f13 | dwmw2: crazy! | |
| warren | dwmw2, did you just give up and move your residence into a plane? | |
| dwmw2 | heh, no. | |
| * nirik wonders if that means dwmw2 is now "everywhere". ;) | ||
| bpepple | The first one was to clear out bugs for unsupported versions: http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver | |
| jeremy | not 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 | ||
| bpepple | f13: ;) | |
| tibbs | +1; it's better than just closing all <=FC6 bugs. | |
| nirik | +1 from me... | |
| * jwb gets 503 | ||
| bpepple | ok, 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 | ||
| bpepple | The 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 | |
| bpepple | alright, I see eight '+1', so this proposal has also been approved. | |
| anything else, or should we move on? | ||
| tibbs | Although I think this might need exceptions for the package review tickets. | |
| bpepple | tibbs: yeah, that makes sense. we can pass that along to poelcat. | |
| tibbs | Who knows what releases were picked for those. | |
| poelcat | tibbs: would you see any type of time limit? | |
| nirik | yeah, although... pinging those once a release might be nice... | |
| f13 | +1 | |
| nirik | the merge reviews should stick around tho. | |
| poelcat | IOW if it is open for X releases w/ no action... close it? | |
| tibbs | Well, 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. | ||
| poelcat | fair enough | |
| tibbs | And 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. | ||
| poelcat | what 'version' should they keep? | |
| nirik | rawhide? | |
| tibbs | I don't think it really matters. rawhide is probably as good as anything else. | |
| tibbs | But then you have to worry about the mass-mover script. | |
| dgilmore | tibbs: rawhide sounds best | |
| it should trikle down from there | ||
| poelcat | it makes it cleaner/easier to manage if there are literally zero bugs for unmaintained releases | |
| well, zero 'open' bugs | ||
| bpepple | anything 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 | |
| tibbs | Originally the board allowed FPC to do this. | |
| dwmw2 | for now, -1. We really ought to sort out the guidelines rather than blocking for ever | |
| tibbs | We are sorting the guidelines. | |
| f13 | cleaning up messes is a lot harder than keeping things out until we have something reasonable to measure it by | |
| dwmw2 | but it's too late for f9 anyway; let's make sure it's sorted by f10 | |
| jwb | tibbs, "the board" as in the Fedora Board? | |
| dwmw2 | true | |
| tibbs | jwb: Yes. | |
| Way back when. | ||
| This java thing is only the first time there's been significant complaint. | ||
| jwb | why did this go to the board? | |
| dgilmore | f13: indeed | |
| nirik | I just want it to be clear if we are blocking on guidelines or not... and who decides. ;) | |
| tibbs | The board originally constituted the FPC. | |
| dgilmore | tibbs: what did the board allow FPC to do? | |
| tibbs | This was before the core-extras merge. | |
| jwb | oh, that long ago | |
| f13 | Proposal: If the package is too confusing for reviewers to actually review it without guidelines, it can't come in until we get guidelines. | |
| tibbs | dgilmore: block new packages on the acceptance of guidelines | |
| nirik | it'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. | |
| bpepple | f13: +1 | |
| f13 | and absolutely -1 on reviewing packages based on Draft guidelines. | |
| dgilmore | tibbs: we should block until we have acceptable guidelines | |
| warren | How likely are the guidelines to be approved and how soon? | |
| nirik | +1 to f13's proposal. Who enforces this tho? | |
| notting | f13: +1 | |
| tibbs | My 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... | ||
| f13 | warren: java guidelines could be approved at next FPC meeting | |
| warren: lots of good work has gone into it | ||
| warren | nice | |
| tibbs | Yes, we have a huge raft of stuff for next Tuesday. | |
| warren | So this means cvsadmin should wait if we see more of the customary "java team approves its own package" review? | |
| bpepple | ok, is there anyone who disagrees with f13's proposal? | |
| nirik | warren: yes, and block F_GUIDELINES | |
| warren | OK | |
| at least I wouldn't be the bad guy there. | ||
| tibbs | You can help with being the bad guy if you like. | |
| spot | -1, fwiw | |
| bpepple | spot: is that to f13's proposal. | |
| nirik | I 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. | |
| bpepple | s/./?/ | |
| spot | yes. | |
| bpepple | ok, 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 | |
| jwb | is this only for java, or any random language that doesn't have guidelines? | |
| nirik | spot: 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. | |
| dwmw2 | blocked contributors can help with the guidelines :) | |
| bpepple | dwmw2: agreed, there would be an incentive to get them worked on. | |
| spot | Basically, 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. | |
| jeremy | dwmw2: having to dive in and write _guidelines_ for how to package something when it's your first package is hardly an incentive | |
| dwmw2 | jeremy: we return to the quality vs. quantity debate... | |
| tibbs | spot: +1 | |
| dgilmore | spot: i think thats largely what f13 is saying | |
| dwmw2 | dgilmore: I thought so too | |
| * bpepple thinks the same thing. | ||
| nirik | spot: +1 to that... | |
| spot | dgilmore: perhaps, but his wording is less clear than mine. | |
| nirik | yeah, except the part about FPC deciding... which makes sense to me. | |
| dgilmore | spot: i agree that if it needs guidelines it needs to wait until guidelines are approved | |
| jeremy | spot: so when does fpc make that decision? | |
| spot | when we notice review problems. :) we have several of the most prolific reviewers on the FPC | |
| tibbs | We need to formalize how the decision is formalized. | |
| spot | and 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 ;) | ||
| f13 | usually 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"? | |
| tibbs | You say that as if it is one of our goals to hold up reviews and discourage contributors. | |
| Our mandate is only for packaging quality. | ||
| spot | jeremy: the problem is that we get poor quality packages for these situations, with files missing or in wrong locations | |
| nirik | and little incentive to go back and fix them. | |
| spot | precisely. | |
| tibbs | And this does cause problems for the whole distro. | |
| dwmw2 | jeremy 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 | |
| jeremy | tibbs: 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 :( | |
| tibbs | I disagree. | |
| f13 | jeremy: we're also seeing a lot more of new and insteresting software to package | |
| which weren't considered before as well | ||
| tibbs | The problem with the java stuff is that it's so complicated. | |
| f13 | ditto ocaml | |
| tibbs | I can't tell whether it actually needs to be that complicated. | |
| f13 | hell even mono for that matter, but at least we have /something/ there. | |
| tibbs | But ocaml went in quickly and without too much fuss. | |
| * spot nods | ||
| f13 | tibbs: except it's still not right | |
| (multilib) | ||
| spot | f13: yes, but its close enough for basic guidelines | |
| f13 | sure | |
| dwmw2 | I'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 | |
| notting | bbia couple of minutes, sorry | |
| jeremy | I'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? | |
| spot | again, no one is saying we have to have it perfect, just good enough for general package quality and standardization | |
| dwmw2 | for things other than ocaml it really is worth getting it right first | |
| dgilmore | dwmw2: I hope to have sugar activities pretty much right first time | |
| dwmw2 | cool | |
| dgilmore | but they defintely need new guidelines | |
| tibbs | So where are we at? | |
| f13 | jeremy: there is a fix for that. Put in real effort to make .spec files less so damn convoluted and free form | |
| tibbs | Besides 30 minutes through the meeting. | |
| f13: Can't argue with that. | ||
| bpepple | tibbs: agreed. we've got plenty of things still left on the agenda. | |
| jeremy | f13: 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 | ||
| bpepple | are we at a point to vote on spot's proposal, or do we need to discuss this on the mailing lists? | |
| spot | jeremy: there may be ways to make the "checking against guidelines easier", some tooling like "rpmlint" for lang specific guidelines. | |
| f13 | jeremy: 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. | |
| notting | as 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 | |
| jeremy | f13: 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 | |
| spot | well, we've been trying to do that for literally months... :) | |
| jeremy | spot: I don't think that tools to check against the guidelines really helps | |
| but, we're way off on a tangent by now | ||
| spot | jeremy: well, if you have some magic way to make people not submit specs that are horrific, i would love to see it. ;) | |
| jwb | summary: | |
| - waiting for guidelines improves package quality at the potential cost of raising the barrier for entry | ||
| yes? | ||
| barrier for entry of new packagers | ||
| jeremy | jwb: arguably, it only potentially improves package quality | |
| jwb | that is the goal of it anyway | |
| so | ||
| spot | i think with ocaml, we have a tangible example showing that it does improve package quality. | |
| jwb | it seems we have to balance between potential quality issues vs. potential packager discouragement | |
| f13 | the flip side, our barrier of entry for /reviewing/ packages improves when we have accurate guidelines in place | |
| warren | Even as simple as misnaming the package and it getting in the distro because there's no package naming guidelines is a bit painful | |
| f13 | because without guidelines, nobody wants to review it to begin with | |
| * spot nods | ||
| f13 | spot: theoretically we'll have another example with java, and we have python, and mono, and... hey look, there is a trend here. | |
| jwb | f13, i have a counter to that | |
| it's not very productive though | ||
| f13 | heh | |
| spot | bpepple: perhaps we should take a vote? | |
| bpepple | spot: 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 | |
| notting | 0 | |
| jwb | passed | |
| 0 fwiw | ||
| bpepple | ok, I see eight '+1, two '0', and one '-1-". | |
| spot's proposal has been approved. | ||
| notting | does fesco reserve the right to 'impel' FPC to write a set of guidelines? | |
| bpepple | notting: seems reasonable to me. | |
| spot | notting: technically, i suppose they do. | |
| tibbs | FPC 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. | |
| bpepple | anything else? we really need to move on. | |
| tibbs | move on++ | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Final Release Schedule (Slip in conjunction w/ latest beta slip?) - all | ||
| bpepple | f13: you want to lead this? | |
| jwb | it'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 | ||
| f13 | not quite a full 3 weeks | |
| poelcat | 19 days of testing lost between alpha and beta + rawhide hasn't exactly been installable on a daily basis | |
| jwb | f13, 3 business weeks | |
| bpepple | how far back are we looking to slip? | |
| f13 | however, 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 | ||
| notting | so, as of now there are 13 buisness days until the final freeze | |
| poelcat | but features don't have to be 100% until final devel freeze | |
| notting | and we haven't released the beta yet | |
| f13 | especially if we tell people that we're *firm* on that date so that they don't feel that they can wait on things. | |
| bpepple | f13: do QA have enough time for testing with the slip? | |
| f13 | notting: beta is freed to mirrors today, rawhide is back in business tonight | |
| jeremy | f13: just like we've been "firm" on every date thus far... | |
| * notting looks at wwoods | ||
| jeremy | notting: he's not around today I don't think | |
| f13 | jeremy: 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 | ||
| poelcat | f13: 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. | ||
| notting | f13: ? name a date we have previously hit for fedora without a slip. | |
| (sad, but true) | ||
| f13 | poelcat: 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? | ||
| notting | f13: no, i'm saying it's a more systemic problem | |
| jwb | poelcat, fwiw i've found beta to be much better than alpha | |
| notting | i do not think we have ever *not* slipped | |
| poelcat | f13: but we keep saying 'let's decide later' | |
| jwb | it's almost as if we're doing what the terms imply or something | |
| f13 | notting: yes, one that I'd like to fix rather than just sigh and continue on. | |
| jeremy | notting: actually, after we did the initial slip with f8, we kept to it iirc | |
| f13 | yeah, F8 was far less slippy | |
| notting | f13: well, if we a) know we generally do slip, b) we're already concerned about the date... | |
| f13 | notting: 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 | ||
| f13 | poelcat: 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 | ||
| jeremy | f13: 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 | |
| f13 | jeremy: nod | |
| jwb | can we move the final freeze and not the release date? | |
| what does that do to QA time? | ||
| dgilmore | f13: id rather not slip but if we do it should only be 1 week | |
| jeremy | jwb: hurts somewhat. more changes "later" | |
| jwb | jeremy, to be honest, new packagers rarely impact things we consider for holding up a release | |
| f13 | the problem I have with this is if we slip now, and rawhide is still a disaster, we've slipped for no good reason. | |
| poelcat | http://poelstra.fedorapeople.org/schedules/f-9/f-9-releng-tasks.html | |
| notting | jwb: that squishes the time between preview and rc | |
| poelcat | how 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 | ||
| tibbs | I was afraid it was just me. | |
| poelcat | sorry :) | |
| jwb | i think you need to have uber project manager powers | |
| poelcat | for each task... top is planned, followed by actual | |
| * poelcat agrees this isn't the most user-friendly format | ||
| poelcat | sorry to derail discussion | |
| notting | maybe revisit next week with QA input? | |
| bpepple | f13: 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. | |
| tibbs | What's the downside to deciding this later? | |
| warren | tibbs, some people just give up thinking they can't complete something in time | |
| bpepple | I know marketing folks stumbled a bit about our pushing the beta release back. | |
| jeremy | notting: I'm okay with that. and maybe also start a general discussion? (not sure if that helps or hurts, though tbh) | |
| f13 | bpepple: 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. | |
| jwb | i'm leaning toward agreeing with f13 here | |
| f13 | bpepple: sure, that was my fault for not announcing it when we decided it. I was rather... involved. | |
| warren | how many days did we lose already from past slips? | |
| poelcat | 19 | |
| jwb | 19. we said that at the start | |
| bpepple | f13: totally understandable. I just want to make sure we're taking into account how other aspects of the project will be affected. | |
| poelcat | f13: i see where you're coming from now | |
| f13 fab | ||
| f13 | 19 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 | ||
| jwb | so 15 then? | |
| which would be my 3 business weeks | ||
| notting | sort of. but only for those with bandwidth | |
| warren | There 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 | ||
| bpepple | jeremy: 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 :-) | |
| f13 | jeremy: I agree too | |
| yeah, we should talk about the snapshots in the releng meeting next week | ||
| 'cause we need a plan. | ||
| jwb | plans are made to be slipped | |
| oops... did i say that outloud? | ||
| ok, i think we all agreed on "wait until next week" | ||
| f13 | yep, we can move to the next topic, if there is one | |
| bpepple | f13: 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 | ||
| poelcat | is 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 | ||
| poelcat | i pinged all owners privately on all of these... most responded, some did not | |
| tibbs | I wonder how much of the stuff in the contingency plan is implemented. | |
| jeremy | we have a new libvirt which at least in theory has storage apis | |
| (according to rpm -q --changelog libvirt :) | ||
| tibbs | Honestly, no updates in two months and still at 25% complete makes me think we should drop this. | |
| bpepple | tibbs: I agree. | |
| * jeremy suspects it's not ... all that compelling to most people too | ||
| tibbs | Is Daniel perhaps on vacation? | |
| f13 | no, he's just very very busy it seems | |
| (same old song and dance right?) | ||
| dgilmore | tibbs: i agree it should be dropped | |
| f13 | he rides the bus with us, but I don't recall seeing him on the bus today | |
| tibbs | When you're too busy to say you're too busy, that's busy. | |
| f13 | I could ask him in person about it. | |
| tibbs | When do we need to make this decision? | |
| poelcat | before beta would be nice so that PR reflects correct list | |
| f13 | poelcat: perhaps we can just avoid mentioning these suspect features in any press for now, but not out right remove them from the list? | |
| tibbs | Which means this meeting or on the list. | |
| jeremy | f13: that's what I was going to suggest... | |
| poelcat | okay, that adds a little more overhead, but I can do it :) | |
| though I think we often refer to the complete feature list | ||
| jeremy | the 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 | ||
| tibbs | I don't we should be shy about dropping things if we need to. We're pretty much up against the beta deadline. | |
| f13 | tibbs: yes, but I want the droppings to reflect reality, not just a (not so) innocent lack of a wiki page update | |
| jeremy | the 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 | |
| f13 | yeah, if 85% isn't reflected anywhere as the cut off %, I'd be very against dropping things for that reason | |
| tibbs | Is this one of those things that has to be right on release because we effectively can't update it? | |
| jeremy | tibbs: well, we can update docs | |
| which is the big thing missing | ||
| this _does_ need testing by more than myself and warren :-) | ||
| f13 | heh | |
| jeremy | oh, and f13 :) | |
| notting | surely dmac will test it | |
| jwb | jeremy, point me at the docs and i can test with a 2gig key | |
| warren | I have been using it extensively | |
| f13 | jeremy: I haven't tested it at all | |
| bpepple | jeremy: that should be something that should be fairly easy to get testers for. | |
| warren | jeremy, is it normal for it to *always* playback the journal whenever I startup? | |
| jeremy | jwb: the feature page has the basics | |
| jwb | ok | |
| jeremy | warren: I've been noticing that on running systems too... jesse said something about kenrel panics on shutdown before lunch | |
| jeremy | bpepple: yep! but we have to have the beta so there are live images available, ... | |
| jeremy | hence, chicken, egg, etc | |
| warren | GNOME shutdown fails to shutdown in both normal and live peristence | |
| bpepple | jeremy: we could probably publicize it a bit on planet fedora also. | |
| warren | I might have been forcing a shutdown | |
| jeremy | bpepple: I did! but plan to again | |
| poelcat | ready to move to the next one? sounds like this one has a good chance of being in | |
| bpepple | poelcat: agreed. | |
| --- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/HandwritingRecognizer | ||
| * bpepple waits for the wiki to load. | ||
| tibbs | I received no response to my request for clarification. | |
| f13 | warren: works sometimes for me, but there is the kernel panic | |
| nirik | last updated almost a month ago? | |
| warren | Who was sent e-mail asking for clarification? | |
| notting | iirc, this barely passed initial approval | |
| jwb | -1 | |
| warren | They might not have seen the request for clarification if they weren't asked via mail. | |
| tibbs | Yeah, no updates since we discussed it three weeks ago. | |
| Well, they were responding to the Comments section. | ||
| f13 | kick it to the curb | |
| bpepple | warren: poelcat did send out a request last week for feature owners to update their pages. | |
| poelcat | warren: i sent mail to feature owners | |
| bpepple | -1 here also. | |
| tibbs | I wanted to see this firm up after we accepted it at the last minute, but nothing has happened. | |
| -1 | ||
| warren | Let 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 | ||
| poelcat | anyone opposed to dropping it? | |
| jeremy | just 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. | |
| bpepple | they can always push it as a feature for F10. | |
| warren: agreed. | ||
| --- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/PackageKit | ||
| notting | keep it in... for now | |
| (pk) | ||
| tibbs | I think we need to have this and need to hype it. | |
| * nirik notes the feature page seems to be inaccurate now... | ||
| tibbs | But if it's not ready.... | |
| bpepple | +1 to keeping in for now. | |
| jeremy | +1 | |
| nirik | I'm +1 for keeping it, but we should note that it's being made the default... | |
| tibbs | nirik: How is the page inaccurate? | |
| jeremy | although the page needs some updates. I'll get with robin to either have him do so this afternoon or do them myself | |
| poelcat | who knows... it hasn't been updated in 1.5 months | |
| jeremy: thanks! | ||
| f13 | +1 for keeping it | |
| nirik | it says "be added as an optional package management system, not replace the existing Fedora tools." but it is going to replace them in Beta. | |
| f13 | nirik: yeah, that got changed | |
| nirik | we should update that asap so Beta docs are misleading, IMHO. ;) | |
| bpepple | nirik: agreed. | |
| jwb | 0 | |
| i'm not thrilled with it being default, but it seems to be "the way forward" | ||
| nirik | although I'm sure in some ways it's too late, since docs has lots of pup/pirut stuff. | |
| f13 | we also reserve the right to fall back to pup/pirut should PK blow up | |
| bpepple | poelcat: anything else for today? | |
| --- poelcat has changed the topic to: http://fedoraproject.org/wiki/Features/K12Linux | ||
| poelcat | no update since 06-mar | |
| just wanted to make sure | ||
| f13 | warren: isn't that you? | |
| * nirik looks at warren | ||
| dgilmore | warren: | |
| tibbs | Hmmm. | |
| warren | working actively on it, it works quite well now | |
| dgilmore | warren: please update the status of the wiki | |
| warren | OK | |
| poelcat | bpepple: 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 | ||
| poelcat | still seems like it could be a little more efficient | |
| bpepple | poelcat: the swfec feature should probably be dropped, since I'm not sure it meets the standard for a new feature. | |
| dgilmore | poelcat: thanks for all your work | |
| poelcat | and rely less on me beating people over the head to update wiki pages | |
| bpepple | anything else, or should we wrap up for this week? | |
| * warren thinks swfdec shouldn't be default install at all | ||
| jwb | aren't we 1/2 hour over? | |
| poelcat | bpepple: vote to drop swfdec? | |
| bpepple | poelcat: I'm not sure it needs a vote even. | |
| jeremy | yeah, if the feature owner wants to drop it, they should be able to :) | |
| poelcat | probably best so it doesn't look i'm making stuff up :) | |
| that too | ||
| warren | Are we removing it from default install too? | |
| bpepple | warren: yeah, though I left it on for beta so we could get more testing for upstream. | |
| warren | sounds good | |
| dgilmore | lets wrap up | |
| bpepple | dgilmore: 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! | ||
| dgilmore | thanks bpepple | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!