Minutes/Summary from today's FESCo meeting (2011-02-02)

Kevin Fenzi kevin at scrye.com
Wed Feb 2 18:53:42 UTC 2011

#fedora-meeting: FESCO (2011-02-02)

Meeting started by nirik at 17:30:01 UTC. The full logs are available at

Meeting summary
* init process  (nirik, 17:30:01)

* #516 Updates policy adjustments/changes  (nirik, 17:32:26)
  * LINK: https://fedorahosted.org/bodhi/ticket/182   (nirik, 17:39:08)
  * LINK: https://fedorahosted.org/bodhi/ticket/470   (nirik, 17:39:59)
  * LINK: https://fedorahosted.org/bodhi/ticket/158   (nirik, 17:40:06)
  * ACTION: nirik to talk to lmacken about this and provide more info
    for next week.  (nirik, 17:53:45)
  * AGREED: will not implement this suggestion at this time.  (nirik,

* #515 Investigate a "features" repo for stable releases  (nirik,

* #517 Updates Metrics  (nirik, 18:06:58)

* #518 Abrt  (nirik, 18:08:06)
  * ACTION: nirik will ask for roadmap/more info in ticket, will revisit
    next week.  (nirik, 18:12:32)

* #544 List of services that may start by default  (nirik, 18:12:54)
  * LINK: http://fpaste.org/B18Y/   (nirik, 18:15:55)
  * ACTION: mjg59 and notting will work on the list and sort thru it for
    next time.  (nirik, 18:36:33)
  * AGREED: we mostly like spot's draft and will look at the list next
    time for exceptions that are needed.  (nirik, 18:36:55)

* #550 F15Feature: Indic Typing Booster -
  http://fedoraproject.org/wiki/Features/IndicTypingBooster  (nirik,
  * AGREED: Feature is approved  (nirik, 18:49:40)

* Open Floor  (nirik, 18:49:48)

Meeting ended at 18:52:51 UTC.

Action Items
* nirik to talk to lmacken about this and provide more info for next
* nirik will ask for roadmap/more info in ticket, will revisit next
* mjg59 and notting will work on the list and sort thru it for next

Action Items, by person
* mjg59
  * mjg59 and notting will work on the list and sort thru it for next
* nirik
  * nirik to talk to lmacken about this and provide more info for next
  * nirik will ask for roadmap/more info in ticket, will revisit next
* notting
  * mjg59 and notting will work on the list and sort thru it for next
  * (none)

People Present (lines said)
* nirik (125)
* mjg59 (64)
* notting (22)
* mclasen (18)
* skvidal (15)
* zodbot (12)
* mmaslano (12)
* SMParrish (9)
* tibbs (3)
* ajax (0)
* kylem (0)
* cwickert (0)
17:30:01 <nirik> #startmeeting FESCO (2011-02-02)
17:30:01 <zodbot> Meeting started Wed Feb  2 17:30:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:01 <nirik> #meetingname fesco
17:30:01 <zodbot> The meeting name has been set to 'fesco'
17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:01 <nirik> #topic init process
17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:06 * notting is here
17:30:10 * mclasen too
17:30:12 <mjg59> Afternoon
17:30:24 * mmaslano is here
17:30:49 <nirik> SMParrish should be here in a few...
17:31:32 <mjg59> ajax is still away
17:32:10 <nirik> I guess we have 5 so we could go ahead and dive in.
17:32:26 <nirik> #topic #516 Updates policy adjustments/changes
17:32:26 <nirik> .fesco 516
17:32:27 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516
17:32:54 <nirik> ok, so this week I pulled two more ideas from the ideas container.
17:32:59 <nirik> 1) allow anon karma to count. Or allow it to count less (.5).
17:33:19 <nirik> The idea here is that we would allow non logged in people to influence karma. They currently don't.
17:33:30 <nirik> Of course it's not very hard to get an account.
17:33:38 <mclasen> wouldn't that open the door to voter fraud ?
17:34:16 <nirik> it could, as you could vote anon a bunch of times from different places, etc.
17:34:34 <mclasen> oh, you can't vote repeatedly from the same place ?
17:34:41 <mjg59> I think we do have to assume good faith on the part of contributors
17:34:49 <mjg59> To a certain extent
17:34:57 <mclasen> but with anon votes we don't know they are contributors...
17:35:00 <nirik> I'm not sure if it does anything for preventing multiple votes from the same ip or the like.
17:35:01 <mjg59> I've no problem with permitting it unless it turns out to cause problems
17:35:23 <mjg59> But it ought to block obvious duplicates, and we probably need to talk to luke to make sure that happens?
17:35:38 <mmaslano> I would try it, it could be reverted if it turn to be bad
17:35:50 <mmaslano> but we should be able to track these changes somehow
17:35:53 <nirik> I think we did have it enabled at first... but then later disabled it.
17:36:03 <mmaslano> why?
17:36:51 <nirik> I can't recall. Let me see if I can dig up details.
17:37:21 <notting> i wouldn't enable it until we know if it catches obvious fraud (repeated spamming from same IP, etc.)
17:37:55 <mjg59> Yes, conditional on that
17:39:08 <nirik> https://fedorahosted.org/bodhi/ticket/182
17:39:59 <nirik> https://fedorahosted.org/bodhi/ticket/470
17:40:06 <nirik> https://fedorahosted.org/bodhi/ticket/158
17:40:28 <nirik> so, currently it should use a captcha and require an email address (but I don't think there's any way to make sure it's a valid address)
17:41:56 <nirik> I guess personally I would say to not do this at this time, and revisit with bodhi 2.0 with the newer karma setup.
17:43:12 * SMParrish here  sorry about that
17:43:26 <nirik> I could ask luke how hard it would be to keep track of per ip anon submissions... that could be complicated tho
17:43:46 <mjg59> If we can limit it to one per IP, sure
17:43:54 <mjg59> Or if we can require that the email address be confirmed
17:44:15 <mjg59> But that's some additional complexity
17:44:28 <nirik> yeah.
17:44:37 <notting> but given that e-mail address confirmation is basically all that's required to get a real account...
17:45:02 <nirik> right. There's no requirement for any group, etc to add karma, just a FAS account at all.
17:46:26 <nirik> so, I am -1 at this time, other votes or discussion?
17:47:06 <mjg59> +1 conditional on some mechanism for encouraging uniqueness
17:48:22 <SMParrish> -1 I don't think it is much to ask that some be cla_done to add karma
17:49:03 * nirik isn't sure you even need cla_done.
17:49:07 <mmaslano> +1 with fixes in bodhi (migt wait for 2.0)
17:49:34 <mjg59> I think cla_done is way too far
17:49:55 <mjg59> I don't think we should be requiring people to provide a real world address in order to test our packages
17:50:11 <mjg59> But we don't require that at present anyway, so
17:50:45 <SMParrish> I just want some way to make sure it isn't gamed.
17:50:58 <nirik> I wonder how clear it is that their karma doesn't count if they are anonymous.
17:51:03 <nirik> it doesn't seem to really say that
17:51:17 <notting> +1 with the same conditions as others... can revisit if it becomes an issue
17:52:38 <nirik> ok, how about I talk with Luke and see what it would take to add stuff for uniqness and we revisit next week?
17:53:03 <mmaslano> fine with me
17:53:13 <SMParrish> works for me
17:53:45 <nirik> #action nirik to talk to lmacken about this and provide more info for next week.
17:53:50 <nirik> The other one I had was:
17:53:53 <nirik> 2) enforced min number of days in testing for some updates?
17:54:20 <nirik> The thing here is that some updates that are in high demand get karma quickly and never even go to testing or get mirrored out.
17:54:46 <nirik> The thought was that rushing testing like that could result in less through testing overall.
17:55:00 <nirik> so, the idea was to require some small number of days in testing... 2-3 or so.
17:55:11 <mclasen> how do they get karma without ending up in testing ? people test koji builds directly ?
17:55:13 <notting> yes
17:55:35 <notting> i'm against this, generally... if the karma/testing being done isn't good enough, we should fix that
17:56:15 <nirik> yeah, grab the builds directly.
17:56:36 <mclasen> as long as we allow updates to trickle, it seems ok to me...testing is testing
17:56:37 <SMParrish> Bodhi should inhibit karma until the build is pushed to the testing repo
17:56:47 <SMParrish> and maybe even for 24 hours after that
17:56:49 <nirik> yeah, I would agree. If someone rushes their testing and says +1, when it's broken, we need them to test better/more.
17:56:51 <mclasen> when we get to actually batch updates in some form, it will solve itself
17:57:50 <mmaslano> it's very handy for broken things which I need to see fix asap e.g fedpkg few weeks back
17:58:08 <nirik> well, going out to testing does mean more people will see it/test it, but if 2-3 people grab the build and test it and say it's ok, we should trust them unless they prove they are not trustworthy.
17:58:13 <mjg59> When we first introduced this I seem to remember us explicitly saying that people could effectively go straight to updates if they had enough karma
17:58:22 <mjg59> So as far as I'm concerned, this is working as we designed it
17:58:24 <nirik> mjg59: yep
17:58:49 <mjg59> And without any evidence that packages falling into this state are going out broken, I don't see any reason to change it
17:59:51 <nirik> There was an example I think from the person who submitted this idea... but I can't recall what package it was.
18:00:02 <nirik> (and it really doesn't seem like it's widespread)
18:00:23 <mjg59> So I'm -1 for now
18:00:29 <mclasen> nirik: so you are saying that having the package out in testing gives some implicit confidence that it is not entirely busted, through the absence of negative karma, even if we don't get positive karma ?
18:01:00 <nirik> thats what the submittor of this idea was supposing I think, yes.
18:01:14 * nirik notes he's just passing these ideas along and trying to get them a fair hearing.
18:02:02 <nirik> I am -1 to this at this time. I think if we run accross updates having problems due to no testing time, we should look at who is doing the testing and help them test better.
18:02:14 <mmaslano> -1
18:03:21 <nirik> ok, so where are we. -4 ?
18:03:35 <mjg59> Think so
18:04:31 <nirik> anyone else? mclasen ?
18:04:33 <nirik> SMParrish: ?
18:04:34 <mclasen> -1
18:04:41 <SMParrish> Y'all changed my mind  I'll go -1
18:05:11 <nirik> #agreed will not implement this suggestion at this time.
18:05:24 <nirik> #topic #515 Investigate a "features" repo for stable releases
18:05:25 <nirik> .fesco 515
18:05:26 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
18:05:39 <nirik> I think cwickert was going to work on this, but I expect he is still traveling right now.
18:05:58 * nirik will move on unless someone has something to add on this topic.
18:06:16 <mclasen> did this get discussed at fudcon ?
18:06:25 <nirik> not that I recall.
18:06:58 <nirik> #topic #517 Updates Metrics
18:06:58 <nirik> .fesco 517
18:06:58 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517
18:07:10 <nirik> same deal for this one... kylem was going to work on it...
18:07:37 * nirik will move on in a minute if nothing else on this from anyone.
18:08:06 <nirik> #topic #518 Abrt
18:08:06 <nirik> .fesco 518
18:08:06 <zodbot> nirik: #518 (Abrt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/518
18:08:23 <nirik> we were hoping to talk to abrt folks at fudcon, but not sure that happened either. ;)
18:08:33 <nirik> So, failing that, we should ask them for a roadmap or the like.
18:08:35 <notting> i saw jiri
18:09:00 <mmaslano> he has a presentation there
18:09:25 <nirik> yeah, too many things to be in at once. ;(
18:09:31 <mmaslano> not sure if he met someone, he's still traveling
18:10:35 <notting> yeah, just talked to him about generalities
18:11:06 <nirik> ok, so shall we ask in the ticket for a roadmap update and go from there next week? I think maintainers will be happier knowing which improvements are coming when...
18:12:06 <mjg59> Sure
18:12:15 <SMParrish> yes
18:12:32 <nirik> #action nirik will ask for roadmap/more info in ticket, will revisit next week.
18:12:51 <nirik> ok, on to the fun one for today...
18:12:54 <nirik> #topic #544 List of services that may start by default
18:12:54 <nirik> .fesco 544
18:12:56 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544
18:13:12 <nirik> we have a list of 68 services that currently start by default.
18:13:50 <nirik> we have spot's page as a guideline start: https://fedoraproject.org/wiki/User:Spot/DefaultServices
18:14:29 <notting> yeah, i was going to work on this, but got distracted with fudcon and other fires
18:14:30 <nirik> how do we want to approach this?
18:14:59 * nirik looked at the list... got confused about the dbus type services in the systemd world
18:15:31 <mclasen> nirik: where's the list of 68 ?
18:15:42 <nirik> it's in the ticket. I can paste it in a better form...
18:15:42 <mmaslano> in ticket ;-)
18:15:55 <nirik> http://fpaste.org/B18Y/
18:16:12 <mjg59> For many of these applications, if the service doesn't start by default then the binaries installed by the package simply won't work
18:16:25 <mjg59> I... don't see how that would be a useful configuration
18:16:55 <mjg59> There's a few counterexamples
18:17:49 * mclasen notes that bluez installs a dbus service file with Exec=/bin/false
18:17:53 <mjg59> But hal, for instance? It's not network enabled, so it doesn't seem to be relevant to this policy at all
18:18:11 <mjg59> And ifplugd?
18:18:34 <nirik> in spot's proposal non network services could choose to start or not if they wanted.
18:18:41 <mclasen> a few other  services do the same, that seems the semi-official way to turn off autostart
18:18:43 <mmaslano> shouldn't maintainers reviewed if it's ok or not?
18:18:48 <mjg59> So is this list of 68 the list of packages that are chkconfiged on by default, rather than the list of packages that may require exceptions?
18:19:07 <nirik> mjg59: well, it depends. Do we agree to:
18:19:19 <nirik> "If a service does not require configuration to be functional and is not network enabled, it may be enabled by default (but is not required to do so). In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away") and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of "runs once then goes away" services include iptables and udev"
18:19:40 <nirik> if we agree with that, we can remove a number from this list on that basis.
18:19:46 <mjg59> I would say I agree to that, but further I would agree to network daemons that only bind to localhost by default
18:19:58 * nirik notes you can't disable bluez except by removing it.
18:20:26 <mjg59> nirik: You can disable bluetooth
18:20:42 <mjg59> Difficult to present an attack surface if there's no radio listening...
18:20:59 <nirik> I'd love to hear how in the rawhide systemd world. ;)
18:20:59 <mclasen> I wonder how much sense it makes to have a guideline entirely on a package basis, without looking at whats installed by default or not
18:21:33 <mjg59> Anyway, as I said, I broadly agree with spot's guidelines
18:21:40 <mjg59> I think we could easily go further than that
18:21:51 <nirik> systemd has no way I can find to disable/enable dbus based services, they are just there and will be enabled when something wants them.
18:21:53 <mjg59> Our default configuration right now is that everything's firewalled unless explicitly not firewalled
18:22:13 <mjg59> So if I have to chkconfig something on, and *also* unblock the firewall, that's a technological failure
18:22:28 <notting> right, but that's being worked
18:22:30 <mjg59> Either we don't need off by default or we don't need blocked by default
18:22:53 <mjg59> notting: Yeah. Just noting that right now the objectives of this seem to be achieved even without changing anything.
18:23:12 <mjg59> What's our feeling on "network enabled and only bound to loopback"?
18:23:36 <skvidal> mjg59: isn't there room for wanting something installed on the system but off and not going to run automatically when something wants it?
18:23:47 <nirik> it could represent a local vulnerability if it needs config to secure/set it up.
18:23:48 <mjg59> skvidal: No
18:23:55 <mjg59> Uninstall it
18:23:58 <skvidal> mjg59: I can think of a fair number of things that I want off until I explicitly need them, - not just when something happens to probe a port
18:24:09 <mjg59> skvidal: So either don't install, or turn it off
18:24:32 * nirik has httpd on his laptop, but off most of the time. Only start it when I need to test something or have someone hit something here.
18:24:35 <skvidal> is that fesco's decision?
18:24:47 <skvidal> ie: has that decision been made as policy for the distro?
18:24:52 <nirik> skvidal: no.
18:24:53 <mjg59> skvidal: No
18:25:09 <mjg59> It's also not clear whether that should be fesco's role, or whether it falls to the packaging committee
18:25:28 * skvidal will be eager to learn whose decision it is.
18:25:30 <nirik> well, we asked packaging to look at what services should start by default, but they pushed it back to us. ;)
18:26:00 <mjg59> nirik: If a non-network daemon (local sockets, for instance) starts by default then it still presents a potential security issue
18:26:01 <nirik> They said: "Decide whether FPC or FESCo makes the list (b/c some thought this was an expansion of fpc's charter while others thought that it was within FPCs charter and additionally FESCo had agreed to hand it to FPC several meetings back)."
18:26:23 <mjg59> nirik: So really I'm not convinced that it's an issue if it only binds to loopback
18:26:29 <mjg59> But this is probably a fairly niche case
18:26:32 <notting> should we just task ourselves with evaluating the list of current start-by-default things in light of spot's draft?
18:26:39 <nirik> in the interests of avoiding a back and forth, I think fesco should decide.
18:26:59 <mjg59> notting: I guess, but we need to start by discarding everything on that list that doesn't listen to the network - which looks to be most of them
18:27:07 <tibbs> I wanted to point out that "network enabled and only bound to loopback" exposes still exposes those daemons to attack by local users or by exploitable code run by local users.
18:27:19 <nirik> I like spot's draft in general... perhaps we could sort the list into things that we need to look at and things that are excepted by the proposed policy
18:27:20 <skvidal> mjg59: it's not just about security - it can also be about resource and power use
18:27:34 <mjg59> tibbs: Yes, as is also the case with anything that's running but not network-enabled
18:27:37 <skvidal> mjg59: I may want something installed for the handful of times i need it but never to come on unless I explicitly want it on
18:27:44 <skvidal> mjg59: for power use cases and for memory-use
18:27:56 <mjg59> skvidal: That's what swap's for
18:28:04 <skvidal> mjg59: not all systems have swap
18:28:05 <mclasen> but you can easily turn them off after installing them...
18:28:08 <skvidal> mjg59: olpc comes ot mind
18:28:14 <nirik> mclasen: in some cases. ;)
18:28:15 <mclasen> since you are willing to turn them on and off all the time anyway
18:28:29 <skvidal> mclasen: how do you turn off dbus-using services?
18:28:46 <mclasen> if you can't turn them off, there's no point discussing if they should be initially turned off, I'd say ...
18:28:59 <mjg59> skvidal: Daemons that consume power when not being actively used are buggy, and the answer there is "Fix the software", not "Mandate that software not start"
18:29:22 <nirik> there are lots of corner cases...
18:29:29 <skvidal> mjg59: so by not loading bluetooth, for example, I don't pull that module in
18:29:34 <skvidal> mjg59: that module burns power for me
18:29:44 <skvidal> ditto with various other components
18:29:47 <nirik> but lots of obvious things we shouldn't allow either.
18:29:49 <mjg59> skvidal: Uh. I think you're misunderstanding hardware here, to a large extent.
18:30:02 <mjg59> skvidal: If you want bluetooth powered down fully then you need to load the module
18:30:06 * nirik points to freenx-server. Which you need to setup a bunch to work.
18:30:08 <mjg59> skvidal: Then you disable bluetooth
18:30:13 <skvidal> mjg59: I'm going by powertops estimate
18:30:23 <mjg59> skvidal: I understand this better than powertop does
18:31:19 <nirik> so, how about we get 1-2 people to sort thu the list and present us with the ones we need to decide on based on the proposed policy?
18:31:22 <notting> <15 minutes ding>
18:31:35 <mjg59> nirik: Sure
18:31:40 <notting> is the proposed policy we're referring to the one spot has in the ticket?
18:31:46 <mjg59> notting: Yes
18:31:48 <nirik> notting: yeah, I was at least.
18:31:52 <notting> as what FPC actually ratified wasn't a policy at all
18:32:05 <nirik> they didn't ratify anything I don't think...
18:32:12 <nirik> just passed what they had back to us.
18:32:13 <mjg59> I'll pull out anything that isn't permitted by spot's proposal and I'll group them by different categories
18:32:15 <notting> they ratified a SEP field
18:32:26 <mjg59> I think everything that's permitted by spot's proposal makes sense
18:32:46 <notting> mjg59: i can help with the weeding if you'd like
18:32:47 <mjg59> Does anyone think that's unreasonable?
18:32:55 <mjg59> notting: Yeah, it's not a big list
18:33:02 <mjg59> I'll let you know
18:33:39 <nirik> it might be good to keep those items in a seperate list... ie "here are things that are one-shot or etc, so don't need an exception"
18:34:20 * nirik is happy with that plan. Any other thoughts? or should we move on for now?
18:34:35 <notting> i.e., sort the permitted things by why they're permitted?
18:34:53 <nirik> yeah.
18:35:12 <nirik> or sort the things which are set to start by default into why they are allowed to do that.
18:36:33 <nirik> #action mjg59 and notting will work on the list and sort thru it for next time.
18:36:55 <nirik> #agreed we mostly like spot's draft and will look at the list next time for exceptions that are needed.
18:37:05 <nirik> #topic #550 F15Feature: Indic Typing Booster - http://fedoraproject.org/wiki/Features/IndicTypingBooster
18:37:05 <nirik> .fesco 550
18:37:06 <zodbot> nirik: #550 (F15Feature: Indic Typing Booster - http://fedoraproject.org/wiki/Features/IndicTypingBooster) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/550
18:37:16 <nirik> This was deferred from last time.
18:37:38 <nirik> answers on the talk page: http://fedoraproject.org/wiki/Talk:Features/IndicTypingBooster
18:38:23 <notting> forks. whee.
18:38:52 <nirik> yeah, thats not great. ;(
18:39:41 <notting> although it seems reasonable why they'd fork if they're going to end up breaking chinese support
18:39:43 <nirik> other than that I guess I am +1... I wish they would have found a non forky way.
18:40:23 <tibbs> Does that mean you can't have both Chinese and Indic ibus installed at the same time?
18:40:34 <mjg59> I think that would need to be checked
18:40:46 <tibbs> Because I can't imagine that would be acceptable.
18:40:48 <nirik> I would hope thats not the case.
18:40:56 <mjg59> Guess we should ask that
18:41:09 <notting> tibbs: the implication is that chinese and indic used to both use ibus-tables; they're forking ibus-tables for indic.
18:41:20 <notting> the appearance is that you could have both installed
18:41:45 <nirik> it's not already a approved package tho it seems
18:42:48 <nirik> or I am looking in the wrong named.
18:42:50 <nirik> names
18:44:41 <notting> in any case, +1
18:44:42 <nirik> so whats the name of that forked package? is it in the same package as the feature?
18:45:38 <nirik> so:
18:45:42 <nirik> .bug 666517
18:45:43 <zodbot> nirik: Bug 666517 Review Request: scim-typing-booster - Indic Typing Booster Table IMEngine for SCIM - https://bugzilla.redhat.com/show_bug.cgi?id=666517
18:45:51 <nirik> .bug 666520
18:45:53 <zodbot> nirik: Bug 666520 Review Request: ibus-typing-booster - Indic Typing Booster Table IMEngine for ibus - https://bugzilla.redhat.com/show_bug.cgi?id=666520
18:46:01 <nirik> both approved, but they forgot to set fedora-cvs.
18:46:15 <mjg59> Ah, ok
18:47:16 <nirik> so, anyhow, +1, but we should make sure there's no conflicts with packages.
18:47:59 <nirik> any other votes/comments?
18:48:23 <mjg59> +1 assuming no conflicts
18:49:09 <SMParrish> +1
18:49:12 <mclasen> +1
18:49:40 <nirik> #agreed Feature is approved
18:49:48 <nirik> #topic Open Floor
18:49:54 <nirik> Anyone have anything for open floor?
18:51:07 <mjg59> Not me
18:51:14 * nirik doesn't.
18:52:16 * nirik will close out in a minute if nothing else comes along.
18:52:46 <nirik> ok, thanks for coming everyone!
18:52:51 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110202/1f5e9d93/attachment.bin 

More information about the devel mailing list