Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.log.html --- 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
