===================================
#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-...
.
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