17:00:19 #startmeeting FESCo meeting 2009-08-07 17:00:20 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:00:27 * nirik is here. 17:00:32 FergatROn: in #fedora-websites 17:00:40 Present. 17:00:46 jds2001: the meeting is on #fedora-websites channel? 17:00:47 odd 17:00:55 * skvidal is here 17:01:00 FergatROn: yeah, the websites meeting conflicts with FESCo 17:01:06 jds2001: thanks 17:02:18 * notting is here now 17:02:25 cool 17:02:35 shall we get started? 17:02:48 #topic MW Patch issue 17:02:54 .fesco 225 17:03:06 Kevin_Kofler: you have an update here? 17:03:19 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 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 that does no good if the maintainer doesnt apply your patch :( 17:04:54 shall we let ricky do that and revisit in a while? or ? 17:04:59 sure 17:05:26 #topic outdated wiki 17:05:30 .fesco 176 17:05:33 nirik: Sure. 17:05:41 so our wiki pages are in various states of fail. 17:05:50 Running late, sorry 17:06:16 notting wanted to appoint someone to JFDI :) 17:06:23 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 which seems reasonable 17:07:00 volunteers? 17:07:20 * jds2001 hears crickets 17:08:25 Finding the time is the big thing. ;( Perhaps some docs people would be willing to help out? 17:08:39 yeah, -ENOTIME here too :( 17:09:12 ianweller: you around? 17:09:26 Before appointing something to do the work, we should agree on what should be done. 17:09:26 or call for helpers on the devel list? 17:09:34 * jds2001 defers to the wiki czar 17:09:36 So the plan for the template page is to turn it into a Trac template? 17:09:48 That needs somebody with Trac admin privileges to handle. 17:09:49 Kevin_Kofler: i think that makes sense, I can do that 17:09:53 jds2001: sorta! 17:09:58 Then the wiki page can be removed. 17:10:13 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 For the schedule page, I think we should be linking to https://fedorahosted.org/fesco/report/9 17:10:42 ianweller: no, we're just saying that our pages are in a state of fail 17:10:47 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 ok 17:11:11 we're looking for some assistance to get them out of said state of fail :) 17:11:37 i'm usually around to answer questions in #fedora-docs (or even #fedora-devel) 17:12:42 alright, I'll put out a call for a proposal on what should be done 17:12:43 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 jds2001: we could just change them to say "ask jds2001 on irc if you need to know something" 17:12:46 Why the heck is the EPEL page embedded or copypasted into the Development/Schedule page? 17:12:46 It has nothing to do with scheduling. 17:13:02 Kevin_Kofler: i dunno :) 17:13:13 I can clean up the page, there won't be much left though. ;-) 17:13:24 Kevin_Kofler: looks like a cut and paste error. ;( 17:13:28 Mostly just one or more links to Trac. 17:14:25 Hmmm, indeed, it should probably be embedding EPEL/Schedule. 17:14:26 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 Not the main EPEL page. 17:14:55 Kevin_Kofler: not sure why it would have any epel content there... 17:14:59 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 OK, well, let's do some proposals for cleanup and try to do fast votes? 17:15:56 Proposal 1: delete EPEL section (embedding of EPEL page) from Development/Schedule 17:16:09 +1 17:16:11 * jds2001 is in favor of just delegating to someone and letting them do what they see fit :) 17:16:13 sounds fine. just do it. 17:16:28 it is after all a wiki :) 17:16:53 Well, then I'll take care of the page if it's fine with everyone. 17:17:01 sure thing 17:17:07 fine with me. ;) 17:17:16 go for it 17:17:19 I'll go through and see what can be done to make it more cohesive, too. 17:17:28 The whole structure, etc 17:17:38 The EPEL content is a redirect from the obsolete Extras/Schedule/EnterpriseExtras page. 17:17:49 That's how it happened. 17:18:14 I think naming the subpages in a good way, and making subcategories for policy/suggestions/howtos would help a lot. 17:18:23 There are a few obsolete and blank/nonexistent Extras/Schedule/* pages it's trying to embed too. 17:18:40 #action Kevin_Kofler will clean up the schedule page 17:18:51 #action jds2001 will look at it as well 17:19:11 next! 17:19:22 #topic Fedora packages as canonical upstreams 17:19:28 .fesco 210 17:19:59 * jds2001 sees no additional information 17:20:02 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 irc there was a mailing list thread, though 17:20:21 yeah, no more info from mether except the thread on devel list. 17:20:39 if this is just to remove that exception from that one guideline it should say so. 17:20:41 jds2001: What do you need to know? Maybe I can fill in blanks 17:20:57 i guess what's the problem space? 17:21:04 why doesnt this work now? 17:21:19 AFAIK from talking to mether, removing the exception from the guidelines is all that's wanted. 17:21:19 i think tarballs are needed 17:21:20 what are we attempting to repair, and is it in need of repair? :) 17:21:36 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 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 ? 17:22:02 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 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 source could equal tarball or version control, etc... anything already allowed to non-Fedora/Red Hat projects currently. 17:22:52 abadger1999: thats currently the case for anything thats not using that exception, right? 17:23:03 Correct. 17:23:16 abadger1999: "i just wrote this, the tarball is now sitting in my fedorapeople dir". is that acceptable for review? 17:23:19 I would personally be fine with that. 17:23:33 what about pacakges where there is no source? 17:23:44 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 notting: Good question. Are you planning on continuing to host the tarballs for subsequent versions there? 17:24:01 notting tjhatss ok 17:24:03 namely oracle-lib-compat from spacewalk 17:24:16 jds2001: no source? everything is in the spec? 17:24:25 nirik: indeed 17:24:25 abadger1999: well, we're speaking in hypotheticals, here. 'maybe'? 17:24:39 it's a horrible hack, but will never be in Fedora :) 17:24:39 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 jds2001: then it doesn't matter, because there is no Source* field, right? 17:24:43 abadger1999: but i think we can claim that the only case you'd hit this is self-written criteria 17:24:47 erm 17:24:48 nirik: correct 17:24:49 self-written software 17:25:27 so, slightly rephrasing it: 17:25:51 we can't force upstream projects to always exist, always have a reachable hosting site where we can get code, etc. 17:26:05 jds2001: it will never be in fedora 17:26:10 dgilmore: riht 17:26:19 dgilmore: but who says other things like it may not? 17:26:47 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 nirik: 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 notting: +1 here. I assume thats what mether wanted... 17:27:12 389-ds has no source 17:27:18 abadger1999: yep. I think thats fine... it's the best we can do. 17:27:19 notting: Good rewrite. 17:27:53 dgilmore: that's the metapackage for 389? 17:28:12 yep 17:28:13 * nirik waits for more votes so we can move on. ;) 17:28:33 I still don't see why it's so important to have a tarball outside of the SRPM / the lookaside cache. 17:28:47 I think it doesn't make sense to require it. 17:28:51 So -1 to notting's proposal. 17:28:54 Kevin_Kofler: I don't care about tarball... but I think the source should be available somehow. 17:29:02 Kevin_Kofler: he didn't say tarball. 17:29:06 The SRPM is "somehow". 17:29:06 * jds2001 is wondering about things that have no source, such as 389-ds 17:29:13 As is the lookaside cache. 17:29:15 jds2001: how does it work then? 17:29:23 jds2001: Or kde-filesystem. 17:29:26 Kevin_Kofler: example? 17:29:31 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 Well, kde-filesystem actually has a source for the RPM macros. 17:29:50 nirik: it requires other things 17:29:50 Kevin_Kofler: where do you store that? 17:29:51 No source wouldn't be affected one way or another by this exception. 17:29:55 nirik: it's a metapackage 17:29:59 But there are pure *-filesystem packages with no source file at all, just mkdir statements in the specfiles. 17:30:10 jds2001: then it doesn't matter here. This only affects things with Source: urls 17:30:14 So keeping or removing it won't affect 389-ds, kde-filesystem, etc. 17:30:30 Kevin_Kofler: thats fine, they have no Source field. They don't matter here. 17:30:37 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 Kevin_Kofler: cool. then that could be the source for it? I don't think thats a problem. 17:31:20 Source1: teamnames <-- That's for i18n/l10n directories. 17:31:20 Source2: macros.kde4 <-- The RPM macros. 17:31:26 Both are text files checked into CVS. 17:31:42 text source: directly in SCM is fine with me. it's not like we have separate hosting for .desktop files 17:31:44 teamnames is 1516 bytes, macros.kde4 887 bytes. 17:31:51 Yeah, that looks fine. 17:33:04 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 yeah, agreed. 17:33:44 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 +1 17:34:19 yes, still +1 from me. I don't think we should have the exception any more 17:34:57 +1 to notting's suggestion 17:35:01 I'm still -1, I don't see the benefits of removing the exception. 17:35:34 #agreed The Fedora packages as canonical upstream excepton is removed. 17:35:53 #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 .fesco 234 17:36:25 nirik: there is something that says no pre-built binaries 17:36:38 so i would assume that leads to source being available :) 17:37:13 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 anyhow, sorry, move on. 17:38:21 * dgilmore is +1 i do think they should be a month after 17:38:43 a whole month? 17:38:46 nirik: hmm... FPC can make that more explicit if you want. 17:39:25 but we could accept nearly complete ones for 2 weeks after 17:39:56 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 and 100% complete for the remaining two weeks? 17:40:47 i.e. i forgot to write the feature page 17:40:49 so what are we trying to solve here? the rush of features at the deadline where they have not landed yet? 17:41:02 nirik: yeah, i think so 17:41:07 jds2001: no 17:41:08 well, the rush of features at the deadline 17:41:12 defer 17:41:28 defer? why? 17:41:31 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 they have alot of time to get a page together and in 17:42:38 nirik: Right. 17:43:11 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 I guess I would be ok with 2 weeks as long as we granted exceptions in cases where they make sense. 17:43:44 So -1 to this proposal, soft freezes just don't work. 17:44:48 i never said soft 17:45:04 2 weeks hard 17:45:23 4 weeks if your not nearly done 17:45:43 Soft freeze = you can work on features, but only if you submitted them first. 17:45:46 but we would need to make exceptions to that rules too? 17:46:20 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 which can't be enforced anyway 17:46:53 IMHO we should be able to advertise features at any time, even in updates. 17:47:15 updates? 17:47:15 drago01: Not being able to work on features can't be enforced, so that's how the problem happens. 17:47:28 The only solution is to be more flexible for advertising features as well. 17:47:38 drago01: Often interesting new features get backported to updates. 17:47:56 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 This makes no sense. 17:48:15 We need a way to advertise features as being in updates. 17:48:16 Kevin_Kofler: but our feature process is tied to releases... you want to announce some new F11 feature now? 17:48:27 yeah but its not worth to advertise them months after the release 17:48:34 where nobody really cares anymore 17:48:40 nirik: More like ~2 weeks from now when KDE 4.3 hits. :-) 17:48:50 But it's not the only such feature. 17:49:01 Graphics driver hardware support improvements have also occasionally been backported. 17:49:12 E.g. 3D for r5xx cards, IIRC in F9 updates. 17:49:14 sure, but thats not a feature by our current process. 17:49:30 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 features == things in the current release that are there at release time. 17:50:49 poelcat: you around? want to weigh in here as you commented in the ticket. 17:51:53 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 well i know that kde4.3 is coming to F10/11 17:52:26 they've done a decent job of advertising that 17:52:37 yeah, and it would be good to shout that out in some standard/official way. 17:52:38 though i think the only way that i know is rex's mail to f-d-a 17:53:09 my question is why this was such a "crisis" for FESCo for F12? :) 17:53:13 FYI, it's too early to announce it to end users now, it should wait until the official update. 17:53:20 all the releases have been this way and things have turned out fine 17:53:41 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 but there are always some of those. 17:53:47 (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 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 It may be a problem of habit, i.e. that we aren't used to this. 17:54:59 poelcat: totally agreed there. 17:55:10 Or it may be that the old Alpha milestone, while mostly useless, served as a warning to get things done soon. 17:55:16 and a bigger discussion about increased process complexity, etc. 17:55:56 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 just getting the word out and my email nags that everyone seems to live to see ;-) 17:57:00 that is all from me 17:57:44 poelcat: i think the propsal was a month 17:58:00 jds2001: i thought someone counter-proposed 2 weeks 17:58:08 notting did 17:58:12 and i agreed with notting 17:58:15 poelcat: and we'll accept 90%+ (or whatever) unitl 2 weeks 17:58:38 * jwb is only like 10% here. apologies 17:58:48 jwb: np 17:59:05 I like the 2 week idea myself. 4 seems a bit much. 17:59:23 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 sounds good 17:59:56 * j-rod only here like maybe 11%... 17:59:59 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 let's change the proposal to a 2 week deadline....all in favor? 18:00:19 where "process and details" == percentages, etc. 18:00:35 * Kevin_Kofler is still against the proposal, seeing more drawbacks than benefits. 18:00:36 and how does one define a percentage? 18:01:16 jds2001: "a ratio between 0 and 1, multiplied by 100" 18:01:18 (drawbacks as already discussed: "just in case" filing of bogus/unimplementable features, features missing the filing deadline but going in) 18:01:25 notting: :D 18:02:02 In the case of features, it's more like "a random number between 0 and 100". 18:02:10 It isn't even always monotonically increasing over time. 18:02:20 sorry network dropped out 18:03:34 * poelcat disappears 18:04:13 anyhow 18:04:17 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 im ok with that 18:05:21 +1 to two weeks 18:06:08 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 -1, that's just silly 18:07:25 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 Kevin_Kofler: -1 seriously 18:07:39 nirik: before 18:07:39 I think before makes a lot more sense. 18:07:48 +1 for 2 weeks before 18:08:02 +1 for 2 weeks before, as well 18:08:13 nirik: and before people can help complete them 18:08:20 -1 for writing it up after 18:08:40 +1 for 2 weeks before 18:08:46 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 #agreed feature submission deadline will be moved to two weeks prior to feature freeze for F13 18:09:42 #topic upstrem release monitoring 18:09:55 .fesco 239 18:10:09 im not sure technically how this could conceivably function 18:10:30 I think it'll just create bugspam 18:10:34 the current manual system i can easily see how it functions 18:11:00 i believe tyll is on another channel, if he wants to join 18:11:05 -1 i think this will just create noise 18:11:06 im all for trying it and putting it up on a webpage or somesuch 18:11:14 I think this could be usefull, but not in bugzilla... 18:11:21 webpage + emails perhaps. 18:11:42 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 well there are reasons why someone does _not_ want to update to lastest upstream 18:11:48 I don't see how it would work otherwise. 18:12:14 I'm a bit worried about bad regexes getting entered, leading to false positives (e.g. unstable/development releases). 18:12:26 I'm going to go with "how 'bout no?" on this one. 18:12:49 But in principle, I think monitoring by default is a good idea if done properly. 18:12:50 getting spamed "update to foo" would be just annoying 18:13:16 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 as a packager, I'm on the upstream mailing lists for all the packages I maintain 18:13:22 If it's not, it's really broken. 18:13:22 that's enough, thank you 18:13:54 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 (though not all projects have one) 18:14:12 opt-in is more reasonable than opt-out 18:14:18 nirik: opt-in is what we currently have. 18:14:27 https://fedoraproject.org/wiki/Upstream_Release_Monitoring 18:14:27 yeah 18:14:33 right, and regexes are manually entered 18:14:35 which is fine 18:14:46 AIUI, the proposal is to have someone enter regexes for the packages which don't have any. 18:14:51 they have the manpower to expand that to all packages? 18:16:02 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 less than 10% coverage 18:17:55 anyhow, -1 to opt-out, +1 to opt-in 18:18:17 similar here. -1 to opt-out, +1 to opt-in 18:19:15 yeah, ditto. Would be nice to use a website/email process instead of bugzilla as well. 18:19:17 -1 opt-out, +1 opt-in 18:19:34 +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 im interested to know why you are in favor of an opt-out system? 18:20:42 -1 to opt out 18:20:58 jds2001: Because that way lazy packagers would get told to upgrade their package by default. 18:21:12 Whereas those who have good reasons not to can opt out and/or close the bugs as NOTABUG. 18:21:24 shouldn't they anyhow when a user wants a newer version for a specific reason? 18:21:24 Kevin_Kofler: said lazy packager would just opt out 18:21:46 I'm thinking of the packager(s) too lazy to opt in or out. 18:21:57 i wasn't aware laziness was a trait we wanted to promote in Fedora 18:21:58 they would likely just pile up 'please update' bugs. 18:22:15 I'm thinking there must be significant overlap with the packagers who are too lazy to upgrade their packages. 18:22:43 -1 to opt out 18:22:52 if there's something new that folks want, I'll upgrade my packages. 18:22:57 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 so -1 to opt-out 18:23:04 but upgrading just to upgrade is silly. 18:23:14 nirik: We could have the system auto-start the NRM/AWOL/MIA process. 18:23:34 Kevin_Kofler: I think that would be hard to automate. 18:23:35 * jds2001 thinks that's an even worse idea. 18:23:44 We'd catch lazy maintainers automatically that way. 18:24:14 * nirik thinks we are drifting off topic. 18:24:45 yeah, we have a boatload of features to consider. 18:25:38 #agreed Opt-out new package notification is not allowed, opt-in is fine 18:26:05 #topic Drop non-testable features 18:26:39 so I haven't had a chance to follow the thread-o-doom 18:26:45 ,fesco 240 18:26:51 .fesco 240 18:26:56 lets just go thru them case by case? 18:27:04 yeah 18:27:23 DisplayPort? 18:28:13 Was updated this week, should be testable at least with intel according to the status, -1 to dropping. 18:28:23 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 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 For DisplayPort, IIRC ajax said it's basically done, though some bugs are left. 18:29:28 yeah, -1 to dropping at this point... 18:29:44 ok, -1 to dropping 18:29:53 -1 18:29:57 If only Intel gets done, we should rescope the feature as Intel-only. 18:30:00 -1 to dropping for now. although if it's not going to get much better, it probably needs reworked 18:30:19 that looks like 5 18:30:23 -1's that is 18:30:32 next 18:30:33 #agreed DisplayPort feature is not dropped 18:30:36 FedoraStudio? 18:30:52 -1 to dropping, looks like it got updated today 18:30:59 and is mostly there 18:31:29 yeah, -1 to drop here as well. 18:31:34 -1 18:31:37 -1 18:31:56 Same here, -1 to dropping. 18:32:02 -1 18:32:08 #agreed FedoraStuido feature is not dropped 18:32:17 GFS2 clustered samba? 18:32:37 looks like some general GFS stability issues, looks like it's in testing and bugfixing 18:32:47 Updates yesterday, 90% complete, -1 to dropping. 18:32:55 -1 to dropping 18:33:05 -1 18:33:08 -1 18:33:12 -1 (so negative we are today) 18:33:23 #agreed GFS2 Clustered Samba feature is not dropped 18:33:30 #agreed GFS2 Clustered Samba feature is not dropped 18:33:33 oops 18:33:36 Gnome 2.28? 18:33:41 -1 18:33:44 -1, because, well.... 18:33:53 -1.... 18:33:56 what's there is certainly testable. 18:34:15 -1 to dropping, it's clearly being implemented for F12 and a prerelease is already in. 18:34:23 yeah, agreed. 18:34:28 #agreed Gnome 2.28 feature is not dropped 18:34:42 LowerProcessCapabilities? 18:35:06 Hmmm, is the owner around? 18:35:15 I don't see this as having landed/testable. 18:35:17 this one doesnt look to have been updated and is rather worrisome at 20% 18:35:22 This hasn't been updated for almost a month and it says 20%. 18:35:32 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 +1 18:35:42 +1 18:35:47 yep. +1 to drop and try again for next cycle. 18:36:16 libcap-ng is in Rawhide. 18:36:20 (and it's the sort of thing that looks complex to land totally) 18:36:22 Package last updated 12 days ago. 18:36:36 Whether anything actually uses it, I have no idea. 18:36:45 +1 to defer it 18:36:47 #agreed Lower Process Capabilties feature is dropped for F12 18:36:57 FedoraMoblin? 18:37:23 looks like it has the headway necessary -1 to dropping it 18:37:36 sgrubb: So here you are. Any updates for LowerProcessCapabilities? 18:37:53 been working on dhcp requirements 18:37:54 I've noticed a number of new moblin packages landing 18:37:59 how are those two outstanding package reviews looking? 18:38:05 new packages are landing, but it's not been added as a spin... 18:38:15 chatted with the maintainer on that to understand how to tackle that onbe 18:38:18 Hmmm, we're discussion 2 features at once now. 18:38:30 I pinged sgrubb so he could give an update on LowerProcessCapabilities. 18:38:40 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 My priority for the last 2 weeks had to be getting audit-2.0 package ready 18:39:06