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