Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2010-01-26/fesco.2010-01-26-20.01.log.html Meeting started by nirik at 20:01:03 UTC (full logs). Meeting summary init process (nirik, 20:01:03) 314 Wordpress bundles libraries (nirik, 20:03:44) AGREED: Will ask packaging to investigate this issue further before taking action on it. (nirik, 20:14:35) 315 Feature: boot.fedoraproject.org ( https://fedoraproject.org/wiki/Features/BFO ) (nirik, 20:14:46) AGREED: Feature is approved. (nirik, 20:17:20) 316 Feature - Bonobo Free Evolution ( https://fedoraproject.org/wiki/Features/BonoboFreeEvolution ) (nirik, 20:19:00) AGREED: This Feature is NOT approved. (Good work, but not feature worthy) (nirik, 20:23:49) 317 Feature: Fedora 13 Boost 1.41 Uplift ( https://fedoraproject.org/wiki/Features/F13Boost141 ) (nirik, 20:23:58) https://svn.boost.org/trac/boost/wiki/CMake (Kevin_Kofler, 20:29:39) AGREED: Feature is approved (nirik, 20:37:54) 318 Feature - Gnome 2.30 ( https://fedoraproject.org/wiki/Features/Gnome2.30 ) (nirik, 20:38:00) AGREED: Feature is approved (nirik, 20:38:50) 319 Feature: KDE Pulseaudio Integration ( https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration ) (nirik, 20:39:39) AGREED: Feature is approved (nirik, 20:40:50) 320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) (nirik, 20:41:01) AGREED: Defer this feature until next weeks meeting. (nirik, 20:48:58) 323 Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall ) (nirik, 20:49:10) AGREED: Feature is deferred to next week. Will ask feature owner for more info. (nirik, 21:01:52) 324 naming conflict: surf (nirik, 21:02:11) AGREED: Will wait a week for more data. (nirik, 21:15:41) Open Floor (nirik, 21:15:48) Open Floor (redux) (nirik, 21:30:01) Meeting ended at 21:34:16 UTC (full logs). People present (lines said) nirik (124) Kevin_Kofler (74) cwickert (74) pjones (67) dgilmore (39) notting (24) zodbot (14) mitr (5) gholms|mbp (4) tibbs (2) abadger1999 (1) mjg59 (0) ajax (0) skvidal (0) -- 20:01:03 <nirik> #startmeeting FESCO (2010-01-26) 20:01:03 <zodbot> Meeting started Tue Jan 26 20:01:03 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:03 <nirik> #meetingname fesco 20:01:03 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:01:03 <nirik> #topic init process 20:01:03 <nirik> Who all is around for the FESCo meeting? 20:01:03 <zodbot> The meeting name has been set to 'fesco' 20:01:03 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:01:25 <pjones> yo 20:01:29 <cwickert> here 20:01:30 * notting is here 20:01:57 <Kevin_Kofler> Present. 20:02:39 * dgilmore is here 20:03:02 <nirik> ok, I guess we have quorum so we can get started. 20:03:31 * nirik doesn't see skvidal yet, so lets defer package-swift further discussion. 20:03:44 <nirik> #topic 314 Wordpress bundles libraries 20:03:44 <nirik> .fesco 314 20:03:46 <zodbot> nirik: #314 (Wordpress bundles libraries) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/314 20:04:08 <nirik> sounds like we need to have packaging look for a line here on when code should be allowed to be bundled, etc. 20:04:23 <Kevin_Kofler> This sounds like a big mess of copypasta. :-( 20:04:34 <nirik> yeah. 20:04:52 <nirik> so, not sure what we can do now on this, shall we wait for packaging to look at it? 20:04:56 <nirik> any other input? 20:04:57 <Kevin_Kofler> There's no way to make it use system libraries when the code it uses is heavily patched. 20:05:12 <cwickert> I doubt this is possible in this case 20:05:20 <Kevin_Kofler> So I think we'll have to just consider it different code. 20:05:31 <Kevin_Kofler> Still, this practice really sucks. 20:05:33 <cwickert> I mean, we cannot go to the wp devs and tell them to upstream their changes 20:05:34 <pjones> that sounds unfortunate, but probably necessary. 20:05:50 <pjones> cwickert: well, we can, but we might also want to let the changes ride while we do so 20:06:02 <Kevin_Kofler> cwickert: Why not? 20:06:08 <nirik> well, it's not all a or b here. 20:06:16 <cwickert> of course we can, but I doubt that it is realistic 20:06:26 <Kevin_Kofler> They really need to stop this practice of copying code from libraries and randomly adding their own stuff. 20:06:33 <nirik> some of the things are heavily modified and could be considered new code ish... there are some that aren't and should use the system libs. 20:06:49 <nirik> where that line is is the question. 20:06:59 <cwickert> Kevin_Kofler: how would you make wp installable without the internal copies? 20:07:26 <Kevin_Kofler> As a package with proper dependencies, like any other package. 20:07:47 <cwickert> I'm not talking about the rpms but about upstream 20:08:07 <Kevin_Kofler> They should support only packages, not obsolete monolithic tarballs. 20:08:29 <Kevin_Kofler> But if they really want the monolithic crap, they can bundle unmodified libraries in a way which can be easily replaced with system copies. 20:08:30 <cwickert> this is unrealistic, think of the target audience 20:08:31 <nirik> cwickert: like any other package that depends on others... they list requirements, fail to install if they aren't there? 20:08:48 <cwickert> nirik: how would you do this with ohp? 20:08:50 <cwickert> php 20:08:54 <Kevin_Kofler> Copying the code into their own source tree and forking it is surely not the only way. 20:08:58 <pjones> cwickert: well, the target audience doesn't /really/ care if the libraries are modified or not. 20:09:05 <nirik> cwickert: wordpress has a setup.php... add it there? 20:09:05 <cwickert> right pjones 20:09:19 <dgilmore> cwickert: use includes for the system versions? 20:09:35 <notting> Kevin_Kofler: well, it's not the only way, but if the licenses are ok, we cannot *prevent* upstreams from doing so 20:09:38 <nirik> you have to add a database user and such, it fails to finish the setup if those are not in place. Just add checks for the libraries it needs. 20:09:52 <cwickert> ok, imagine you have some hosted webspace, how would you install the stuff there? 20:09:52 <Kevin_Kofler> notting: Well, we can say we don't ship their stuff if they do. 20:09:58 <Kevin_Kofler> But sadly, that's all we can really do. 20:10:04 <Kevin_Kofler> And it'd probably hurt us more than them. 20:10:34 <notting> yeah, i'm not sure what good drawing a line in the sand does us 20:10:35 <Kevin_Kofler> cwickert: Get a VPS. 20:10:49 <cwickert> great idea Kevin_Kofler ;) 20:10:49 <Kevin_Kofler> Webspace without root access is so yesterday. 20:10:56 <pjones> seems like we should at least make sure somebody involved in the security team is intimately involved? ;) 20:11:00 <Kevin_Kofler> We have virtualization these days. 20:11:27 * nirik suggests again we ask packaging about where this line should be... 20:11:34 <cwickert> +1 20:11:48 <nirik> or do folks want to just vote on wp as is now? 20:11:52 * notting agrees with that - +1 20:12:03 <notting> looks like toshio is already working the issue 20:12:14 <nirik> yeah. 20:12:33 <pjones> +1 20:12:52 <abadger1999> cwickert: I can tell you how in #fedora-devel if you'd like 20:13:07 <nirik> +1 to punting to packaging at least for now. 20:13:13 * dgilmore thinks we should wait to see what abadger1999 comes up with before we say or do much on this 20:13:58 <nirik> ok, I think thats 5 for that? 20:14:18 <Kevin_Kofler> Ideally we'd fork wordpress entirely to work with the standard libraries throughout, but that's a lot of work and it puts us in a kinda weird position ("hey, you're evil because you're forking libraries, so to remedy that, we're forking your project" – "huh?"). 20:14:35 <nirik> #agreed Will ask packaging to investigate this issue further before taking action on it. 20:14:46 <nirik> #topic 315 Feature: boot.fedoraproject.org ( https://fedoraproject.org/wiki/Features/BFO ) 20:14:46 <nirik> .fesco 315 20:14:47 <zodbot> nirik: #315 (Feature: boot.fedoraproject.org ( https://fedoraproject.org/wiki/Features/BFO )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/315 20:15:05 <Kevin_Kofler> Yeah, letting FPC sort that out is best (so +1 from me too for that, for the record). 20:15:52 <notting> this sounds neat. wish i had time to play with it. +1 20:16:14 * nirik has played with boot.fedoraproject.org a little bit. It is neat. +1 here. 20:16:20 <dgilmore> +1 for boot.fp.o 20:16:20 <cwickert> not tested it ether, but looks sane. +1 20:16:29 <cwickert> looks great in fact 20:16:32 * dgilmore thinks its very cool and useful 20:16:33 <Kevin_Kofler> +1 for boot.fedoraproject.org 20:17:19 <pjones> it's not that I don't like this, but what's the advantage of having it over just using boot.kernel.org ? 20:17:20 <nirik> #agreed Feature is approved. 20:17:43 <nirik> pjones: it can say fedora, and provide custom fedora images? 20:17:51 <notting> pjones: presumably having a branded place we could point people that won't also tell people they can boot ubuntu 20:18:08 <pjones> oh, we're allowing developers to put their own content there. okay, that's enough for me. 20:18:08 <pjones> +1 20:18:10 <Kevin_Kofler> And booting a Fedora kernel, not a vanilla one. 20:18:22 <pjones> Kevin_Kofler: b.k.o is also booting a fedora kernel 20:18:28 <pjones> (when you choose to) 20:18:55 * nirik moves on to the next topic 20:19:00 <nirik> #topic 316 Feature - Bonobo Free Evolution ( https://fedoraproject.org/wiki/Features/BonoboFreeEvolution ) 20:19:00 <nirik> .fesco 316 20:19:01 <zodbot> nirik: #316 (Feature - Bonobo Free Evolution ( https://fedoraproject.org/wiki/Features/BonoboFreeEvolution )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/316 20:19:09 <cwickert> I doubt this really is a feature 20:19:36 <cwickert> users won't notice any changes, so why announce it in the release notes? 20:19:41 * nirik isn't sure either... most users won't care that there are less monkeys. 20:19:42 <notting> yeah, it doesn't sound like a feature that is toutable in the release notes, or makes a difference to users in obvious ways. that being said, DO IT. 20:19:46 <dgilmore> -1 not a feature 20:19:57 <Kevin_Kofler> Yeah, I mean this change makes a lot of sense technically, but why do we need to advertise it to users? 20:20:02 <dgilmore> but im all for the change 20:20:06 <Kevin_Kofler> They won't notice a difference. 20:20:16 <dgilmore> Just dont think its worth doing a song and dance over 20:20:23 <cwickert> it's already done, I doubt they will go back to 2.28 20:20:33 <Kevin_Kofler> The feature even says "This being largely an internal cleanup effort with no major UI changes, users should not notice much difference from F12." 20:20:51 <cwickert> and the text for the release notes is bad too 20:20:55 <pjones> I'm guessing this was filed because somebody's manager in RHEL-land asked them to file it for accounting reasons that RHEL people haven't properly expressed to FESCo. 20:21:00 <pjones> (there was a lot of that recently) 20:21:22 <nirik> yeah, I am all for it, but -1 for being a feature. 20:21:26 <cwickert> just do it, but don't call it a feature 20:21:30 <notting> nirik: agreed, -1 20:21:34 <dgilmore> pjones: possibly its still not a toutable feature 20:21:37 <Kevin_Kofler> I guess the eshell API which is part of this would be something resembling a feature to some extent. 20:21:51 <pjones> dgilmore: yeah, I don't think that's something the RHEL people are considering. 20:22:10 <Kevin_Kofler> But how many users of that API are there, realistically? Just in-process plugins for Evolution, which aren't that many, are they? 20:22:30 <pjones> Kevin_Kofler: also evolution-data-server, I would think? 20:22:56 <pjones> or rather, it's communicating using related methods 20:23:02 <pjones> not saying it's using that specifically 20:23:07 <Kevin_Kofler> AIUI, e-d-s is at the other end of the dependencies, it's used by Evolution, it doesn't use eshell or other stuff from Evolution. 20:23:15 <nirik> any more -1 votes? I see 3. 20:23:26 <pjones> nirik: I'm for "not a feature but go ahead", so -1 20:23:28 <cwickert> -1 for the feature, but +1 for the change 20:23:43 <Kevin_Kofler> -1, not a feature (but the change fully makes sense, of course) 20:23:49 <nirik> #agreed This Feature is NOT approved. (Good work, but not feature worthy) 20:23:58 <nirik> #topic 317 Feature: Fedora 13 Boost 1.41 Uplift ( https://fedoraproject.org/wiki/Features/F13Boost141 ) 20:23:58 <nirik> .fesco 317 20:24:02 <zodbot> nirik: #317 (Feature: Fedora 13 Boost 1.41 Uplift ( https://fedoraproject.org/wiki/Features/F13Boost141 )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/317 20:25:00 * cwickert is not sure if this is a feature ether, but it sounds good 20:25:10 * dgilmore doesnt think it sounds good 20:25:11 <Kevin_Kofler> Well, it's relevant for developers. 20:25:21 <dgilmore> sounds like we are jumping onto a fork 20:25:25 <Kevin_Kofler> In particular we have MPI support now. 20:25:38 <Kevin_Kofler> Using CMake always sounds good. :-) 20:25:43 <cwickert> dgilmore: a fork? 20:25:57 <Kevin_Kofler> Just a different build system. 20:26:05 <Kevin_Kofler> There are no changes outside of the build system. 20:26:08 <dgilmore> cwickert: In addition, this update changes the canonical sources used for the package from the official Boost release to an alternate repository. 20:26:13 <cwickert> the feature page says we sync with upstream 20:26:30 <Kevin_Kofler> BJam is homegrown, arcane and annoying, we're using CMake instead now. 20:26:31 <dgilmore> cwickert: the feature page is kinda contradictory 20:26:39 <cwickert> dgilmore: right 20:26:44 <Kevin_Kofler> I think the plan is for future versions of Boost to use CMake by default. 20:26:48 <dgilmore> CMAKE is annoying and difficult also Kevin_Kofler 20:27:19 <dgilmore> but regardless i think moving away from official sources for whatever reason is bad 20:27:32 <pjones> I don't think bjam vs cmake is really something we need to discuss 20:27:34 <Kevin_Kofler> CMake is not annoying at all. :-) 20:27:46 <notting> pjones: +1 20:27:54 * nirik thinks people are derailing. we don't care what the build sys is. 20:28:01 <dgilmore> pjones: i dont either. i think moving away from upstream is bad though 20:28:17 <pjones> it looks like it's switching to a different branch at the /same/ upstream. Is that not what's happening? 20:28:31 <notting> i suppose this is more or less in-line with the various other updates from upstreams (gnome, kde, etc.) 20:28:32 <notting> ergo, +1 20:28:56 <dgilmore> pjones: NFI because its not clear where this alternate source is 20:29:39 <Kevin_Kofler> https://svn.boost.org/trac/boost/wiki/CMake 20:29:40 <cwickert> if this is the new boost, I'd say ok, but what if it turns out to be a short-lived fork? 20:29:58 <Kevin_Kofler> This is linked from the feature-page and there's a lot of information there. 20:30:32 <pjones> hrm, url in the .spec in bz is http://sodium.resophonic.com/boost-cmake/%{version}.cmake4/, but the feature page points to https://svn.boost.org/trac/boost/wiki/CMake 20:30:33 <Kevin_Kofler> cwickert: I guess we can switch back to BJam if we have to, though getting things like MPI to work there might be harder (we didn't ship that in the past because of BJam issues AIUI). 20:30:42 * nirik would hope that the cmake and bjam build versions of the same upstream source would be compatible. 20:31:08 <pjones> the latter of those urls does point to the former though 20:31:10 <pjones> still, seems odd. 20:31:26 * cwickert is confused by that feature page 20:31:36 <dgilmore> cwickert: its not at all clear 20:31:46 * dgilmore doesnt think its feature worthy 20:32:00 <Kevin_Kofler> I also doubt the CMake port is going to be short-lived. 20:32:02 <dgilmore> but im concerned about wtf is actually going on 20:32:11 <nirik> so, should we add comments to the talk page/feature owner and revisit next week? 20:32:21 <nirik> oh, we can't. 20:32:24 <Kevin_Kofler> It's more likely to become the default at some point. 20:32:31 <pjones> nirik: deadline time 20:32:33 <nirik> yep. 20:32:41 <pjones> I'm certainly for switching to 1.4.1 20:32:43 <Kevin_Kofler> Or at least an alternative supported option. 20:32:51 <pjones> switching to the cmake repo seems odd since it's not the main upstream repo 20:33:00 <dgilmore> pjones: right 20:33:07 <Kevin_Kofler> nirik: Sure we can, the feature got submitted in time, nothing says it has to be approved today. 20:33:08 <pjones> OTOH, I'm largely in favor of "bkos is probably right" 20:33:15 <nirik> So, I guess I am an weak +1 to this. I would like the feature page to be more clear. 20:33:33 <pjones> nirik: yeah, likewise. 20:33:41 <pjones> +1 but it'd be nice if this were explained better. 20:34:10 * nirik sees 3 +1's so far. 20:34:37 <Kevin_Kofler> +1 20:35:11 <dgilmore> im -1 because it really doesnt seem like a feature 20:35:17 <cwickert> +-1, I have no idea if this is going to be the next big thing or a dead horse 20:35:31 <pjones> dgilmore: that is a fair point. 20:35:50 * nirik sees +4 / -1 / 0 20:35:56 <pjones> having MPI looks like a feature, so I'm still +1 20:36:10 <Kevin_Kofler> dgilmore: The new version and the addition of MPI are both relevant to developers. 20:36:14 <cwickert> ack 20:36:28 <Kevin_Kofler> And Boost is a common library, so developers are a relevant audience. 20:36:34 <pjones> yeah 20:36:39 <cwickert> ok, so +1 for me because of the new MPI. and I really think this is feature worthy 20:37:00 <nirik> ok, that pushes it to +5. ;) 20:37:00 <pjones> I think the cmake issue is worth ignoring, because if upstream doesn't move to it, switching back to non-cmake or to something else is still doable, and shouldn't make any difference. 20:37:22 <Kevin_Kofler> The CMake stuff is more an internal change. 20:37:27 <pjones> yeah. 20:37:30 <cwickert> ok, then I see no drawbacks 20:37:44 * nirik notes that the feature title also makes him think of dolphins and chimps... but I read too much sci-fi. ;) 20:37:54 <nirik> #agreed Feature is approved 20:38:00 <nirik> #topic 318 Feature - Gnome 2.30 ( https://fedoraproject.org/wiki/Features/Gnome2.30 ) 20:38:00 <nirik> .fesco 318 20:38:01 <pjones> nirik: not that dolphins and chimps are necessarily a problem? ;) 20:38:01 <zodbot> nirik: #318 (Feature - Gnome 2.30 ( https://fedoraproject.org/wiki/Features/Gnome2.30 )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/318 20:38:11 <pjones> +1 on new gnome 20:38:14 <cwickert> +1 20:38:26 <notting> +1, per usual 20:38:35 <nirik> +1 again. ;) 20:38:38 <Kevin_Kofler> +1, blanket approval for new version of major DE :-) and prereleases are already in 20:38:50 <nirik> #agreed Feature is approved 20:39:30 <Kevin_Kofler> BTW: "The default mode in nautilus has been changed to browser." :-) 20:39:39 <nirik> #topic 319 Feature: KDE Pulseaudio Integration ( https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration ) 20:39:40 <nirik> .fesco 319 20:39:41 <zodbot> nirik: #319 (Feature: KDE Pulseaudio Integration ( https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/319 20:39:49 <Kevin_Kofler> +1, that's my feature, of course I'm for it. ;-) 20:39:51 <cwickert> :D 20:39:54 <pjones> +1 in that I don't actually give a shit. 20:39:54 <cwickert> +1 20:40:14 <notting> +1, sounds good 20:40:18 <dgilmore> +1 id like it working better 20:40:24 <nirik> +1. "sounds" good to me too. ;) 20:40:28 <pjones> nirik: ow. 20:40:34 * nirik ducks. 20:40:35 <gholms|mbp> ... 20:40:50 <nirik> #agreed Feature is approved 20:41:01 <nirik> #topic 320 Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist ) 20:41:01 <nirik> .fesco 320 20:41:02 <zodbot> nirik: #320 (Feature: Modprobe whitelist ( https://fedoraproject.org/wiki/Features/ModprobeWhitelist )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/320 20:41:27 <pjones> This sounds like a misfeature to me, honestly. 20:41:56 * nirik notes it's not accepted upstream from what this says. 20:41:58 <Kevin_Kofler> Well, we won't ship with a whitelist by default. 20:42:10 <pjones> but really I don't think it's FESCo's territory - if the upstream maintainer likes it, I don't know why we'd care. If they don't, it shouldn't go in. 20:42:20 <cwickert> fair point 20:42:40 <cwickert> and IMO upstream should decide before we vote, but this is not possible due to the deadline 20:42:44 <mitr> nirik: upstream agreed in principle - but the complete patches are not ready yet, will be in a ready in day or two. 20:42:46 <Kevin_Kofler> 25% sounds pretty low for percentage of completion given where we are in the release cycle. 20:42:53 <nirik> hey mitr. :) 20:43:10 <Kevin_Kofler> But if the stuff will be ready in a day or two, that's fine. 20:43:45 <nirik> is this something that could be controlled from a sysconfig file or be integrated with our system more? just running a script doesn't seem very polished to me... 20:43:49 <mitr> Kevin_Kofler: The whole feature is small - the remaining 75% is testsuite+documentation+3 line-script for dracut + upstream acceptance. If upstream rejects the patch, we can pull the feature with no impact on Fedora. 20:43:59 <notting> cwickert: it was submitted before the deadline, we could postpone the vote 20:44:07 <Kevin_Kofler> I think this feature is OK and worth advertising, I don't see this as particularly useful, but I guess paranoid admins will like it. ;-) 20:44:17 <cwickert> mitr: what do you think when you have a decision from upstream? 20:44:23 <Kevin_Kofler> And it won't break anything for people who don't set up such a whitelist. 20:44:25 <pjones> Kevin_Kofler: paranoid admins will make their systems unbootable with it ;) 20:44:46 <mitr> cwickert: After I post the patches - day or two, again. 20:44:53 <dgilmore> -1 its only 25% done and not in a testable state. 20:45:08 <dgilmore> feature freeze is really close 20:45:10 <pjones> +1 for delaying a verdict until later 20:45:21 <Kevin_Kofler> So proposal: we vote on this next week? 20:45:26 <nirik> how much "later" do we have? 20:45:29 <nirik> next week? 20:45:44 <Kevin_Kofler> That's 1 week before feature freeze and we should know more (mitr says he needs 1 or 2 days to complete the patches). 20:45:56 <pjones> nirik: a week is a week. 20:46:24 <nirik> pjones: sure, meaning how much should we wait before deciding? 20:46:47 <pjones> I'm for asking mitr to get it done soon and discussing it again next week ;) 20:46:48 <nirik> I guess I am ok with waiting a week, if there is going to be progress in the next week we should consider. 20:46:59 <cwickert> I suggest do wait a week, otherwise I give my +1 right now because we really should let mitr try. if something bad happens, it can still be dropped 20:47:04 <cwickert> s/do/to 20:47:05 <pjones> mitr: hey, so is there going to be progress this week? 20:47:29 <mitr> pjones: Getting it done this week is my #1 priority. 20:47:39 <Kevin_Kofler> I'd say defer 1 week, if it's still undecided, defer another week (which will be the day of feature freeze), if it's still undecided then, reject. 20:48:05 <pjones> (still) +1 for revisiting this next week 20:48:14 <nirik> +1 to that here. 20:48:18 <Kevin_Kofler> +1 to deferring to next week 20:48:24 <cwickert> same from me 20:48:36 <notting> +1 to defer 20:48:45 <pjones> that's 5 20:48:48 <nirik> ok. 20:48:58 <nirik> #agreed Defer this feature until next weeks meeting. 20:49:10 <nirik> #topic 323 Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall ) 20:49:10 <nirik> .fesco 323 20:49:11 <zodbot> nirik: #323 (Feature: Dynamic Firewall ( https://fedoraproject.org/wiki/Features/DynamicFirewall )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/323 20:50:04 <notting> the 'Fedora 12' at the bottom needs tweaked :) 20:50:06 <pjones> 20% sounds rather poor. 20:50:07 * nirik is a bit confused here with this one. 20:50:26 <cwickert> pjones: trust twoerner, he is a good guy 20:51:00 <nirik> iptables-restore is atomic, so 'restart' shouldn't matter. But perhaps they are talking about unloading connection tracking/modules on restart? 20:51:23 * nirik doesn't know the internals here tho 20:51:50 <dgilmore> nirik: adding and removing rules without a restart of iptables 20:52:00 <Kevin_Kofler> I'd really like to know why this is listed at only 20% too. 20:52:16 <dgilmore> This really needs to be testable with a test plan 20:52:23 <nirik> dgilmore: if they were using iptables-restore, it shouldn't matter. 20:52:57 <pjones> nirik: I think he's talking about running system-config-firewall and selecting a /new/ firewall rule, then doing "service iptables restart" 20:53:05 <nirik> but I think they are unloading connection tracking and such, which does make it matter 20:53:15 <dgilmore> the wiki page the feature page points to looks to be the same content 20:53:17 <pjones> but either way, this clearly needs more info if we're going to vote on it meaningfully. 20:53:44 <Kevin_Kofler> The linked https://fedoraproject.org/wiki/SystemConfig/firewall has some more info. 20:53:55 * dgilmore thinks we need to ask for more detail 20:53:56 <cwickert> but that page is incomplete too 20:54:28 * nirik also would be good asking for more detail and defering to next week. 20:54:33 <cwickert> the new features like user policy support sound cool, but is anything of this already implemented? 20:54:49 <nirik> shall we add questions to the fesco ticket and/or the talk page? 20:54:57 <cwickert> ack 20:54:57 <notting> we can wait, if people want. but nothing in the limited data there would make me inclined to vote against it 20:55:42 <Kevin_Kofler> IIUC, the drawback of the dynamic mode seems to be that it requires yet another background service. 20:55:56 <cwickert> dbus is already required everywhere 20:56:02 <cwickert> (in Fedora) 20:56:09 <dgilmore> notting: nothing would make me vote against it. I just have no idea from the feature page how i would use it 20:56:48 <Kevin_Kofler> Yes, but it seems to run a D-Bus-based daemon too. But I may be misunderstanding things, the documentation is really light on details. 20:57:01 <nirik> proposed: defer a week and ask questions we have of feature owner? 20:57:32 <cwickert> I think we really could need some more info, but I trust the owner to do the right thing (tm) 20:57:38 <Kevin_Kofler> Anyway, I don't see that as a real issue. 20:59:42 * nirik would prefer to defer, but if folks want to vote now we can 21:00:20 <Kevin_Kofler> I'm for asking for more info and deferring. 21:00:39 <cwickert> +1 for defer 21:00:48 <nirik> thats 3 to defer. 21:01:08 * notting votes to defer to keep the meeting moving 21:01:28 * pjones too 21:01:33 <nirik> ok 21:01:52 <nirik> #agreed Feature is deferred to next week. Will ask feature owner for more info. 21:02:03 <nirik> Please ask your questions of the feature owner everyone who had them. 21:02:11 <nirik> #topic 324 naming conflict: surf 21:02:11 <nirik> .fesco 324 21:02:22 <zodbot> nirik: #324 (naming conflict: surf) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/324 21:02:23 <cwickert> an update on that one 21:02:39 <cwickert> the number of packages that need would to be patched is 4, not 7 21:02:58 <cwickert> but it could become more in the future depending on how many surf plugins there are 21:03:07 <nirik> personally I would like to hear from the other still in existance upstream. 21:03:51 <cwickert> simon has tried to contact the other upstream today, but no reply yet 21:04:14 <nirik> well, lets give them some time to answer? unless there is some critical need for another web browser right now? ;) 21:04:32 <cwickert> IMO not 21:04:35 <tibbs> Note that the web browser package is already in the distribution. 21:04:43 <nirik> oh, right. 21:05:00 <cwickert> but we can't do anything about it, can we? untag the package for now? 21:05:43 <nirik> has it pushed out already? testing or stable? 21:05:48 <cwickert> stable 21:05:54 <tibbs> Went straight to stable. 21:06:00 <cwickert> already before anybody noticed the conflict 21:06:42 <nirik> ok, then I say we just leave it for now, and if we have to re-name it later the new package can obsolete it. 21:07:36 * dgilmore thinks that we should rename it to surf-browser since upstream doesnt want to rename and the existing package existed before this 21:07:47 <nirik> it may be that the other upstream is willing to rename... or that they are dead completely and don't answer. Either would be more data than we have now. 21:08:19 <cwickert> ok, then give upstream the a week to respond? 21:08:29 <nirik> +1 from me to that. 21:08:46 <Kevin_Kofler> dgilmore: The problem is that there's also the binary which I guess will also conflict. 21:08:58 <cwickert> nirik: the other upstream doesn't seem dead, they release something recently 21:09:11 <Kevin_Kofler> There are 3 conflicting packages. :-/ 21:09:22 <Kevin_Kofler> The third one is completely dead and non-Free though. 21:09:34 <dgilmore> Kevin_Kofler: we rename it 21:09:34 <Kevin_Kofler> And has no project page, just a tarball sitting around. 21:09:46 <nirik> right, so we should work with both to try and come up with a solution... 21:09:56 <nirik> (and ignore the dead nonfree one) 21:10:27 <cwickert> latest surf from http://sourceforge.net/projects/surf/files/ is from 2010-01-18, so they are alive and kicking 21:10:40 <dgilmore> without talking to both upstreams we cant do too much 21:10:50 <cwickert> +1 dgilmore 21:11:19 <cwickert> and maybe Simon can talk to the browser upstream again in a more diplomatic way ;) 21:11:51 <nirik> we shouldn't just go do our own thing... we should try and help both the projects come up with a solution... IMHO. 21:12:20 <nirik> proposed: wait a week for more data. 21:12:42 <cwickert> +1 for waiting a week 21:12:54 <nirik> +1 from me. 21:13:49 <notting> +1 21:15:01 <dgilmore> +1 21:15:39 <Kevin_Kofler> +1 21:15:41 <nirik> #agreed Will wait a week for more data. 21:15:48 <nirik> #topic Open Floor 21:15:56 <nirik> Anyone have anything for open floor? 21:16:30 <cwickert> one more thing on the dynamic firewall thing: s-c-d is required by andconda, this means that we have dbus as a required package *everywhere*. not sure if this is a good idea 21:16:33 <pjones> we've got a cople of features that are submitted but havn't made it past the bot yet 21:16:51 <pjones> cwickert: we already have dbus in anaconda 21:16:56 <cwickert> ah, ok 21:17:28 <mitr> pjones: how about the installed system? I thought anaconda / s-c-f were recently modified not to require installing dbus on the final system. 21:17:29 <nirik> ok, today is feature submission deadline... do we want to try and do anything for those features? 21:17:55 <pjones> mitr: well, anaconda has nothing to do with that. no idea about s-c-f 21:18:09 <cwickert> did we vote in https://fedoraproject.org/wiki/Features/VHostNet already? 21:18:13 <pjones> nirik: it'd be nice, since they were submitted on time ;) 21:18:30 <nirik> pjones: I added all the ones that past the feature wrangler. 21:18:48 <cwickert> nirik: it is ReadyForFesco 21:18:59 <nirik> cwickert: it wasn't yesterday. 21:19:06 <pjones> nirik: yesterday wasn't the deadline. 21:19:24 <nirik> thats fine. I am just explaining why it wasn't on my agenda. ;) we can do it now... 21:19:41 <nirik> #topic Feature: VhostNet ( https://fedoraproject.org/wiki/Features/VHostNet ) 21:19:43 <pjones> and in reality, several of these are "management asked me to file a feature on this yesterday afternoon" (including the one I filed) 21:20:01 <Kevin_Kofler> cwickert: dbus is being added as mandatory to the base group. 21:20:08 <cwickert> nirik: it was marked ready by the owner, not by poelcat 21:20:10 <Kevin_Kofler> So it will be required everywhere anyway. 21:20:26 <nirik> cwickert: ah... interesting. 21:20:51 <notting> cwickert: then perhaps we should leave it 21:21:18 <cwickert> right, seems like a violation of the feature process, it was moved directly from incomplete to ReadyForFesco 21:21:55 <dgilmore> pjones: management should not do that. at least not this late in the game 21:21:55 <pjones> Right, so move it back to ReadyForWrangler. 21:21:58 <Kevin_Kofler> And Documentation and Release Notes are blank with no rationale. 21:22:01 <pjones> dgilmore: and yet they do. 21:22:09 <Kevin_Kofler> So it's not really ReadyForFesco. 21:22:10 <nirik> pjones: yeah, but then we don't consider it at all? 21:22:53 <dgilmore> pjones: ill be glad to explain why all there features were not looked at 21:23:07 <pjones> nirik: I'm still saying we should be considering those since AFAIK wrangler (and I don't know the mechanics here) simply hasn't run since the deadline, which AFAICS is effectively announced as this meeting. 21:23:23 <nirik> poelcat: you around? 21:24:02 <nirik> pjones: ok, so anything thats incomplete now we should consider next time if it's readyforfesco? 21:25:05 <pjones> in effect just extending the deadline? instead of just reviewing them now, since (as you may have noticed earlier) ReadyForFesco doesn't really indicate if it's ready for fesco in the first place? 21:25:36 <dgilmore> pjones: we probably should give them a look over 21:26:53 <nirik> pjones: well, the feature wrangler does check things over... 21:27:08 <pjones> when? 21:27:17 <nirik> so in the case of this feature it likely won't be marked readyforfesco until the documentation and release notes are filled in at least. 21:27:27 <dgilmore> nirik: but this is supposed to be the last meeting for features 21:27:30 <pjones> and how does somebody submitting a feature know that it's done so? 21:27:36 <pjones> nirik: there are others that don't have that problem. 21:27:55 <dgilmore> certainly any new feature added to the wiki now is for F-14 21:27:57 <cwickert> btw: does anybody know the owner? 21:28:06 <nirik> pjones: I don't know. poelcat is the feature wrangler, I don't know what his schedule is, aside from him processing them yesterday afternoon. 21:28:14 <notting> feature submisssion deadline is today, correct? so that means marking them 'ready for wrangler', no? 21:28:29 <cwickert> notting: good point 21:28:35 <nirik> notting: that sounds sane to me, yes. 21:28:58 <pjones> notting: if that's what that means, sure. and in that case, reviewing them next week sounds fine to me. 21:29:11 <cwickert> then move it back to readyforwrangler, let poelcat go over it again and vote next week? 21:29:23 <pjones> +1 on that 21:29:24 <nirik> sounds good to me. 21:29:24 <cwickert> s/again// 21:29:27 <cwickert> +1 then 21:29:30 <nirik> #undo 21:29:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x29f85a50> 21:29:52 * nirik wonders if that did the right thing. Hope so. 21:29:52 <notting> neat, we're removing objects 21:29:59 <gholms|mbp> Back to open floor, then? 21:30:01 <nirik> #topic Open Floor (redux) 21:30:07 <gholms|mbp> Will skvidal be here today, or is package-swift completely off the menu this week? 21:30:14 <notting> i believe he's vacationing? 21:30:17 <pjones> nirik: looks like you've caused a message that the bot has never had to display before ;) 21:30:28 <cwickert> gholms|mbp: he told me he doesn't want to discuss this again 21:30:35 <gholms|mbp> Okee dokee. 21:32:22 <nirik> ok, anything for open floor? 21:33:09 * nirik will close the meeting in a few then. 21:34:13 <nirik> Thanks for coming everyone. 21:34:16 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
