=================================== #fedora-meeting: FESCO (2013-03-27) ===================================
Meeting started by t8m at 18:02:10 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-03-27/fesco.2013-03-27-18.02.log.html . Meeting summary --------------- * init process (t8m, 18:02:19) * #896 Refine Feature process (t8m, 18:03:35) * AGREED: The merged template for Change proposals is approved as per jreznik's proposal. (t8m, 18:26:44) * #1103 Release names should not include shell metacharacters (t8m, 18:33:09) * AGREED: Release name must not contain any shell metacharacters. (+5, -3, 0:1) (t8m, 19:05:24) * ACTION: pjones will reopen bug #923462 (t8m, 19:08:42) * ACTION: t8m will update the naming rules (t8m, 19:10:02) * Next meeting time (t8m, 19:10:57) * AGREED: FESCo meeting will continue to be at 18:00 UTC on Wednesdays (t8m, 19:19:58) * Next week chair (t8m, 19:20:10) * ACTION: sgallagh is the next week chair (t8m, 19:21:12) * Open Floor (t8m, 19:21:24) * LINK: https://fedorahosted.org/fesco/ticket/1104 - do we just redirect to FPC? (mitr, 19:23:49) * LINK: https://fedorahosted.org/fpc/ticket/93 (nirik, 19:25:58) Meeting ended at 19:35:34 UTC. Action Items ------------ * pjones will reopen bug #923462 * t8m will update the naming rules * sgallagh is the next week chair Action Items, by person ----------------------- * pjones * pjones will reopen bug #923462 * sgallagh * sgallagh is the next week chair * t8m * t8m will update the naming rules * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * t8m (63) * pjones (53) * nirik (39) * abadger1999 (38) * mitr (37) * sgallagh (19) * jreznik (17) * notting (11) * mmaslano (8) * zodbot (6) * jwb (5) * mjg59 (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ------------ 18:02:10 <t8m> #startmeeting FESCO (2013-03-27) 18:02:10 <zodbot> Meeting started Wed Mar 27 18:02:10 2013 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:18 <t8m> #meetingname fesco 18:02:18 <zodbot> The meeting name has been set to 'fesco' 18:02:18 <t8m> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:02:18 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:02:19 <t8m> #topic init process 18:02:24 <jwb> i'm kind of here 18:02:25 * nirik waves. morning everyone. 18:02:26 <mitr> Hello 18:02:27 * notting is here 18:02:28 <t8m> hi 18:02:31 <sgallagh> Hello 18:02:33 <mmaslano> hello 18:02:35 * abadger1999 here 18:02:36 <pjones> I'm mostly here - may get pulled away to deal with car insurance some more 18:03:35 <t8m> #topic #896 Refine Feature process 18:03:58 <t8m> .fesco 896 18:04:00 <zodbot> t8m: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:04:30 <t8m> So let's start with the more complicated thing 18:05:01 * jreznik is around... 18:05:05 <t8m> jreznik, do you want to start the discussion? 18:05:42 <t8m> There is the merged template for Change proposals https://fedoraproject.org/wiki/JaroslavReznik/ChangeProposalTemplate 18:05:58 <t8m> Are we OK with that? 18:06:33 <jreznik> well, as you said - I merged proposed templates by mitr - as I think it will be much more easier to ask people to fill in more details when change is escalated to system wide one 18:06:39 <notting> i think even self-contained things could stand to have some of the other fields filled in 18:06:53 <notting> how to test and documentation, for example 18:07:22 <nirik> I'm fine with the merging of templates and the bugzilla use... I'm not as clear on the change proposals. Thats autogenerated? from what? 18:07:24 <jreznik> notting: well, it's based on what was approved - docs were approved as optional 18:08:06 <mitr> notting: I'd expect docs for self-contained to mostly exist upstream, and a release note can point there. Similarly testing should primarily be upstream-focused (but that's a much weaker argument) 18:08:15 <jreznik> nirik: not sure what are you asking now 18:08:36 <nirik> sorry, the Changeset... 18:08:38 <t8m> nirik, it isn't autogenerated - it's created by the change owner 18:09:12 <jreznik> nirik: change set will be generated from change proposals using script 18:09:21 <t8m> ah Changeset will be generated from wiki 18:09:31 <jreznik> I use script even now, it wasn't manageable even for F19 by hand 18:09:42 <nirik> ok. so its just a more detailed version of the feature list page we have now? 18:10:16 <jreznik> nirik: yes, it's more detailed - I'd say the list was just a list 18:11:03 <jreznik> and I'd really like to see both change page and change set to be more central point for not only development but also docs, marketing etc. 18:11:15 <mitr> Historically in my FESCo role I've needed to consult the full list of features only once I think - the helpful feature wranglers have always provided a distilled list for FESCo meetings; so I'm fine with whatever infrastructure jreznik wants to set up for himself 18:11:26 <nirik> sure, I'm fine with doing that and adjusting it as we go if we need more/less/whatever. 18:11:33 * nirik is with mitr 18:12:26 * nirik has to step away for a sec. brb. 18:13:04 <mmaslano> I also agree with mitr. 18:13:08 <jreznik> so yes, FeatureList -> ChangeSet 18:13:36 <t8m> Anybody has any proposals that we can vote on? 18:13:37 <jreznik> and it's more about format, structure and as it will be generated, it can be always adjusted to show less/more info 18:14:18 <mmaslano> t8m: we could agree with Template or ask more questions about it 18:14:22 <jreznik> also for the rest of wikis - https://fedoraproject.org/wiki/JaroslavReznik/Changes/ (still initial version based on proposal - I'd like to avoid a lot of text and make the process more clear) 18:15:59 <t8m> #proposal The merged template for Change proposals is approved as per jreznik's proposal. 18:16:13 <nirik> jreznik: sounds reasonable to me. You might use the thing that qa is using for critera... 18:16:25 <nirik> that hides detailed stuff and gives you a high level view. 18:16:49 <mitr> I can be +1, I'd be also OK with making "how to test" universally mandatory (undecided about it) 18:17:30 <t8m> +1 to my proposal 18:17:33 <jreznik> nirik: good idea! 18:17:41 <mmaslano> +1 to change proposal 18:18:07 <sgallagh> I'm good with it. +1 18:18:39 <notting> t8m: sure, +1 18:19:05 * nirik nods. sure +1 18:19:07 <abadger1999> Just a nit: I'd move "blocks release" to the scope section and make it for all features. 18:19:24 <abadger1999> +1 to proposal with or without that change. 18:20:08 <t8m> abadger1999, afaik by definition of the self contained features they can't block release otherwise they are automatically systemwide 18:20:15 <jreznik> abadger1999: if there's possibility the change could block release - it's definitely system wide one 18:20:54 * pjones can be +1 18:21:14 <pjones> jreznik: though I think that's not necessarily true 18:21:37 <pjones> if it would block release /without consideration of pure implementation bugs/, yes. 18:22:59 <t8m> pjones, well of course anything can block release if there is serious enough bug in it, but this is rather anticipated blocking of release and that automatically implies switching the change to the system wide category 18:23:01 <abadger1999> okay, if that's the idea, I'd still move it to the scope section as contingency planning seems to be a separate issue to release blocking. 18:23:29 <jreznik> I'll take a look and talk with mitr, this part was his idea 18:24:01 <t8m> mitr, ? 18:24:31 <mitr> What t8m said - blocker bugs go through QA and we don't need to care that they are a part of a tracked change (except that it needs to be dropped from the "we did these changes in the release" list) 18:25:24 <mitr> As for whether the "Blocks release?" box belongs in Contingency or Scope, I think Contingency will make it easier for us to see the consequences but I'll go with anything, it doesn't matter much 18:26:41 <t8m> regardless of whether we move the blocks release from one part of the template to another I declare this as approved :] 18:26:44 <t8m> #agreed The merged template for Change proposals is approved as per jreznik's proposal. 18:28:03 <t8m> Anything else to vote on in regards to this topic? Or shall we move on? 18:28:36 <mitr> Move on I think 18:28:48 * mitr is wondering whether we need to individually approve every aspect of the new process at all 18:29:29 * jreznik promised to consult it with FESCo, less for approval, more for feedback 18:30:03 <t8m> jreznik, what's remaining before we can actually use the new process? 18:31:51 <t8m> jreznik neodpovida, takze asi next topic 18:32:01 <t8m> oops sorry wrong window 18:32:04 <jreznik> t8m: move template to the right place, and finish the process wiki 18:32:26 <jreznik> so I think I can make it now asap 18:32:46 <t8m> (translation for non-czech speakers jreznik does not respond so let's go to next topic) 18:33:04 <t8m> jreznik, yep 18:33:09 <t8m> #topic #1103 Release names should not include shell metacharacters 18:33:34 <t8m> .fesco 1103 18:33:35 <zodbot> t8m: #1103 (Release names should not include shell metacharacters) – FESCo - https://fedorahosted.org/fesco/ticket/1103 18:34:00 <notting> seems fairly straightforward to me: +1 18:34:10 <t8m> +1 from me as well 18:34:18 * pjones also +1 18:34:24 <mitr> I'm... disappointed with making a bug workaround up to the level of a distribution-wide policy. 18:34:27 <nirik> sure. +1 18:34:32 <mitr> 0 18:34:33 <sgallagh> -1 18:34:40 <nirik> I assume we should add this to the release name voting page if it passes? 18:34:42 * abadger1999 feels the same way as mitr 18:34:48 <pjones> nirik: yeah 18:34:50 <sgallagh> I don't think papering over legitimate bugs through policy is an appropriate solution 18:35:14 <abadger1999> but being able to use unicode characters for the same meaning alleviates that somewhat. 18:35:17 <mitr> (FWIW, I have a script running for uses of /etc/{fedora,os}-release: so far it's about 20 packages that might (not necessarily do) read the contents) 18:35:25 <pjones> even if we "fix" everything that does this now, 1) os-release is always going to be parsed by shell, and 2) the "fix" to shell to make that work is pretty terrible 18:35:40 <pjones> and 3) more uses will always show up, and 4) they'll always start wrong 18:35:47 <mitr> pjones: 2) It's pretty ordinary as correct shell programming goes 18:35:47 <pjones> it'll happen *every time*. 18:35:56 <t8m> I'm with pjones on this issue. 18:36:02 <pjones> mitr: which is a nice way of saying nobody writes shell well 18:36:16 <mitr> 5) Even if we +1 this item, we won't end up with a good specification of the files 18:36:32 <mmaslano> um, I tend to say -1. This is bad guideline 18:36:33 <sgallagh> We might as well freeze all packages now, lest an update introduce new bugs. 18:36:33 <pjones> that's true, but it's hardly a good reason to not have /any/ specification of them 18:36:53 <pjones> sgallagh: ... that's an argument for making the rule, not for not making it 18:37:08 <nirik> I don't see any reason to use those, if we want those to be in there, use the unicode version... 18:37:30 * abadger1999 votes +0 18:37:39 <pjones> yeah, it really is entirely about 1) just saying we pick other characters and making that a rule, and 2) making it so we can check up front 18:37:55 <sgallagh> Making policy because we don't want to fix real bugs is a bad precedent. 18:38:05 <pjones> this isn't that, though. 18:38:10 <mitr> sgallagh: ++ 18:38:21 <t8m> Are they "real bugs"? 18:38:31 <pjones> I'm all for fixing bugs, if it makes sense to do so. In this case the fix is worse than the problem. 18:38:37 <sgallagh> t8m: Yes. Any application that is improperly quoting their input has a bug. Period. 18:38:59 <pjones> sgallagh: that's a strange way to look at shell sourcing 18:39:28 <mitr> t8m: If the proposal were "release names shall include only characters from $certain_unicode_set", that would hide the bug as a side effect, but make some sense. A proposal to carefully avoid specific characters that are problematic in a single language, not. 18:40:01 <abadger1999> pjones: It shouldn't be sourced from the shell... it's data not executable in and of itself. 18:40:11 <abadger1999> but that's off in the weeds :-) 18:40:29 <pjones> abadger1999: nobody who looks at the file as their source of information will ever reach that conclusion. 18:40:34 <sgallagh> mitr: +1. I could get behind htat 18:40:39 <abadger1999> pjones: uhm... 18:40:55 <mitr> pjones: Using shell is a fixable implementation problem, not a legitimate problem statement. We did account for the implementation situation by an one-off hack in #1102, and I'm fine with that. Making shell a holy cow, not. 18:40:56 <abadger1999> $ cat /etc/fedora-release *[f19] (11:40:46) 18:40:58 <abadger1999> Fedora release 17 (Café Kuratomi) 18:41:03 <pjones> abadger1999: os-release, not fedora-release 18:41:09 <abadger1999> ah 18:41:12 <abadger1999> pjones: okay. 18:41:29 <abadger1999> pjones: That's not specified i nthe ticket. 18:41:44 <pjones> if you look at os-release and your first thought is "this isn't meant to be sourced in shell", you've got a very different thought process from most people writing shell. 18:42:09 <pjones> abadger1999: well, sorry, I didn't write the ticket. 18:42:12 <abadger1999> pjones: sure. but like I said, the ticket doesn't talk about os-release 18:42:23 <nirik> 'man os-release' has a 'spec' 18:42:41 <pjones> but nevertheless os-release is the canonical source for programs looking for the data contained therein 18:43:57 <nirik> could we instead of checking those characters, do some check of the spec in os-release man page? 18:44:05 <sgallagh> Yeah, the manpage for os-release expressly states that the variables have to be escaped for bash compatibility 18:44:08 <abadger1999> pjones: hmm... following hte os-release spec, sourcing the file works with quotes i nthe name. 18:44:19 <abadger1999> VERSION="schrödinger's cat" 18:44:40 <pjones> yeah, so there are two issues, 1 is a straightforward bug - we didn't quote it right. the other is the expectation that that'll happen again 18:44:42 * nirik notes checking those rules would be harder. 18:45:25 <abadger1999> If the fix can be done in os-release instead of in each application that uses it.. fixing this by policy is much less attractive to me. 18:45:44 <pjones> abadger1999: fixing it by policy is what the package maintainer asked of us when we suggested that. 18:46:03 <abadger1999> the os-release package maintainer? 18:46:07 <pjones> though tbf mjg59's fix to the package was simply not allowing those characters, rather than trying to check for proper escaping. 18:46:23 <pjones> well, it's the fedora-release package, hence your confusion above, but yeah 18:46:38 <mitr> abadger1999: Changing the spec of something that has >20 uses is not attractive to me 18:46:51 <abadger1999> mitr: what changing of hte spec? 18:46:54 <mitr> abadger1999: or do you mean just writing os-release correctly? 18:47:15 <abadger1999> mitr: correct. If just writing os-release correctly fixes things, then I think we should do that. 18:47:31 <pjones> mitr: I don't get it. If we don't emit a ' ever, how are any users of it ever going to care? 18:47:34 * nirik is with abadger1999 on that. 18:47:54 <pjones> not that I'm completely convinced just doing it right is good enough 18:48:00 <pjones> since e.g. shell programs use eval and such 18:49:10 <mitr> pjones: Specifications exist to be followed (and to clarify which of the interoperating packages is supposed to fix an interoperability problem). We have a spec that anticipates use of \'. I'm not interested in institutializing a "we might have a bug, let's restrict the set". 18:50:33 <mitr> We have enough situations where the spec doesn't exist that I don't want to spend FESCo time overriding specs that do exist. 18:50:40 * abadger1999 changes vote to -1 18:50:57 <t8m> OK it looks like we won't agree on this 18:51:03 <t8m> as I count only +4 18:51:17 <sgallagh> What do we have for explicit -1's? 18:51:36 <abadger1999> Atm 2 -1 18:51:46 <notting> ok, so "Fedora 20 ( (╯°□°)╯︵ÉɹopÇℲ )" ? 18:51:51 <abadger1999> ( abadger1999 and sgallagh) 18:52:05 <abadger1999> notting: that one isn't covered by this ticket. 18:52:07 <pjones> abadger1999: mitr was explicitly -1, mmaslano implicitly so 18:52:10 <sgallagh> notting: You have no idea how much I want that to happen now. 18:52:16 <pjones> notting: I think we're all fine with that being a bug 18:52:19 <pjones> sgallagh: zalgo. 18:52:32 <sgallagh> pjones: I was kidding (obviously) 18:52:35 <abadger1999> pjones: actually.. the opposite but you're right about the count 18:52:41 <nirik> counterproposal: ask fedora-release/interested parties to come up with a check that checks for the spec in 'man os-release' and checks against that? 18:52:47 <abadger1999> (mmaslano was explicitly -1, mitr was officially 0) 18:52:53 <pjones> or, sorry. 18:52:54 <mitr> pjones: Was I? 18:52:59 <pjones> my mistake 18:53:00 <notting> abadger1999: parentheses 18:53:04 <pjones> scrollback is being strange. 18:53:25 <mitr> I think I'll have a list of packages that might be affected ready sometime tomorrow. 18:53:32 <t8m> nirik, I can be +1 to that as well 18:53:39 <mitr> If we do want to spend FESCo time with it, why not just divide the list of packages and spend time fixing it? 18:53:40 <pjones> mitr: only for the current set, though. 18:53:48 <mitr> pjones: that's what the spec is for. 18:54:13 <sgallagh> nirik: I'm in favor of that. +1 18:54:14 <mitr> I realize ACPI and EFI and all make it sound ridiculous :) 18:54:32 <pjones> they really do ;) 18:55:21 <t8m> mitr, I don't want to spend time on fixing it I voted for limiting the character set :) 18:55:54 <abadger1999> notting: heh. In practice, we already have paranethesis in the VERSION field... just that they're something we're adding around the actual release name. 18:56:06 <nirik> I mean we could make a thing that checks the spec and have everything that consumes it call it, but really... I think we are starting to way overengineer this. ;) 18:56:32 <pjones> abadger1999: and I'll note that that has /absolutely never/ conformed with the spec 18:57:04 <mitr> pjones: Why? in F18 it's properly quoted for the shell. 18:57:09 <abadger1999> pjones: ? The example in the man page says: VERSION="17 (Beefy Miracle)" 18:57:24 <abadger1999> and on my f17 machine I have VERSION="17 (Beefy Miracle)" in os-release 18:57:41 <pjones> yeah, okay, you're right. 18:58:34 <pjones> nirik: belt and suspenders, 'eh? and shall we drop this file in /etc/verify-os-release and make /it/ sourceable? 18:59:06 <mjg59> I'll just note that the spec (to the extent that the man page is the spec) doesn't require escaping 18:59:27 <mjg59> Lots and lots of "should"s 18:59:27 <mitr> t8m: I fear that if we accept this now, we'll deserve even more curious "let's prohibit a bug" tickets in the future 19:00:15 <mitr> mjg59: the language is not RFC-like but the intent is stated clearly on the first line. 19:00:18 <pjones> you're arguing that this makes all bugs a "slippery slope". I think that's absurd. 19:00:34 <t8m> I don't really see this discussion going anywhere. 19:00:48 * abadger1999 notes that we're approaching the 30 minute mark 19:01:57 <t8m> Apparently the ticket proposal won't be approved and who wants volunteering for bug fixing the problems with shell metacharacters can do it with or without explicit FESCo "go ahead" anyway. 19:02:11 <jwb> i'm for excluding shell characters 19:02:22 <pjones> so is that +5 then? 19:02:35 <t8m> ah then that's actually +5 :) 19:03:01 <abadger1999> Probably should revote as people changed their mind during the conversation. 19:03:19 <t8m> ok then please: 19:03:30 <sgallagh> I'm sticking with -1 as the proposal is written. 19:03:35 <mitr> 0 ("-1 to having it on the agenda") 19:03:36 <nirik> what are we voting on excatly? 19:03:45 <pjones> the proposal as given 19:03:55 <t8m> #proposal Exclude shell metacharacters in the release name. 19:03:56 <pjones> +1 19:03:56 * notting is still +1 19:03:59 <t8m> +1 19:04:00 <jwb> +1 19:04:00 <abadger1999> -1 19:04:20 <mmaslano> -1 19:04:36 <pjones> nirik: you were the other plus one before... 19:05:00 <nirik> sorry, got distracted. I think this is a bit of a papering over, but still a weak +1 until a better thing comes along. 19:05:24 <t8m> #agreed Release name must not contain any shell metacharacters. (+5, -3, 0:1) 19:05:51 <nirik> so, this needs naming rules updated and a bug against systemd? 19:06:21 <pjones> why systemd? 19:06:35 <nirik> % rpm -qf /usr/share/man/man5/os-release.5.gz 19:06:35 <nirik> systemd-198-7.fc20.x86_64 19:06:41 <sgallagh> Isn't that where all bugs are nowadays? :-P 19:06:53 <pjones> the file format hasn't changed, we've just agreed to not use those characters in it 19:06:55 <nirik> or are we not changing that, just adding our own rules in fedora-release? 19:07:01 <nirik> ok 19:07:27 <pjones> so 923462 needs to be re-opened and we need a naming rules update 19:07:32 <pjones> I'll handle the former. 19:08:42 <t8m> #action pjones will reopen bug #923462 19:10:02 <pjones> yeah, that's done. 19:10:02 <t8m> #action t8m will update the naming rules 19:10:10 <nirik> I'll update the wiki page 19:10:27 <t8m> nirik, I can do it as well 19:10:37 <nirik> ok, fine with me. 19:10:39 <nirik> go ahead 19:10:57 <t8m> #topic Next meeting time 19:11:24 <t8m> Do we want to stay with 18:00 UTC or move to one hour earlier? 19:12:04 <sgallagh> I'm in favor of an hour earlier, but I don't have any problems if we stay where we are either. 19:12:07 * abadger1999 has a conflict with FPC if it's one hour earlier 19:12:26 <abadger1999> Unless a different day as well 19:12:27 * pjones doesn't care either way 19:12:29 * nirik thinks we should stay with this time 19:13:10 <notting> i'm ok with either. (may not make next week, though) 19:13:40 <mitr> So, whenisgood again? 19:13:57 <nirik> when are elections? 19:14:08 * nirik is all confused due to the f18 release being off. 19:15:08 * abadger1999 thinks elections should stay relative to the predicted f19 release schedule rather than calendar time. 19:15:36 <t8m> proposal: We stay with 18:00 UTC for now. 19:15:40 <nirik> just thinking... we do a whenisgood after each election, if we also do it at time change thats 4x a year... is that too many? 19:15:44 <nirik> +1 19:15:56 <t8m> +1 19:16:00 <mmaslano> +1 19:16:15 <notting> t8m: sure, +1 19:16:23 <pjones> is anybody against that? 19:16:36 <sgallagh> +1 19:17:06 <mitr> I'm fine with it 19:17:09 <pjones> +1 19:17:16 <t8m> jwb, ? 19:17:24 <abadger1999> +1 19:19:10 <jwb> +1 19:19:11 <t8m> jwb might have problem with the 18:00 UTC as he apparently is not around now :) 19:19:18 <t8m> heh too fast :) 19:19:26 <jwb> i'm busy trying to fix stuff, not worry about meeting times 19:19:58 <t8m> #agreed FESCo meeting will continue to be at 18:00 UTC on Wednesdays 19:20:10 <t8m> #topic Next week chair 19:20:16 <t8m> Anybody wants it? 19:20:38 <sgallagh> I can do it if no one else wants to. 19:21:12 <t8m> #action sgallagh is the next week chair 19:21:24 <t8m> #topic Open Floor 19:22:09 <t8m> Anybody anything for the open floor? 19:22:59 <sgallagh> "How do we solve meeting fatigue?" :-P 19:23:49 <mitr> https://fedorahosted.org/fesco/ticket/1104 - do we just redirect to FPC? 19:23:52 * nirik yawns, takes nap 19:24:13 <nirik> mitr: I think before they passed it to fesco... so I don't think passing it to them will work. ;) 19:25:58 <nirik> https://fedorahosted.org/fpc/ticket/93 19:27:03 <t8m> mitr, actually if I understand your comment correctly there is actually nothing to vote on this ticket as the current guidelines already ask for packages that are covered in the ticket proposal to be PIE? 19:27:14 <mitr> nirik: So FPC asked for "long running", and #1104 now asks for a subset of "long running" - perhaps FPC just needs to clarify the text (not intent) of the guideline 19:27:18 <mitr> t8m: I think so 19:27:32 <mitr> well, see above 19:28:15 <nirik> I find the ticket not very specific... also, it landed right before the meeting? shouldn't we comment in ticket and discuss next week? 19:28:27 <notting> that works for me 19:29:04 <mitr> works for me as well 19:29:22 <mitr> I was hoping for a quick "yes, move to FPC", not to have a full discussion here 19:30:14 <mmaslano> yes, please move it to fpc. We will do it next week anyway 19:30:53 <t8m> let's just discuss it next week 19:30:55 <pjones> yes, move it to fpc. 19:31:18 * nirik would be happy for their imput, but suspects they will just punt it back 19:32:07 <t8m> Anything else for open floor? If not I'll close the meeting in 2 minutes. 19:35:34 <t8m> #endmeeting -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
