Summary/Minutes from today's FESCo Meeting (2013-03-27)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



=================================== 
#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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux