17:00:19 <jds2001> #startmeeting FESCo meeting 2009-08-07
17:00:20 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:27 * nirik is here.
17:00:32 <jds2001> FergatROn: in #fedora-websites
17:00:40 <Kevin_Kofler> Present.
17:00:46 <FergatROn> jds2001: the meeting is on #fedora-websites channel?
17:00:47 <FergatROn> odd
17:00:55 * skvidal is here
17:01:00 <jds2001> FergatROn: yeah, the websites meeting conflicts with FESCo
17:01:06 <FergatROn> jds2001: thanks
17:02:18 * notting is here now
17:02:25 <jds2001> cool
17:02:35 <jds2001> shall we get started?
17:02:48 <jds2001> #topic MW Patch issue
17:02:54 <jds2001> .fesco 225
17:03:06 <jds2001> Kevin_Kofler: you have an update here?
17:03:19 <Kevin_Kofler> So some discussion got started after this got escalated, I had hoped they'd find a resolution. Unfortunately, the discussion has since dried out.
17:03:37 <jds2001> yeah , me too :(
17:03:56 * ricky would be happy to restart the discussion - I just need to do some testing on some of the methods mentioned
17:04:51 <jds2001> that does no good if the maintainer doesnt apply your patch :(
17:04:54 <nirik> shall we let ricky do that and revisit in a while? or ?
17:04:59 <jds2001> sure
17:05:26 <jds2001> #topic outdated wiki
17:05:30 <jds2001> .fesco 176
17:05:33 <Kevin_Kofler> nirik: Sure.
17:05:41 <jds2001> so our wiki pages are in various states of fail.
17:05:50 <j-rod> Running late, sorry
17:06:16 <jds2001> notting wanted to appoint someone to JFDI :)
17:06:23 <notting> jds2001: yeah, my goal was to bring this up so that the 'Assigned to' part of this ticket is no longer blank
17:06:25 <jds2001> which seems reasonable
17:07:00 <jds2001> volunteers?
17:07:20 * jds2001 hears crickets
17:08:25 <nirik> Finding the time is the big thing. ;( Perhaps some docs people would be willing to help out?
17:08:39 <jds2001> yeah, -ENOTIME here too :(
17:09:12 <jds2001> ianweller: you around?
17:09:26 <Kevin_Kofler> Before appointing something to do the work, we should agree on what should be done.
17:09:26 <nirik> or call for helpers on the devel list?
17:09:34 * jds2001 defers to the wiki czar
17:09:36 <Kevin_Kofler> So the plan for the template page is to turn it into a Trac template?
17:09:48 <Kevin_Kofler> That needs somebody with Trac admin privileges to handle.
17:09:49 <jds2001> Kevin_Kofler: i think that makes sense, I can do that
17:09:53 <ianweller> jds2001: sorta!
17:09:58 <Kevin_Kofler> Then the wiki page can be removed.
17:10:13 <ianweller> uh oh "perhaps some docs people are willing to help out / ianweller: you around?" bad combination for me. ;)
17:10:18 * nirik looks more closely at the ticket again.
17:10:30 <Kevin_Kofler> For the schedule page, I think we should be linking to https://fedorahosted.org/fesco/report/9
17:10:42 <jds2001> ianweller: no, we're just saying that our pages are in a state of fail
17:10:47 <nirik> so that gets rid of a few pages on the wiki side, but we need to clean up the overall tree of fesco pages.
17:10:50 <ianweller> ok
17:11:11 <jds2001> we're looking for some assistance to get them out of said state of fail :)
17:11:37 <ianweller> i'm usually around to answer questions in #fedora-docs (or even #fedora-devel)
17:12:42 <jds2001> alright, I'll put out a call for a proposal on what should be done
17:12:43 <nirik> so, looking at the http://fedoraproject.org/wiki/PackageMaintainers page, I would say we should look at: renaming category pages consistently, putting "policies" in one area, and "suggestions" in another and "guides/howtos" in another?
17:12:44 <skvidal> jds2001: we could just change them to say "ask jds2001 on irc if you need to know something"
17:12:46 <Kevin_Kofler> Why the heck is the EPEL page embedded or copypasted into the Development/Schedule page?
17:12:46 <Kevin_Kofler> It has nothing to do with scheduling.
17:13:02 <jds2001> Kevin_Kofler: i dunno :)
17:13:13 <Kevin_Kofler> I can clean up the page, there won't be much left though. ;-)
17:13:24 <nirik> Kevin_Kofler: looks like a cut and paste error. ;(
17:13:28 <Kevin_Kofler> Mostly just one or more links to Trac.
17:14:25 <Kevin_Kofler> Hmmm, indeed, it should probably be embedding EPEL/Schedule.
17:14:26 <jds2001> my trac plugin package review got approved, I'm just waiting for CVS on it.
17:14:27 * dgilmore is kinda here
17:14:28 <Kevin_Kofler> Not the main EPEL page.
17:14:55 <nirik> Kevin_Kofler: not sure why it would have any epel content there...
17:14:59 <jds2001> and then I can get it into infra, and enable it for our instance.
17:15:05 * nirik will run the cvs queue after this meeting.
17:15:30 <Kevin_Kofler> OK, well, let's do some proposals for cleanup and try to do fast votes?
17:15:56 <Kevin_Kofler> Proposal 1: delete EPEL section (embedding of EPEL page) from Development/Schedule
17:16:09 <Kevin_Kofler> +1
17:16:11 * jds2001 is in favor of just delegating to someone and letting them do what they see fit :)
17:16:13 <nirik> sounds fine. just do it.
17:16:28 <jds2001> it is after all a wiki :)
17:16:53 <Kevin_Kofler> Well, then I'll take care of the page if it's fine with everyone.
17:17:01 <jds2001> sure thing
17:17:07 <nirik> fine with me. ;)
17:17:16 <notting> go for it
17:17:19 <jds2001> I'll go through and see what can be done to make it more cohesive, too.
17:17:28 <jds2001> The whole structure, etc
17:17:38 <Kevin_Kofler> The EPEL content is a redirect from the obsolete Extras/Schedule/EnterpriseExtras page.
17:17:49 <Kevin_Kofler> That's how it happened.
17:18:14 <nirik> I think naming the subpages in a good way, and making subcategories for policy/suggestions/howtos would help a lot.
17:18:23 <Kevin_Kofler> There are a few obsolete and blank/nonexistent Extras/Schedule/* pages it's trying to embed too.
17:18:40 <jds2001> #action Kevin_Kofler will clean up the schedule page
17:18:51 <jds2001> #action jds2001 will look at it as well
17:19:11 <jds2001> next!
17:19:22 <jds2001> #topic Fedora packages as canonical upstreams
17:19:28 <jds2001> .fesco 210
17:19:59 * jds2001 sees no additional information
17:20:02 <jds2001> defer again?
17:20:17 * abadger1999 notes that although I tried to clarify things on the mailing list, I'm not for or against it.
17:20:19 <jds2001> irc there was a mailing list thread, though
17:20:21 <nirik> yeah, no more info from mether except the thread on devel list.
17:20:39 <nirik> if this is just to remove that exception from that one guideline it should say so.
17:20:41 <abadger1999> jds2001: What do you need to know?  Maybe I can fill in blanks
17:20:57 <jds2001> i guess what's the problem space?
17:21:04 <jds2001> why doesnt this work now?
17:21:19 <abadger1999> AFAIK from talking to mether, removing the exception from the guidelines is all that's wanted.
17:21:19 <dgilmore> i think tarballs are needed
17:21:20 <jds2001> what are we attempting to repair, and is it in need of repair? :)
17:21:36 <nirik> abadger1999: is it just asking to remove that guideline? or is it also asking to add stuff about requiring upstreams to have a "proper hosting infrastructure"
17:21:51 * jds2001 thought the latter
17:22:00 <notting> so, the only possible consequence is we have source tarballs for some packages that it is unclear of their origin (or they resolve to some place not publically available)
17:22:01 <notting> ?
17:22:02 <nirik> abadger1999: I would be for it if he would redo this to clarify that. The current proposal doesn't really say that.
17:22:23 <abadger1999> nirik: AFAIK, it does not require upstream to have a proper hosting infra.  However, if they do not have some sort of public place to get the source (outside of our lookaside) it won't pass review.
17:22:50 <abadger1999> source could equal tarball or version control, etc... anything already allowed to non-Fedora/Red Hat projects currently.
17:22:52 <nirik> abadger1999: thats currently the case for anything thats not using that exception, right?
17:23:03 <abadger1999> Correct.
17:23:16 <notting> abadger1999: "i just wrote this, the tarball is now sitting in my fedorapeople dir". is that acceptable for review?
17:23:19 <nirik> I would personally be fine with that.
17:23:33 <jds2001> what about pacakges where there is no source?
17:23:44 <nirik> notting: if thats the upstream location, i would say sure.
17:23:52 * jds2001 ran into another one last night, though not in the context of fedora
17:23:57 <abadger1999> notting: Good question.  Are you planning on continuing to host the tarballs for subsequent versions there?
17:24:01 <dgilmore> notting tjhatss ok
17:24:03 <jds2001> namely oracle-lib-compat from spacewalk
17:24:16 <nirik> jds2001: no source? everything is in the spec?
17:24:25 <jds2001> nirik: indeed
17:24:25 <notting> abadger1999: well, we're speaking in hypotheticals, here. 'maybe'?
17:24:39 <jds2001> it's a horrible hack, but will never be in Fedora :)
17:24:39 <abadger1999> notting: because, I think it satisfies the criteria.  But someone (like nirik's from source script) would be legitimately calling you out if the future tarballs didn't exist at some location later.
17:24:41 <nirik> jds2001: then it doesn't matter, because there is no Source* field, right?
17:24:43 <notting> abadger1999: but i think we can claim that the only case you'd hit this is self-written criteria
17:24:47 <notting> erm
17:24:48 <jds2001> nirik: correct
17:24:49 <notting> self-written software
17:25:27 <notting> so, slightly rephrasing it:
17:25:51 <nirik> we can't force upstream projects to always exist, always have a reachable hosting site where we can get code, etc.
17:26:05 <dgilmore> jds2001: it will never be in fedora
17:26:10 <jds2001> dgilmore: riht
17:26:19 <jds2001> dgilmore: but who says other things like it may not?
17:26:47 <notting> Proposal: "We are upstream" section should be removed from https://fedoraproject.org/wiki/Packaging:SourceURL. source should still be downloadable from somewhere.
17:26:56 <abadger1999> nirik: <nod> But for an upstream project that no longer has an upstream tarball, we'd say, this upstream seems to be dead, you need to either retire the package or get the latest ersion of the source and start hosting it somewhere.
17:27:02 <nirik> notting: +1 here. I assume thats what mether wanted...
17:27:12 <dgilmore> 389-ds has no source
17:27:18 <nirik> abadger1999: yep. I think thats fine... it's the best we can do.
17:27:19 <abadger1999> notting: Good rewrite.
17:27:53 <jds2001> dgilmore: that's the metapackage for 389?
17:28:12 <dgilmore> yep
17:28:13 * nirik waits for more votes so we can move on. ;)
17:28:33 <Kevin_Kofler> I still don't see why it's so important to have a tarball outside of the SRPM / the lookaside cache.
17:28:47 <Kevin_Kofler> I think it doesn't make sense to require it.
17:28:51 <Kevin_Kofler> So -1 to notting's proposal.
17:28:54 <nirik> Kevin_Kofler: I don't care about tarball... but I think the source should be available somehow.
17:29:02 <nirik> Kevin_Kofler: he didn't say tarball.
17:29:06 <Kevin_Kofler> The SRPM is "somehow".
17:29:06 * jds2001 is wondering about things that have no source, such as 389-ds
17:29:13 <Kevin_Kofler> As is the lookaside cache.
17:29:15 <nirik> jds2001: how does it work then?
17:29:23 <Kevin_Kofler> jds2001: Or kde-filesystem.
17:29:26 <nirik> Kevin_Kofler: example?
17:29:31 <abadger1999> I think i makes sense to have one outside of the SRPM.  outside of lookaside I'm not 100% on but it's cleaner to have less exceptions.
17:29:38 <Kevin_Kofler> Well, kde-filesystem actually has a source for the RPM macros.
17:29:50 <jds2001> nirik: it requires other things
17:29:50 <nirik> Kevin_Kofler: where do you store that?
17:29:51 <abadger1999> No source wouldn't be affected one way or another by this exception.
17:29:55 <jds2001> nirik: it's a metapackage
17:29:59 <Kevin_Kofler> But there are pure *-filesystem packages with no source file at all, just mkdir statements in the specfiles.
17:30:10 <nirik> jds2001: then it doesn't matter here. This only affects things with Source: urls
17:30:14 <abadger1999> So keeping or removing it won't affect 389-ds, kde-filesystem, etc.
17:30:30 <nirik> Kevin_Kofler: thats fine, they have no Source field. They don't matter here.
17:30:37 <Kevin_Kofler> The source for the macros in kde-filesystem? It's a trivial text file and it's stored within CVS (not even lookaside cache).
17:30:38 * abadger1999 checks what's in kde-filesystem
17:31:06 <nirik> Kevin_Kofler: cool. then that could be the source for it? I don't think thats a problem.
17:31:20 <Kevin_Kofler> Source1: teamnames <-- That's for i18n/l10n directories.
17:31:20 <Kevin_Kofler> Source2: macros.kde4 <-- The RPM macros.
17:31:26 <Kevin_Kofler> Both are text files checked into CVS.
17:31:42 <notting> text source: directly in SCM is fine with me. it's not like we have separate hosting for .desktop files
17:31:44 <Kevin_Kofler> teamnames is 1516 bytes, macros.kde4 887 bytes.
17:31:51 <abadger1999> Yeah, that looks fine.
17:33:04 <abadger1999> If someones says its a problem FPC would probably be better off making a better definition of what "source" means than to use the exception limited to Fedora/Red Hat projects.
17:33:16 <nirik> yeah, agreed.
17:33:44 <notting> but i would still vote +1 to the propsal, on a "fix this part, we can clarify more later if need be" basis
17:34:15 * jds2001 votes +1 to this proposal
17:34:19 <j-rod> +1
17:34:19 <nirik> yes, still +1 from me. I don't think we should have the exception any more
17:34:57 <skvidal> +1 to notting's suggestion
17:35:01 <Kevin_Kofler> I'm still -1, I don't see the benefits of removing the exception.
17:35:34 <jds2001> #agreed The Fedora packages as canonical upstream excepton is removed.
17:35:53 <jds2001> #topic feature submisson deadlin
17:35:53 * nirik notes there is nothing in the packaging guidelines that says source must be available.
17:35:58 <jds2001> .fesco 234
17:36:25 <jds2001> nirik: there is something that says no pre-built binaries
17:36:38 <jds2001> so i would assume that leads to source being available :)
17:37:13 <nirik> jds2001: sure, but it doesn't say source MUST be provided at an upstream site. The SourceURL guideline is how to point to it, but it doesn't say it has to exist...
17:38:07 <nirik> anyhow, sorry, move on.
17:38:21 * dgilmore is +1  i do think they should be a month after
17:38:43 <jds2001> a whole month?
17:38:46 <abadger1999> nirik: hmm... FPC can make that more explicit if you want.
17:39:25 <dgilmore> but we could accept nearly complete ones for 2 weeks after
17:39:56 <nirik> abadger1999: yeah, might be something to consider. The sourceurl page doesn't explicitly say that source MUST be available upstream somehow, just how to address various ways upstream might point to it.
17:40:01 <jds2001> and 100% complete for the remaining two weeks?
17:40:47 <jds2001> i.e. i forgot to write the feature page
17:40:49 <nirik> so what are we trying to solve here? the rush of features at the deadline where they have not landed yet?
17:41:02 <jds2001> nirik: yeah, i think so
17:41:07 <dgilmore> jds2001: no
17:41:08 <notting> well, the rush of features at the deadline
17:41:12 <dgilmore> defer
17:41:28 <jds2001> defer? why?
17:41:31 <nirik> I think this could lead to more 'the feature is done for the release, but I didn't know it would be in time/didn't make the deadline' so we don't advertize it as a feature even though it's done.
17:42:09 <dgilmore> they have alot of time to get a page together and in
17:42:38 <Kevin_Kofler> nirik: Right.
17:43:11 <Kevin_Kofler> It will also lead to developers promising stuff "just in case I can complete it" and us having to vote for a lot more features, just to drop them 2-4 weeks later as not even started.
17:43:15 <nirik> I guess I would be ok with 2 weeks as long as we granted exceptions in cases where they make sense.
17:43:44 <Kevin_Kofler> So -1 to this proposal, soft freezes just don't work.
17:44:48 <dgilmore> i never said soft
17:45:04 <dgilmore> 2 weeks hard
17:45:23 <dgilmore> 4 weeks if your not nearly done
17:45:43 <Kevin_Kofler> Soft freeze = you can work on features, but only if you submitted them first.
17:45:46 <jds2001> but we would need to make exceptions to that rules too?
17:46:20 <Kevin_Kofler> And that's basically what your proposal is, except that you can still work on features, but not advertise them as such (which is about the worst part of our feature process, this proposal doesn't help this issue).
17:46:52 <drago01> which can't be enforced anyway
17:46:53 <Kevin_Kofler> IMHO we should be able to advertise features at any time, even in updates.
17:47:15 <drago01> updates?
17:47:15 <Kevin_Kofler> drago01: Not being able to work on features can't be enforced, so that's how the problem happens.
17:47:28 <Kevin_Kofler> The only solution is to be more flexible for advertising features as well.
17:47:38 <Kevin_Kofler> drago01: Often interesting new features get backported to updates.
17:47:56 <Kevin_Kofler> Then they get advertised as "Fedora n features", but they have been in Fedora n-1 and possibly even n-2 months earlier.
17:47:59 <Kevin_Kofler> This makes no sense.
17:48:15 <Kevin_Kofler> We need a way to advertise features as being in updates.
17:48:16 <nirik> Kevin_Kofler: but our feature process is tied to releases... you want to announce some new F11 feature now?
17:48:27 <drago01> yeah but its not worth to advertise them months after the release
17:48:34 <drago01> where nobody really cares anymore
17:48:40 <Kevin_Kofler> nirik: More like ~2 weeks from now when KDE 4.3 hits. :-)
17:48:50 <Kevin_Kofler> But it's not the only such feature.
17:49:01 <Kevin_Kofler> Graphics driver hardware support improvements have also occasionally been backported.
17:49:12 <Kevin_Kofler> E.g. 3D for r5xx cards, IIRC in F9 updates.
17:49:14 <nirik> sure, but thats not a feature by our current process.
17:49:30 <jds2001> a lot of the reasoning for the feature process is in order to prepare the press for what's coming in that release.
17:49:34 <nirik> features == things in the current release that are there at release time.
17:50:49 <nirik> poelcat: you around? want to weigh in here as you commented in the ticket.
17:51:53 <nirik> Kevin_Kofler: I think it might be nice to have some standard way of noting big updates... ie, fedora-announce, some kind of "press release", etc. But I think thats outside the scope of our feature process.
17:52:06 * poelcat reads backscroll
17:52:15 <jds2001> well i know that kde4.3 is coming to F10/11
17:52:26 <jds2001> they've done a decent job of advertising that
17:52:37 <nirik> yeah, and it would be good to shout that out in some standard/official way.
17:52:38 <jds2001> though i think the only way that i know is rex's mail to f-d-a
17:53:09 <poelcat> my question is why this was such a "crisis" for FESCo for F12? :)
17:53:13 <Kevin_Kofler> FYI, it's too early to announce it to end users now, it should wait until the official update.
17:53:20 <poelcat> all the releases have been this way and things have turned out fine
17:53:41 <nirik> poelcat: yeah. I think we got several more 'please give us more time, it's about to be done' than the last few cycles...
17:53:46 <nirik> but there are always some of those.
17:53:47 <Kevin_Kofler> (i.e. stable, not just testing, where it's queued for now)
17:54:23 * poelcat thinks the issue of "features" in "updates" is a separate issue clouding this discussion
17:54:36 <Kevin_Kofler> As for the "please give us more time", I think this has everything to do with the removal of the old Alpha release and the rename of Beta to Alpha.
17:54:49 <Kevin_Kofler> It may be a problem of habit, i.e. that we aren't used to this.
17:54:59 <nirik> poelcat: totally agreed there.
17:55:10 <Kevin_Kofler> Or it may be that the old Alpha milestone, while mostly useless, served as a warning to get things done soon.
17:55:16 <poelcat> and a bigger discussion about increased process complexity, etc.
17:55:56 <poelcat> so if you're asking me if I think a feature filing deadline two weeks before FF is okay... I don't see any serious downsides
17:56:41 <poelcat> just getting the word out and my email nags that everyone seems to live to see ;-)
17:57:00 <poelcat> that is all from me
17:57:44 <jds2001> poelcat: i think the propsal was a month
17:58:00 <poelcat> jds2001: i thought someone counter-proposed 2 weeks
17:58:08 <jwb> notting did
17:58:12 <jwb> and i agreed with notting
17:58:15 <jds2001> poelcat: and we'll accept 90%+ (or whatever) unitl 2 weeks
17:58:38 * jwb is only like 10% here.  apologies
17:58:48 <jds2001> jwb: np
17:59:05 <j-rod> I like the 2 week idea myself. 4 seems a bit much.
17:59:23 <poelcat> i think managing to exact percentages is going to be more problems than it is worth... i'd recommend starting with two weeks... all filed and see what happens
17:59:38 <jds2001> sounds good
17:59:56 * j-rod only here like maybe 11%...
17:59:59 <poelcat> if we want to rework the process and details of it we should probably draw up a proposal and have a meeting about it vs. trying engineer it all here now
18:00:07 <jds2001> let's change the proposal to a 2 week deadline....all in favor?
18:00:19 <poelcat> where "process and details" == percentages, etc.
18:00:35 * Kevin_Kofler is still against the proposal, seeing more drawbacks than benefits.
18:00:36 <jds2001> and how does one define a percentage?
18:01:16 <notting> jds2001: "a ratio between 0 and 1, multiplied by 100"
18:01:18 <Kevin_Kofler> (drawbacks as already discussed: "just in case" filing of bogus/unimplementable features, features missing the filing deadline but going in)
18:01:25 <jds2001> notting: :D
18:02:02 <Kevin_Kofler> In the case of features, it's more like "a random number between 0 and 100".
18:02:10 <Kevin_Kofler> It isn't even always monotonically increasing over time.
18:02:20 <dgilmore> sorry network dropped out
18:03:34 * poelcat disappears
18:04:13 <jds2001> anyhow
18:04:17 <dgilmore> i think that it needs to be no less than 2 weeks
18:04:38 * nirik would be ok trying 2 weeks for the next cycle and adjusting. I don't think it's going to change much though.
18:05:17 <dgilmore> im ok with that
18:05:21 <jds2001> +1 to two weeks
18:06:08 <Kevin_Kofler> My counterproposal: move the feature submission deadline to at least 2 weeks AFTER the feature freeze. Rationale: the features we document should reflect the features which actually got implemented. The best moment to know that is after the freeze.
18:07:13 <jds2001> -1, that's just silly
18:07:25 <nirik> I guess that depends on if we expect maintainers to write up their proposal after they have done their implementation or before...
18:07:28 <dgilmore> Kevin_Kofler: -1 seriously
18:07:39 <dgilmore> nirik: before
18:07:39 <nirik> I think before makes a lot more sense.
18:07:48 <j-rod> +1 for 2 weeks before
18:08:02 <skvidal> +1 for 2 weeks before, as well
18:08:13 <dgilmore> nirik:  and before people can help complete them
18:08:20 <skvidal> -1 for writing it up after
18:08:40 <dgilmore> +1 for 2 weeks before
18:08:46 <nirik> it's a lot more open and community orented. ;)
18:08:57 * notting is +1 to two weeks before, -1 to two weeks later
18:09:23 <jds2001> #agreed feature submission deadline will be moved to two weeks prior to feature freeze for F13
18:09:42 <jds2001> #topic upstrem release monitoring
18:09:55 <jds2001> .fesco 239
18:10:09 <jds2001> im not sure technically how this could conceivably function
18:10:30 <skvidal> I think it'll just create bugspam
18:10:34 <jds2001> the current manual system i can easily see how it functions
18:11:00 <notting> i believe tyll is on another channel, if he wants to join
18:11:05 <dgilmore> -1 i think this will just create noise
18:11:06 <jds2001> im all for trying it and putting it up on a webpage or somesuch
18:11:14 <nirik> I think this could be usefull, but not in bugzilla...
18:11:21 <nirik> webpage + emails perhaps.
18:11:42 <Kevin_Kofler> I think the idea is that somebody will enter the URLs for all packages whose maintainer(s) do(es)n't opt out by hand.
18:11:45 <drago01_> well there are reasons why someone does _not_ want to update to lastest upstream
18:11:48 <Kevin_Kofler> I don't see how it would work otherwise.
18:12:14 <Kevin_Kofler> I'm a bit worried about bad regexes getting entered, leading to false positives (e.g. unstable/development releases).
18:12:26 <j-rod> I'm going to go with "how 'bout no?" on this one.
18:12:49 <Kevin_Kofler> But in principle, I think monitoring by default is a good idea if done properly.
18:12:50 <drago01_> getting spamed "update to foo" would be just annoying
18:13:16 <Kevin_Kofler> drago01_: I assume the system is smart enough not to annoy you again with the same version if you close it once as NOTABUG.
18:13:18 <j-rod> as a packager, I'm on the upstream mailing lists for all the packages I maintain
18:13:22 <Kevin_Kofler> If it's not, it's really broken.
18:13:22 <j-rod> that's enough, thank you
18:13:54 <nirik> I think it's usefull in some cases, but it needs to be hashed out more... and perhaps opt-in would make more sense.
18:13:59 <j-rod> (though not all projects have one)
18:14:12 <j-rod> opt-in is more reasonable than opt-out
18:14:18 <Kevin_Kofler> nirik: opt-in is what we currently have.
18:14:27 <Kevin_Kofler> https://fedoraproject.org/wiki/Upstream_Release_Monitoring
18:14:27 <nirik> yeah
18:14:33 <jds2001> right, and regexes are manually entered
18:14:35 <jds2001> which is fine
18:14:46 <Kevin_Kofler> AIUI, the proposal is to have someone enter regexes for the packages which don't have any.
18:14:51 <jds2001> they have the manpower to expand that to all packages?
18:16:02 <nirik> I think they don't realize what a job that will be if they think they do. ;)
18:17:00 * jds2001 counts only 621 packages currently monitored
18:17:05 <jds2001> less than 10% coverage
18:17:55 <jds2001> anyhow, -1 to opt-out, +1 to opt-in
18:18:17 <notting> similar here. -1 to opt-out, +1 to opt-in
18:19:15 <nirik> yeah, ditto. Would be nice to use a website/email process instead of bugzilla as well.
18:19:17 <j-rod> -1 opt-out, +1 opt-in
18:19:34 <Kevin_Kofler> +1 to opt-out, 0 to opt-in (also because I don't see why that'd need our approval at all)
18:20:16 * nirik gets confused... checks to see if he voted as he intended.
18:20:32 <jds2001> im interested to know why you are in favor of an opt-out system?
18:20:42 <dgilmore> -1 to opt out
18:20:58 <Kevin_Kofler> jds2001: Because that way lazy packagers would get told to upgrade their package by default.
18:21:12 <Kevin_Kofler> Whereas those who have good reasons not to can opt out and/or close the bugs as NOTABUG.
18:21:24 <nirik> shouldn't they anyhow when a user wants a newer version for a specific reason?
18:21:24 <jds2001> Kevin_Kofler: said lazy packager would just opt out
18:21:46 <Kevin_Kofler> I'm thinking of the packager(s) too lazy to opt in or out.
18:21:57 <jwb> i wasn't aware laziness was a trait we wanted to promote in Fedora
18:21:58 <nirik> they would likely just pile up 'please update' bugs.
18:22:15 <Kevin_Kofler> I'm thinking there must be significant overlap with the packagers who are too lazy to upgrade their packages.
18:22:43 <skvidal> -1 to opt out
18:22:52 <jds2001> if there's something new that folks want, I'll upgrade my packages.
18:22:57 <jwb> anyway, i already expressed much of my opinion in the ticket.  i like the service, but i don't want it to be opt-out
18:23:03 <jwb> so -1 to opt-out
18:23:04 <jds2001> but upgrading just to upgrade is silly.
18:23:14 <Kevin_Kofler> nirik: We could have the system auto-start the NRM/AWOL/MIA process.
18:23:34 <nirik> Kevin_Kofler: I think that would be hard to automate.
18:23:35 * jds2001 thinks that's an even worse idea.
18:23:44 <Kevin_Kofler> We'd catch lazy maintainers automatically that way.
18:24:14 * nirik thinks we are drifting off topic.
18:24:45 <jds2001> yeah, we have a boatload of features to consider.
18:25:38 <jds2001> #agreed Opt-out new package notification is not allowed, opt-in is fine
18:26:05 <jds2001> #topic Drop non-testable features
18:26:39 <jds2001> so I haven't had a chance to follow the thread-o-doom
18:26:45 <jds2001> ,fesco 240
18:26:51 <jds2001> .fesco 240
18:26:56 <nirik> lets just go thru them case by case?
18:27:04 <jds2001> yeah
18:27:23 <jds2001> DisplayPort?
18:28:13 <Kevin_Kofler> Was updated this week, should be testable at least with intel according to the status, -1 to dropping.
18:28:23 <jds2001> btw, since i havent had a chance to read the thread in it's entirety, I'm not 100% sure I'm qualified to vote on these since I've not seen potential feedback from owners.
18:28:27 * notting brings up the portion of the thread that doesn't involve arguing over someone's review skill
18:28:57 <Kevin_Kofler> Well, just follow the link and throw a quick glance of the linked feature pages, you'll get an opinion fairly quickly.
18:29:25 <Kevin_Kofler> For DisplayPort, IIRC ajax said it's basically done, though some bugs are left.
18:29:28 <nirik> yeah, -1 to dropping at this point...
18:29:44 <jds2001> ok, -1 to dropping
18:29:53 <j-rod> -1
18:29:57 <Kevin_Kofler> If only Intel gets done, we should rescope the feature as Intel-only.
18:30:00 <notting> -1 to dropping for now. although if it's not going to get much better, it probably needs reworked
18:30:19 <skvidal> that looks like 5
18:30:23 <skvidal> -1's that is
18:30:32 <nirik> next
18:30:33 <jds2001> #agreed DisplayPort feature is not dropped
18:30:36 <jds2001> FedoraStudio?
18:30:52 <jds2001> -1 to dropping, looks like it got updated today
18:30:59 <jds2001> and is mostly there
18:31:29 <nirik> yeah, -1 to drop here as well.
18:31:34 <notting> -1
18:31:37 <j-rod> -1
18:31:56 <Kevin_Kofler> Same here, -1 to dropping.
18:32:02 <skvidal> -1
18:32:08 <jds2001> #agreed FedoraStuido feature is not dropped
18:32:17 <jds2001> GFS2 clustered samba?
18:32:37 <jds2001> looks like some general GFS stability issues, looks like it's in testing and bugfixing
18:32:47 <Kevin_Kofler> Updates yesterday, 90% complete, -1 to dropping.
18:32:55 <jds2001> -1 to dropping
18:33:05 <skvidal> -1
18:33:08 <notting> -1
18:33:12 <nirik> -1 (so negative we are today)
18:33:23 <jds2001> #agreed GFS2 Clustered Samba feature is not dropped
18:33:30 <jds2001> #agreed GFS2 Clustered Samba feature is not dropped
18:33:33 <jds2001> oops
18:33:36 <jds2001> Gnome 2.28?
18:33:41 <j-rod> -1
18:33:44 <notting> -1, because, well....
18:33:53 <jds2001> -1....
18:33:56 <notting> what's there is certainly testable.
18:34:15 <Kevin_Kofler> -1 to dropping, it's clearly being implemented for F12 and a prerelease is already in.
18:34:23 <nirik> yeah, agreed.
18:34:28 <jds2001> #agreed Gnome 2.28 feature is not dropped
18:34:42 <jds2001> LowerProcessCapabilities?
18:35:06 <Kevin_Kofler> Hmmm, is the owner around?
18:35:15 <nirik> I don't see this as having landed/testable.
18:35:17 <jds2001> this one doesnt look to have been updated and is rather worrisome at 20%
18:35:22 <Kevin_Kofler> This hasn't been updated for almost a month and it says 20%.
18:35:32 <notting> as it stands, i'm +1 to dropping - it's not been updated, and it does not appear to have landed in any way
18:35:40 <skvidal> +1
18:35:42 <jds2001> +1
18:35:47 <nirik> yep. +1 to drop and try again for next cycle.
18:36:16 <Kevin_Kofler> libcap-ng is in Rawhide.
18:36:20 <notting> (and it's the sort of thing that looks complex to land totally)
18:36:22 <Kevin_Kofler> Package last updated 12 days ago.
18:36:36 <Kevin_Kofler> Whether anything actually uses it, I have no idea.
18:36:45 <j-rod> +1 to defer it
18:36:47 <jds2001> #agreed Lower Process Capabilties feature is dropped for F12
18:36:57 <jds2001> FedoraMoblin?
18:37:23 <skvidal> looks like it has the headway necessary -1 to dropping it
18:37:36 <Kevin_Kofler> sgrubb: So here you are. Any updates for LowerProcessCapabilities?
18:37:53 <sgrubb> been working on dhcp requirements
18:37:54 <j-rod> I've noticed a number of new moblin packages landing
18:37:59 <jds2001> how are those two outstanding package reviews looking?
18:38:05 <nirik> new packages are landing, but it's not been added as a spin...
18:38:15 <sgrubb> chatted with the maintainer on that to understand how to tackle that onbe
18:38:18 <Kevin_Kofler> Hmmm, we're discussion 2 features at once now.
18:38:30 <Kevin_Kofler> I pinged sgrubb so he could give an update on LowerProcessCapabilities.
18:38:40 <sgrubb> got patch in for irqbalance and I think one other
18:38:50 * nirik nods. Lets go back to sgrubb's feature.
18:39:02 <sgrubb> My priority for the last 2 weeks had to be getting audit-2.0 package ready
18:39:06 <Kevin_Kofler> Can you please update the feature page at https://fedoraproject.org/wiki/Features/LowerProcessCapabilities ?
18:39:15 <Kevin_Kofler> Right now this is at 20% and not updated for almost a month.
18:39:17 <sgrubb> its now blocked on package review for sc-audit
18:39:32 <jds2001> is audit-2.0 somehow related to this?
18:39:38 <jds2001> or is that something else?
18:39:52 <sgrubb> it takes my time so that I cannot work on LowerProcessCapabilities
18:40:32 <jds2001> ok, fair enough
18:41:04 <jds2001> so are you OK if we defer this to F13 since you didn't have time?
18:41:38 <sgrubb> no, I'm not. :)
18:41:55 <sgrubb> I am about done audit 2.0
18:42:27 * skvidal reiterates his -1 - this is not done and it is too late now
18:42:43 <Kevin_Kofler> You mean your +1 to dropping the feature?
18:43:05 <skvidal> yes, I did
18:43:32 * skvidal got the -1/+1 backward again
18:43:34 <skvidal> +1 for dropping
18:43:56 <Kevin_Kofler> I'm -1 to dropping it now, it looks like some work got done already which is worth mentioning on its own, and more is to come.
18:44:33 <nirik> but should we be making these kind of changes after freeze?
18:44:35 <Kevin_Kofler> I think we should give sgrubb a chance to update the page and continue his work and revisit the feature later.
18:44:58 <sgrubb> alpha freeze?
18:45:03 <jds2001> we're now into "fix bugs stage"
18:45:11 <jds2001> sgrubb: alpha is the new beta
18:45:27 <jds2001> sgrubb: there's been confusion about that, and that's fair.
18:45:58 <nirik> I think it would be better to get everything ready for this and land it early in the next cycle...
18:46:12 <jds2001> we dropped the alpha milestone we've had in previous releases, and are now calling what used to be beta alpha
18:46:23 <notting> but the feature freeze is still at the same relative point of the release
18:46:29 <Kevin_Kofler> jds2001: And I think that was a mistake.
18:46:44 <Kevin_Kofler> I think pretty much all our issues with stuff not being ready are due to that.
18:46:56 <sgrubb> so from Fesco approval to freeze is 2-3 weeks...is that fair?
18:47:48 <jds2001> sgrubb: there's a separate proposal that was approved earlier in the meeting to move feature submission to two weeks prior to feature freeze
18:48:04 <jds2001> as of now, you could propose a feature on the day of feature freeze.
18:48:36 <jds2001> and have it accepted
18:49:04 <jds2001> so hopefully that addresses that concern.  Late for now, I know.
18:49:30 <sgrubb> I created the Feature Page June 23 and it was not approved until July26
18:49:44 <sgrubb> I lost a lot of time waiting to get the go ahead on this
18:49:54 <notting> it was not submitted to fesco until july 23
18:50:10 <notting> (we can't approve what we don't see)
18:50:20 <nirik> sgrubb: whats left to land before this would be testable?
18:50:56 <sgrubb> well, its kind of testable right now, its just not finished
18:51:03 <sgrubb> run netcap
18:51:04 <nirik> permissions changes in the base packages?
18:51:37 <sgrubb> I spoke with shadow-utils maintainer he told me to see setup package maintainer
18:52:06 <sgrubb> that was my next step for getting perms a little tighter
18:52:29 <sgrubb> but based on conversation on the mail list, looks like I can't do full permission change I originallyy proposed
18:52:38 <sgrubb> so I am scaling that bit back
18:53:11 <sgrubb> do shadow and gshaow is simple to fix
18:53:43 <sgrubb> taking root's write away from /bin /sbin /lib is also doable
18:54:15 <sgrubb> but the other dirs I don't this I can touch without some thinking about it. So I don't want to do those at this point
18:54:39 <skvidal> sgrubb: taking root's write away from /bin and /sbin?
18:54:49 <sgrubb> yeah, 0555 perms
18:54:50 <skvidal> sgrubb: and what does that do for rpm?
18:55:05 <sgrubb> nothing, the admin has DAC_OVERRIDE
18:55:16 <Kevin_Kofler> Read the feature page, root is allowed to write into stuff with no write permissions (even now).
18:55:32 <Kevin_Kofler> What's going to change is that daemons will run as root but with that capability explicitly dropped.
18:55:36 <nirik> so how soon would this realistically land? the next few days?
18:55:44 <notting> Kevin_Kofler: only patched daemons, correct?
18:55:51 <Kevin_Kofler> Correct.
18:55:54 <sgrubb> yes
18:56:01 <Kevin_Kofler> They need to explicitly drop the capability.
18:56:22 <sgrubb> also...the current daemons that do drop capabilities all have a security hole in them
18:56:35 <sgrubb> dbud dnsmasq  for example
18:56:39 <sgrubb> dbus that is
18:56:51 * nirik still wonders if it wouldn't be better to just work on this now and land it first thing after the next cycle branch...
18:57:24 <sgrubb> not all of this has to land now, it can be done in pieces
18:57:25 <nirik> so that way more could be done, and it would get testing and not disrupt this shorter release cycle.
18:58:16 <nirik> sgrubb: could you then update the feature page with what could realistically be done now? and move the rest to another page for next cycle?
18:58:32 <sgrubb> sure, no problem with that
18:58:52 <notting> esp. given that it looks like only libcap-ng is going to make the alpha, no users of it
18:58:54 <nirik> I'd be ok with that... but thats just me. ;) I guess we need to vote?
18:59:27 <jds2001> +1 to new scope
19:00:05 <Kevin_Kofler> +1 to new scope as well
19:00:59 <jds2001> is anyone else still with us? :)
19:01:11 * skvidal is and is mulling things
19:01:26 <skvidal> fine +1 to new scope
19:02:07 <notting> +1 to reduced scope (still obviously needs to land before beta)
19:02:38 <nirik> thanks for dropping and providing us info sgrubb. :)
19:02:40 <jds2001> #agreed LowerProcessCapabilities feature with reduced scope is not dropped.
19:03:07 * jds2001 notes we're out of tmie
19:03:21 <jds2001> i'd like to get through the rest of these though
19:03:30 <jds2001> everyone cool with that?
19:03:40 <Kevin_Kofler> Yeah, let's continue.
19:04:08 <jds2001> alright, 6 more
19:04:10 * nirik nods.
19:04:19 <jds2001> FedoraMoblin
19:04:36 <nirik> great work being done there, but it needs updating/reduced scope too, or defering until next cycle.
19:04:52 <nirik> the spin has not been submitted to the spins sig, so no way that will make it this cycle.
19:05:12 <jds2001> ok, so let's drop this for this cycle
19:05:20 <Kevin_Kofler> Uhm, yeah, we approved it contingent on that, so technically the approval is already no longer valid.
19:05:26 <jds2001> +1 to dropping
19:05:36 <Kevin_Kofler> The packages are almost all in (only 2 missing), but the spin is not. :-/
19:05:38 * nirik nods. drop to next cycle.
19:05:41 <Kevin_Kofler> Why haven't they submitted the spin?
19:05:46 <j-rod> +1, per what Kevin_Kofler said
19:05:47 <nirik> don't know.
19:06:09 <notting> +1 to dropping if the spin isn't there yet. plus, their blocker bug shows 9 open reviews
19:06:39 <jds2001> #agreed Fedora Moblin is deferred to F13.
19:06:46 <jds2001> NetBeans 6.7?
19:07:37 <jds2001> looks to have have been updated
19:08:01 <Kevin_Kofler> Yeah, 70% complete, not testable yet as deps are still missing. :-(
19:08:06 <notting> the page, yes. the packages, no
19:08:12 <Kevin_Kofler> So where do we go from there?
19:08:14 <jds2001> there's a review there that still needs a reviewer
19:08:16 <nirik> yeah, still lacking some packages that haven't been reviewed.
19:08:24 <jds2001> +1 to dropping
19:09:08 <tibbs> The queue was spammed quite a bit with moblin-related packages.
19:09:13 <j-rod> +1, spill the beans next release
19:09:14 <skvidal> +1 to dropping
19:09:18 <skvidal> j-rod: booo
19:09:22 <j-rod> :D
19:09:41 <tibbs> Someone should tell the reviewers if there are packages which need reviews in order for features to progress.
19:10:20 <victorv> FYI netbeans-platform pkg is 100% ready to test, but it is not in CVS due to https://bugzilla.redhat.com/show_bug.cgi?id=510255
19:10:22 <buggbot> Bug 510255: medium, medium, ---, nobody, NEW, Review Request: cobertura - a Java tool for calculating the test coverage
19:10:46 <j-rod> perhaps a keyword should be added to review requests that block features?
19:10:50 <jds2001> victorv: there's been no activity on that review
19:11:28 <Kevin_Kofler> Can we find a reviewer for that and then revisit?
19:11:43 <nirik> victorv: is that the last thing blocking it being testable?
19:11:47 <tibbs> I get the impression that folks think that reviewers just come out of the aether.
19:12:14 <jds2001> tibbs: they don't? :D
19:12:18 <notting> tibbs: right, that's why we put the packages on the aethernet
19:12:35 * nirik groans.
19:13:21 <nirik> I don't know java packaging too well, but I can take a stab at reviewing it.
19:13:27 <tibbs> Anyway, my point is that if someone wants to collect a list of review tickets that are holding up features then we could perhaps try to address them.
19:13:28 <victorv> nirik: the last thing is the netbeans pkg that is in progress right now
19:13:39 <notting> so, hrm. it's not part of the default package set, so i'd be willing to give a little leeway
19:13:55 <nirik> victorv: yeah, but that needs this new package first?
19:14:02 <jds2001> yeah, especailly since that review has been lingering
19:14:11 <tibbs> Or if the submitters want to actually indicate somehow that individual tickets are needed for features to progress, that would help as well.
19:14:16 <jds2001> not victorv's fault
19:14:25 <tibbs> But just assuming they're going to get done is not going to work in general.
19:14:33 <jds2001> tibbs: that's noted on the feature page in question
19:14:40 <tibbs> That goes the wrong way.
19:14:52 <nirik> we could ask feature owners to add a 'neededforfeature' keyword or something.
19:14:54 <tibbs> A reviewer isn't going to read the feature page; they're going to look at the review ticket.
19:15:17 <nirik> anyhow, I am willing to review this package, can we vote on leaving this feature based on it getting testable asap?
19:15:40 <jds2001> sure, +1 to leaving it
19:15:56 <Kevin_Kofler> leave +1, drop -1
19:15:57 <victorv> nirik: netbeans pkg is already in Fedora. Need to be updated.
19:16:01 <j-rod> I'm fine with defer to next week
19:16:08 <nirik> victorv: right.
19:17:02 <nirik> +1 leaving for now.
19:17:05 <j-rod> +1 for leaving it in, if the bits are actually testable by next friday
19:17:23 <notting> +1
19:17:24 <skvidal> +1 leaving for now
19:17:42 <jds2001> #agreed NetBeans feature is not dropped, pending package review
19:17:59 <jds2001> NFSv4 default?
19:18:12 <Kevin_Kofler> steved: So what's the current status?
19:18:20 <Kevin_Kofler> The feature page was last updated on July 15.
19:18:24 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/NFSv4Default
19:18:33 <jds2001> no
19:18:39 <jds2001> it was last updated today
19:18:49 <steved> all the kernel parts are in place... I have a configuration file posted upstream...
19:18:51 <jds2001> (cur) (prev)  11:52, 7 August 2009 Steved (Talk | contribs) (3,167 bytes)
19:19:00 <notting> ok, then -1 to dropping it
19:19:03 <steved> all thats left is to change the mount command
19:19:13 <nirik> -1 to dropping. Land as soon as you can.
19:19:16 <jds2001> -1 to dropping
19:19:29 <steved> is -1 good ? :)
19:19:34 <Kevin_Kofler> jds2001: Then he needs to fix the Last updated date.
19:19:38 <nirik> steved: yeah, in this case. ;)
19:19:39 <Kevin_Kofler> -1 to dropping.
19:19:42 <jds2001> steved: it is. :)
19:19:47 <steved> good!
19:19:55 * steved is working as hard as possible..
19:19:58 <Kevin_Kofler> But please keep in mind that the Last updated: date needs updating, too, when you edit things. :-)
19:20:11 <steved> will do... thanks!
19:20:15 <jds2001> #agreed NFSv4 feature is not dropped
19:20:17 <j-rod> -1, keep it
19:20:40 <jds2001> Raduko Perl 6?
19:20:43 <nirik> -1 to dropping, it's done and landed now and should be testable. (aside from a ppc bug that they are working hard on)
19:20:48 <Kevin_Kofler> -1 to dropping, it's already complete.
19:20:52 <jds2001> it seems to have landed.
19:20:58 <jds2001> -1 to dropping
19:21:06 <notting> yeah, -1.
19:21:08 <jds2001> Kevin_Kofler: not quite complete
19:21:14 <jds2001> Kevin_Kofler: a ppc bug remains
19:21:32 <nirik> one more so we cna move on?
19:21:58 <Kevin_Kofler> 2 more actually.
19:22:26 <nirik> I see 4 -1's... one more would be passing?
19:22:30 <jds2001> #agreed Raduko perl 6 feature is not dropped
19:22:36 <jds2001> oops
19:22:49 <nirik> j-rod: ?
19:23:00 <Kevin_Kofler> nirik: Oh, I thought you were talking about the remaining features (we have 2 more to go).
19:23:22 <j-rod> sorry
19:23:23 <nirik> nope, was talking votes. :( looks like we may have lost quorum.
19:23:32 <j-rod> -1, keep raduko too
19:23:38 <jds2001> ok good
19:23:45 <nirik> next
19:23:46 <j-rod> rakudo, even
19:23:48 <jds2001> Thusnelda?
19:23:54 <jds2001> -1, keep it, it's landed
19:23:57 <Kevin_Kofler> -1 to dropping.
19:24:05 <Kevin_Kofler> Beta already in, worst case we can ship with that.
19:24:11 <nirik> yep. Keep it.
19:24:13 <Kevin_Kofler> And the final version is coming soon too.
19:24:22 <j-rod> -1 for drop, keep it in
19:24:35 <notting> right, -1 to dropping it
19:24:39 <nirik> cool. next?
19:24:48 <jds2001> #agreed Thusnelda feature is not dropped
19:25:02 <jds2001> YumLangPackPlguin?
19:25:12 <jds2001> the feature owner is reportedly on holiday
19:25:29 <jds2001> but even so, at 30% as of 7-24, this doesnt look good
19:25:51 <tibbs> I guess there's a review ticket on that one as well.
19:25:52 <nirik> I don't know how much of this has landed/is testable.
19:26:03 <tibbs> bug 512663
19:26:04 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=512663 medium, medium, ---, nobody, NEW, Review Request: langpack-support - Meta packages for Yum langpack support
19:26:09 <notting> -1, it hasn't landed
19:26:18 <notting> erm, +1 to drop, it hasn't landed
19:26:25 <nirik> yeah, I think dropping and punting to next cycle would be good.
19:26:29 <Kevin_Kofler> Is yum-plugin-langpacks anywhere?
19:26:35 <Kevin_Kofler> That's the code part.
19:26:41 <Kevin_Kofler> Without that, there's nothing in.
19:26:58 <j-rod> +1, next cycle
19:27:07 <jds2001> +1, next cycle
19:27:32 * jds2001 sees 3 votes
19:27:47 <jds2001> well, 4
19:27:54 <jds2001> if i count nirik's :)
19:28:03 <nirik> yeah
19:28:25 <jds2001> Kevin_Kofler: ?
19:28:40 <Kevin_Kofler> drop +1, I don't see yum-langpack-plugin anywhere.
19:28:51 <Kevin_Kofler> And the metapackage is not reviewed yet either.
19:29:10 <jds2001> #agreed Yum langpack plugin feature is deferred to F13
19:29:16 <jds2001> That's it for features
19:29:21 <f13> ok, I think it's time for the nick change :/
19:29:33 <jds2001> one remaining item on the agenda
19:29:45 <jds2001> f13: was wondering when you'd do that :)
19:30:16 <jds2001> anyhow, there's one remaining item
19:30:22 <j-rod> I'm fine with deferring libvdpau discussion to next week, we're already a like 7 hours here
19:30:24 <jds2001> j-rod: it's not pressing, is it?
19:30:28 <jds2001> ok :)
19:30:34 <jds2001> that's what i was asking :)
19:30:40 <notting> hooray
19:30:49 <Kevin_Kofler> defer +1, I don't think we'll get a quorum either way now and we're 30 minutes over time
19:31:01 <jds2001> anything else have anything that's world-ending?
19:31:28 <jds2001> guess not
19:31:30 <jds2001> #endmeeting