17:02:00 #startmeeting FESCO (2012-07-09) 17:02:00 Meeting started Mon Jul 9 17:02:00 2012 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:12 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 17:02:12 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 17:02:21 hallo. 17:02:23 #topic init process 17:02:27 Hello 17:02:27 mjg59 said he'd be a few minutes late. 17:02:57 hi there 17:02:58 Hello everyone. 17:03:24 Here 17:03:26 * notting is here, sorry about that 17:03:50 seems that we have quorum 17:04:14 mmaslano is on holidays afaik 17:04:18 not sure about mitr 17:05:10 and limburgher 17:06:01 OK, let's start with old tickets 17:06:30 #topic #861 Cleanup of maintainers with bugzilla account issues 17:06:31 .fesco 861 17:06:32 t8m: #861 (Cleanup of maintainers with bugzilla account issues) – FESCo - https://fedorahosted.org/fesco/ticket/861 17:06:37 ok, I have some info on this... 17:06:55 I forgot that I was going to still be out of town on the 2nd, so I wasn't able to do anything then. 17:07:07 I mailed everyone again and sent a thing to the devel list on friday. 17:07:24 we are down to 72 issues now (from a high of about 190) 17:07:49 I can do the orphaning today, or we could wait longer. There was a bit of response on the devel list... 17:08:04 2 folks that said they contacted people on the list to fix things. 17:08:47 so, I'm happy to do the orphaning/cleanup later today, or wait longer if we think it will help out. 17:09:41 we still have a ways before we branch, right? 17:09:47 since we're doing the usual orphan blocking before we branch, orphaning sooner (for some value of sooner) is probably better to get more people to pick things up 17:09:51 jwb: ~1 month 17:09:54 yep. 17:10:04 I don't care much either way, but given the mail on devel list was sent on Friday when it was supposed to be mailed on Monday you might delay the orphaning to Friday as well 17:10:07 notting, right. i'd say wait until friday, then orphan 17:10:26 i doubt e.g. nasrat is going to suddenly rejoin fedora but one can always hope 17:10:37 hehe 17:10:59 t8m: monday was supposed to be the 'orphan day' 17:11:14 * nirik has been mailing people weekly for a long time now. 17:11:23 nirik, this monday or last monday? 17:11:42 nirik, ok, i changed my mind. just orphan them 17:11:56 in https://fedorahosted.org/fesco/ticket/861#comment:13 we agreed to a 2012-07-02 deadline. 17:12:04 I was still away from the internets then. 17:12:15 nirik, OK then go ahead and orphan 17:12:39 it's been about 7 weeks since I started poking people. Happily it has been cleaned up a lot since then... 17:13:08 * nirik is fine either way. Getting it done today is good for me too. 17:13:49 votes? 17:14:07 nirik, I don't think we need voting as we voted already? 17:14:16 +1 to whenever (today is included in that) 17:14:17 true, ok. 17:14:24 * nirik will just do it later today. 17:15:16 #action nirik will orphan the remaining packages with bugzilla account issues today 17:15:36 #topic #868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo 17:15:37 .fesco 868 17:15:38 t8m: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868 17:15:59 * dsd_ is here 17:16:36 I don't think there's a way to disable this just for one consumer. 17:16:56 i don't really think there needs to be 17:17:01 only in image postprocessing 17:17:03 So basically we were asked to revoke our decision to accept this feature because of OLPC 17:17:45 Specifically 1.0, right? 17:17:48 This isn't a problem on 1.5 17:18:14 its a bigger problem on 1.0, but its a problem all round, and not just for OLPC (in my eyes) 17:18:17 yeah, honestly - too bad the old one is old 17:18:39 dsd_: We decided we were fine with the increase in disk usage 17:18:45 dsd_: in the sense that the problem is "all round", I think that was covered in the initial discussion before we voted on it the first time. 17:18:51 It's not clear why we'd want to discuss that again. 17:19:20 did anyone represent small systems that time around? 17:19:23 "This thing that you voted for on the understanding that it increased disk usage turns out to increase disk usage" isn't a *hugely* compelling argument for revisiting it 17:19:33 dsd_: yes 17:19:48 ok 17:19:51 well, I think the thought was "this increase of disk usage is impacting OLPC, did you consider that?" 17:20:02 nirik: Well, it impacts everyone 17:20:08 sure. 17:20:13 mjg59, but someone more than others 17:20:17 It just turns out that OLPC is plausibly the most resource constrained device we care about at all 17:20:41 my thinking was only that it has no OLPC-specific impliciations other than the fact we ship a small disk. and we cant be the only fedora consumer with a small disk 17:20:43 I'm just suggesting thats why we were asked to revisit it and see if this information changes anyones thoughts on it. 17:20:44 Eventually XO-1.0 isn't going to be a viable Fedora target 17:20:56 The question is just whether we're ok with that happening sooner or later 17:20:59 mjg59, or it can be said that if you're not too resource constrained it doesn't impact you much 17:21:23 But overall, Fedora isn't a great choice for highly resource-constrained devices 17:21:36 We make a bunch of design decisions without that being a significant concern 17:21:39 dsd_: two full desktops? 17:21:45 I'd probably change my vote to -1 as I was not too fond of the feature before anyway. 17:21:46 dsd_: what's the other one? 17:21:51 sugar and gnome-fallback 17:22:25 well, upstream gnome is solving that problem of two desktops for you 17:22:38 Chances are that by F19 we'll have gained another 43MB for you anyway 17:22:48 * nirik continues to be -1 on it as before, but thats only -2. ;) 17:22:55 mjg59, for? 17:23:08 Proposal: Let's not re-address this since there's actually no new information 17:23:18 jwb: For extra code in core packages 17:23:36 mjg59, oh, just the general software growth problem 17:23:46 dsd_: I don't think there's any benefit in revisiting this on the basis of resource constraints unless that's part of a significant overall goal of reducing Fedora's disk use 17:24:08 mjg59: in which case it should be a new, separate feature about reducing disk space 17:24:09 hm. sugar at least would be less affected by this than gnome/kde/xfce/etc 17:24:10 dsd_: We can go back on this and you get some space back. But what's your long-term plan? 17:24:22 pjones, by dropping minidebuginfo information? 17:24:24 :] 17:24:46 long term plan for what? 17:24:49 t8m: Well, I wouldn't vote yes to that, but if you're proposing a "make it smaller" feature, that's a thing you /could/ include. 17:25:00 dsd_: for when the code you're shipping just gets to big to fit 17:25:31 i guess we;d have to ditch fedora if that became true :/ 17:25:39 but in recent years it has been pretty constant 17:25:42 dsd_: The software we ship is getting larger over time 17:26:06 i.e. beyond F11 we havent changed that much 17:26:35 #proposal Drop the minidebuginfo feature because of the OLPC being overly affected by it 17:26:41 -1 17:26:45 +1 17:26:49 -1 17:26:56 17:27:10 -1 17:27:56 (well, I am -1 to the feature, but not simply due to OLPC, so I guess count me +1 here 17:28:14 But I'd be in favour of a feature that looked at the entire distribution and identified areas that could be trimmed down 17:28:23 as would i 17:28:23 i wouldnt say we're overly affected, and the main thing i was wondering is if you'd reconsider the point that it doesnt have an easy/clean on/off switch (right?) 17:28:44 notting, you're the potential deciding vote here 17:28:51 example: xorg server package gained 20k in compressed size, for a delta of 1.5%. geode driver gained 40 bytes ,for percentage diff of 17:29:16 notting: Over what timescale? Does that include us changing compression method? 17:29:28 jwb, we're done with this topic as we won't find enough votes for revoking this feature 17:29:49 mjg59: last build before minidebuginfo landed in rawhide. a few months in the geode case, a week or two in the server case 17:29:52 t8m, but if notting votes +1 to your proposal, we tie and need the missing members to weigh in 17:30:03 notting: Ah, that's the increase due to minidebuginfo? 17:30:15 Sorry, was thinking that was F11->now 17:30:31 jwb, I thought that the +5 in the meeting is what counts 17:30:40 mjg59: yes 17:30:41 then why did you make another proposal? 17:31:04 digikam looks to be ~1.8% bigger compressed as another example 17:31:23 jwb: I believe features need +5 rather than simply a majority of those present 17:31:27 i am -1 to reverting 17:31:51 Let's go ahead with another topic then. 17:31:59 #topic #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals 17:32:00 .fesco 873 17:32:01 t8m: #873 (F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals) – FESCo - https://fedorahosted.org/fesco/ticket/873 17:32:02 and i am willing to help any and all dependency chain pruning to help shrink images where necessary 17:32:20 its understandable if this goes ahead 17:32:31 but could someone at the very least write and test the "give me my space back" script? 17:33:06 we'd appreciate a contribution like that, yes 17:33:06 dsd_: what would be in such a script? 17:33:23 dsd_: perhaps ask notting out of band since he offered to help? 17:33:26 dsd_: you mean for stripping the minidebuginfo from your image post rpm-install pre-squashfs-ing (or whatever)? 17:33:33 notting: yes, something like that 17:33:42 dsd_: sure, will do 17:33:46 thanks 17:35:16 this discussion died down on the list, didn't it? 17:35:29 so where are we on this one? I saw some discussion on list, but not sure it was definitive... 17:35:43 more less - there were some proposals to work with openssh upstream and so on 17:36:07 I think what was definitive was the rejection of the profile.d file solution 17:36:12 mangling the $TERM 17:37:04 in the absence of that, do we have a viable feature proposal? 17:37:15 Not currently 17:37:23 I think the feature proposal is not meant to use this file 17:37:29 so the main issue was: should this happen in a) profile, or b) vte or some lower level... ? 17:37:38 They want to change the default in the terminals. 17:37:51 The script is only a quick hack for testing. 17:38:03 "For quick testing and development you can also use this /etc/profile.d/256color.sh file. That keeps the config central, and set things up in a standard way such that LS_COLORS will be set appropriately. " 17:38:07 citing the feature page 17:38:27 "This will be mainly configuration changes. After some discussion it was thought best to update each terminal to adjust the TERM environment variable, to indicate that 256 colors are supported." 17:38:40 So i think we can tentatively accept it. 17:38:50 I am +1 to the feature. 17:39:28 * nirik is fine with it. +1. I'd ask feature owners to work with terminal maintainers and/or vte/vte3, etc maintainers to make sure everything is done. 17:39:54 It's still a problem 17:40:08 It doesn't deal with the ssh case 17:41:38 well, so we defer this and say 'get it working with ssh' ? 17:41:49 mjg59: in which way? 17:42:00 mjg59, ssh could be patched to drop the -256color suffix from $TERM 17:42:03 mjg59: will try and pass a term not supported on the remote side? 17:42:23 notting: Yes 17:42:51 t8m: That's a pretty gross hack, and would break any existing setups where people have manually configured this 17:43:04 I don't have a good solution 17:43:15 The question is really just whether this is worth the pain it'll cause some users 17:43:22 mjg59, I suppose it would have to be configurable 17:44:18 but I don't really see any other way - we always had the problem with remote end not knowing the terminal we use 17:45:56 historically, have we used less-than-standard $TERM values for anything? 17:46:07 Don't /think/ so 17:46:23 how old does xterm-256color go? 17:46:25 Back in the dark ages Debian used xterm-debian because of subtly different backspace/delete handling 17:46:28 And that was miserable 17:46:42 notting: My understanding is that current Debian stable doesn't know xterm-256color 17:47:04 So I'd guess it's a loss on all legacy Unix 17:47:16 ... ? 17:47:24 debian stable doesn't? heck, rhel5 has it 17:47:31 exactly how old is debian stable? 17:47:33 yeah, rhel5 works here. 17:48:46 Ah, sorry, my misunderstanding 17:48:48 "Debian for example traditionally didn't support xterm-256color unless the ncurses-term package was installed." 17:48:51 even rhel4 has it 17:49:05 * notting runs out of ancient machines to ssh into 17:49:25 Debian stable is newer than rhel 6. How far back do you need to look? 17:49:43 Nothing on my Debian system actually depends on ncurses-term 17:50:07 So it's not necessarily "Can this platform be made to support it", it's "Does this platform support it by default" 17:50:12 so 1) systems that split up their terminfo db somewhat arbitrarily 2) really ancient unix 17:50:23 Yeah 17:50:30 i'm inclined to +1 17:50:42 * nirik thinks those people can just reset it for their old machine use case. 17:50:52 since we're off staring at obscure stuff, does this work with *BSD? 17:51:06 http://marcoschuh.de/wp/?p=873 makes it sound reasonably widespread 17:51:15 * pjones is also leaning towards +1 17:52:36 Given Apple's use of it by default I suspect that the rest of the world will catch up quickly 17:52:50 The only reason I'm cautious is that it doesn't give a huge benefit and it's going to result in some loud complaining 17:53:12 But eh that's probably not going to rate given how much other complaining I'm dealing with, so +1 17:53:30 Heh 17:53:32 Yeah, I don't think that's going to peak above the noise floor tbh :) 17:54:13 I'm counting +5 if the above tentative votes are counted 17:54:17 +1 17:55:00 t8m: yeah, okay. 17:55:04 notting, ? 17:55:19 +1, thought i said that 17:55:32 notting, well it was not really clear to me 17:55:34 :) 17:56:15 #agreed The 256 Color Terminals feature is approved (+1:5 0:0 -1:0) 17:56:34 #topic #880 Timing of FESCo Elections 17:56:34 .fesco 880 17:56:35 t8m: #880 (Timing of FESCo Elections) – FESCo - https://fedorahosted.org/fesco/ticket/880 17:57:32 I'm fine with the idea of moving it to be better aligned with others. 17:57:48 not to be a complete wet blanket, but i really don't care one way or another 17:57:52 I'd say whoever wants to change things should propose dates and we could ack/nack? 17:58:16 i have no opinion on the topic 17:58:23 I don't really care much about the FESCo elections timing. Although it would make sense to me to have the timing so all the features for the release that the elected FESCo will be taking care of are approved by the newly elected FESCo 17:58:51 nirik, +1 18:00:11 Yeah, I can't really bring myself to care. 18:00:26 so, +1 to nirik's semi-proposal 18:01:01 nirik: +1 18:01:43 +1 to nirik's proposal 18:02:20 * nirik is fine with it too... not surprisingly 18:02:29 +1 18:02:58 #info The current FESCo does not have any strong opinion on the election date change if you want to please propose a concrete change of the date to be voted on. 18:03:32 Do we want to discuss the feature tickets that were submitted today? 18:04:02 There are some uncontroversial ones, some maybe not. 18:04:16 i've got time 18:04:24 * nirik is fine either way 18:04:41 I'm fine at least with the uncontroversial ones for today. 18:05:15 out of curiosity, how long is the fesco meeting supposed to go for? 18:05:57 undefined 18:06:03 though I think we reserve 2 hours? 18:06:06 I think we mostly finish by 2 hours 18:06:32 #topic #882: F18 Feature: CIM Management - https://fedoraproject.org/wiki/Features/CIMManagement 18:06:38 .fesco 882 18:06:39 t8m: #882 (F18 Feature: CIM Management - https://fedoraproject.org/wiki/Features/CIMManagement) – FESCo - https://fedorahosted.org/fesco/ticket/882 18:07:25 +1 - pretty uncontroversial as it is more of the advertisement type 18:07:43 i'd really prefer that we pick one cimom and standardize on it 18:07:56 notting, agreed 18:08:15 sure, +1. Dunno how many people will be excited by it, but ok 18:08:17 i was under the impression that sblim was the current trend there 18:10:14 as a self-contained feature, sre, +1 18:10:39 +1 with the suggestion of standardizing on one cimom 18:11:08 yeah +1 18:11:26 mjg59, ? 18:11:35 +1 18:12:25 #agreed CIM Management feature is approved (+1:6 0:0 -1:0) 18:12:40 #info Please consider standardizing on one CIMOM. 18:13:03 #883: F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework 18:13:11 #topic #883: F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework 18:13:17 .fesco 883 18:13:19 t8m: #883 (F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework) – FESCo - https://fedorahosted.org/fesco/ticket/883 18:13:29 This one is more intrusive. 18:13:50 but looks like a nice cleanup 18:14:27 Yeah, I'm +1 18:14:47 yes, +1 18:14:48 +1 here. It may be difficult for some dm's that aren't very active to get the correct changes for vt1, etc, but thats life 18:15:00 this depends on presets, no? shouldn't we adopt that first? (did we?) 18:15:00 +1 18:15:20 I wonder what happens if you have multiple dms installed and then you remove the package with the default one, will some else be picked up? 18:15:53 notting: good question. I think we defrred them in the past? /me looks 18:15:56 t8m: from my understanding of the implementation, not afaik 18:16:24 https://fedoraproject.org/wiki/Features/PackagePresets 18:16:26 notting, that's how I understood it too. Not sure if that's a big loss though. 18:16:44 but at least it should be clearly documented 18:18:15 I propose we defer this until the Presets are accepted. 18:18:38 thats fine with me. 18:21:05 Sure 18:21:47 #info Decision on this feature is deferred till the PackagePresets feature is accepted. 18:22:15 #topic #884: F18 Feature: Fontconfig 2.10 - https://fedoraproject.org/wiki/Features/Fontconfig2.10 18:22:19 .fesco 884 18:22:20 t8m: #884 (F18 Feature: Fontconfig 2.10 - https://fedoraproject.org/wiki/Features/Fontconfig2.10) – FESCo - https://fedorahosted.org/fesco/ticket/884 18:22:35 +1 18:22:46 sure, +1 18:22:50 +1 18:22:59 +1 18:23:04 +1 18:23:05 +1 18:23:29 the bit about the config files moving might be irritating, but *shrug* 18:23:37 #agreed Feature Fontconfig 2.10 is approved (+1:6 0:0 -1:0) 18:24:57 #topic #886: F18 Feature: Rails 3.2 - https://fedoraproject.org/wiki/Features/Rails_3.2 18:25:01 .fesco 886 18:25:02 t8m: #886 (F18 Feature: Rails 3.2 - https://fedoraproject.org/wiki/Features/Rails_3.2) – FESCo - https://fedorahosted.org/fesco/ticket/886 18:25:49 I thought rails needed mod_passenger... 18:25:55 * nirik is probibly just confused. 18:25:58 hehe :] 18:26:01 does this break any packaged rails apps? 18:26:28 "all the packages from the Rails stack are dependencies of other cca 50 packages. These will have to be rebuilt and possibly updated." 18:26:44 Enterprise ready 18:26:51 LOL 18:27:08 but +1 anyway 18:27:19 i wonder what 8 Gems packages will have to be reviewed and included 18:27:33 yeah, would be good to update the page with the specific packages mentioned. 18:28:08 i'm fine to doing the upgrade, so +1. just concerned that apps might break 18:28:18 +1 18:28:51 +1 with the suggestion of updating the page with more specifics and possibly using a koji buildtag for it 18:28:54 +1 in any case 18:29:32 +1 18:30:02 #agreed Feature Rails 3.2 is approved (+1:6 0:0 -1:0) 18:30:40 #info Please mention the specific packages that need to be updated and added on the feature page. 18:31:30 #topic #887: F18 Feature: Perl 5.16 - https://fedoraproject.org/wiki/Features/perl5.16 18:31:37 .fesco 887 18:31:38 t8m: #887 (F18 Feature: Perl 5.16 - https://fedoraproject.org/wiki/Features/perl5.16) – FESCo - https://fedorahosted.org/fesco/ticket/887 18:32:13 +1 18:32:18 ack. +1 18:32:20 +1 18:32:22 didn't they start building this already? 18:32:29 another fedora, another perl. ;) +1, but it would be nice if this was announced before the mass building had started. 18:32:34 yes. 18:32:45 aside from me wanting perl removed entirely, +1 18:33:20 pjones, ? 18:34:09 +1 18:34:12 #agreed Feature Perl 5.16 is approved (+1:6 0:0 -1:0) 18:34:55 #info Please announce the Perl version upgrade rebuild before starting rebuilding next time. 18:35:29 #topic #885: F18 Feature: PowerPC ppc64p7 subarch support in rpm and yum and in packages - https://fedoraproject.org/wiki/Features/Power7Subarch 18:35:33 .fesco 885 18:35:34 t8m: #885 (F18 Feature: PowerPC ppc64p7 subarch support in rpm and yum and in packages - https://fedoraproject.org/wiki/Features/Power7Subarch) – FESCo - https://fedorahosted.org/fesco/ticket/885 18:35:41 hi, I'm here. 18:36:03 Not really sure why this needs a feature, but nevertheless I'm fori t. 18:36:04 for it 18:36:27 pjones: it touches a few things that could affect primary (e.g. mash, rpm & yum) 18:36:28 Only one quibble 18:36:43 The notes might make it clearer that it's as a scondary arch? 18:37:04 mjg59: sure, can do 18:37:18 Right now I think I'd read that and think it was primary 18:37:29 mjg59: er... not sure why that matters to adding yum and rpm support 18:37:37 mjg59: you mean release notes, right? 18:37:39 pjones: It doesn't 18:37:40 dwa: Right 18:37:46 pjones, features get added to the PR stuff 18:37:46 +1 here. 18:38:00 jwb: Looking forward to that new feature process 18:38:05 mjg59: nod. We wouldn't necessarily have to include it in the primary release notes either 18:38:13 but I'll update them regardless 18:38:23 mjg59, as PPC is secondary and this is just subarch I think it is implicit 18:38:27 are you building everything as it, or just some things? 18:38:34 notting: just some things 18:39:02 notting: we've got a list with notes at https://fedoraproject.org/wiki/Ppc64p7subarch 18:39:16 +1 with the caveat mjg59 added 18:39:20 the mailers??? 18:39:42 i ... did not know they were ever cpu bound 18:40:07 also pam does not seem to me to be perf critical either 18:40:13 notting: heh. I can get specifics from IBM if you're curious - the packages they suggested apparently have significant gains. *shrug*. 18:40:22 i would add xz to that list if you're already doing zlib and bzip, given that every RPM is xz compressed 18:41:28 pp64 app can use pp64p7 lib,right? 18:41:42 wait, that's a silly question, of course it could 18:41:46 +1 anyway 18:41:50 in any case, sure, +1. 18:41:51 notting: we'd still build ppc64 versions of everything 18:42:05 notting: so it'd be like i686 & i386 way back when. 18:44:31 pjones, mjg59, ? 18:44:44 Already said I'm fori t. 18:44:46 for it. 18:44:53 Even made that same typo the first time. 18:44:53 +1 18:46:48 pjones, I'm sorry I overlooked it 18:47:19 #agreed Feature PowerPC ppc64p7 subarch support in rpm and yum and in packages is approved (+1:6 0:0 -1:0) 18:47:36 thanks guys. 18:48:04 I am not sure we want to discuss the SecureBoot feature as the Board still did not vote on it? 18:48:22 Yeah, I think we're still waiting for them to do something other than talk about it 18:48:28 yeah, probibly defer 18:48:55 #topic Next week's chair 18:48:56 did we just stop? 18:49:09 sigh, ignore that. wrong tab 18:49:19 Anybody wants it? 18:49:21 presets aren't specifically filed as a feature yet? 18:49:42 i'll take chair 18:50:02 notting, it seems that the page is still in FeaturePageIncomplete 18:50:20 #info notting will be the next week's chair for FESCo 18:51:02 #topic Open Floor 18:51:09 anything? 18:53:02 * nirik has nothing. 18:53:15 I'll close the meeting if nothing appears in one minute. 18:55:23 Quick question? 18:55:34 go ahead 18:55:41 What, exactly, are you looking to get out of the board? 18:55:57 There's been discussion, yes, but I'm still unclear about what it is you folks are wondering. 18:56:14 gholms: well, if the Board feels that they need to approve the feature instead of us? 18:56:16 For secure boot? An agreement that we can go ahead with a shim signed by the signing service and still be Fedora? :) 18:56:17 Just a stance from a political/freedom standpoint? 18:56:23 Ok 18:56:28 I mean, it seems like that's what they're saying they want 18:56:40 if they don't feel the need to do that, we can cover it from a technical perspective without it 18:56:55 so either their okay or their statement of opting out of making that decision :) 18:56:56 gholms, exactly what pjones said 18:57:08 Alrighty. Thanks. 18:57:31 * t8m will opt out of acking the feature if board opts out of making that decision though :) 18:57:37 I'd just hate to participate in a board discussion about this and come up with a completely irrelevant resolution. 18:59:04 I'll close the meeting if nothing appears in one minute. 19:00:32 #endmeeting