18:00:00 <nirik> #startmeeting FESCO (2012-01-23)
18:00:00 <zodbot> Meeting started Mon Jan 23 18:00:00 2012 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <nirik> #meetingname fesco
18:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:00:01 <nirik> #topic init process
18:00:01 <zodbot> The meeting name has been set to 'fesco'
18:00:01 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:04 <pjones> hello.
18:00:10 <mjg59> Afternoon
18:00:11 <mitr> Hello
18:00:11 * notting is here. have to leave in 55 mins, though
18:00:24 <sgallagh> Hello
18:00:30 <nirik> we have a pile of features, then another pile of features. ;)
18:01:00 <mmaslano> hi
18:01:08 <sgallagh> nirik: Don't forget about the avalanche of features too
18:01:17 <nirik> sgallagh: oh, there might be some features too. ;)
18:01:23 <nirik> ok, lets go ahead and dive in.
18:01:27 <pjones> yeah.  and for some reason when those get filed, the urls for the part that's useful to read aren't links.  *really* annoying.
18:01:36 <nirik> from last week:
18:01:39 <nirik> #topic sponsor request - sdake
18:01:40 <nirik> .fesco 724
18:01:41 <zodbot> nirik: #724 (sponsor request - sdake) – FESCo - https://fedorahosted.org/fesco/ticket/724
18:01:45 <nirik> we tabled this last week.
18:01:51 <nirik> further thoughts now?
18:02:09 <sgallagh> Any new package reviews since last week?
18:02:11 <t8m> Hi
18:02:59 <nirik> some more in progress I think...
18:03:00 * nirik looks
18:03:34 <nirik> 2 more finished reviews, 3 more in progress.
18:04:38 <sgallagh> Sounds like he's committed to the job
18:04:38 * nirik is +1 now. Not a vast number of reviews, but they all seem good to me, and we need more folks helping in the could space with sponsoring.
18:04:46 * sgallagh agrees. +1
18:04:48 <pjones> yeah, +1
18:04:49 <t8m> I am +1 as well
18:04:50 <mitr> +1
18:05:22 <notting> sure, +1
18:05:51 <nirik> #agreed sponsorship is approved.
18:06:05 <nirik> #topic F17 Feature: DIET - https://fedoraproject.org/wiki/Features/F17_DIET
18:06:05 <nirik> .fesco 751
18:06:07 <zodbot> nirik: #751 (F17 Feature: DIET - https://fedoraproject.org/wiki/Features/F17_DIET) – FESCo - https://fedorahosted.org/fesco/ticket/751
18:06:20 <mitr> +1
18:06:22 <mjg59> +1
18:06:33 <nirik> sure, +1
18:06:40 <mmaslano> +1
18:06:55 <t8m> +1
18:07:05 <t8m> Fedora on a diet
18:07:16 <notting> moderately concerned about the name overlap with the old pseudo-libc and utils, but sure, +1
18:07:16 <pjones> +1
18:07:32 <pjones> notting: does anybody but us remember that? ;)
18:07:36 <notting> also: diet + corba?
18:07:39 <notting> odd combination
18:07:46 <t8m> notting, :D
18:07:57 * nirik remembers it. man, must be old.
18:07:59 <sgallagh> +1
18:08:04 <nirik> #agreed Feature is approved
18:08:25 <nirik> #topic F17 Feature: Rework Live CD - https://fedoraproject.org/wiki/Anaconda/Features/ReworkLiveCD
18:08:26 <nirik> .fesco 752
18:08:27 <zodbot> nirik: #752 (F17 Feature: Rework Live CD - https://fedoraproject.org/wiki/Anaconda/Features/ReworkLiveCD) – FESCo - https://fedorahosted.org/fesco/ticket/752
18:08:41 <nirik> so, one concern I have here is making live images in koji...
18:08:52 <mitr> Note that this requires running virt guests as part of rel-eng processes
18:08:55 <bcl> hey, just in time :)
18:09:15 <nirik> yep. ;)
18:09:23 <pjones> mitr: but it also gets us off of the old hacky way to do it, which has always been pretty awful.
18:09:26 <nirik> so, yeah, it's nice to be able to do live composes in koji...
18:10:09 <mitr> pjones: I'm fine with it as a matter of principle, just wondering whether rel-eng will be able to use it
18:10:21 <notting> can't koji already do live composes?
18:10:27 <pjones> yeah, I understand.  Guess that's a question for rel-eng.
18:10:40 <nirik> notting: yes, with the current process. not this new process, AFAIK
18:10:45 <mjg59> As far as the feature goes, I'm fine with it
18:10:59 <mjg59> Implementation details may always prevent something we approve from happening
18:11:07 <t8m> I am fine with the feature +1
18:11:07 <sgallagh> I'm not sure this qualifies as a Feature
18:11:11 <sgallagh> This sounds more like a process.
18:11:19 <sgallagh> *process change
18:11:37 <nirik> I like moving it all into the same place, I don't like the requirement on libvirt instances. ;(
18:11:40 <sgallagh> I guess I don't understand what this adds to Fedora that is worth putting in release notes, etc.
18:11:45 <pjones> sgallagh: nevertheless in light of no dramatic overhaul of the feature process having occurred, people are still effectively being encouraged to make this sort of thing a Feature.
18:12:04 <sgallagh> pjones: I'm not sure it matches up even with the current flawed feature process
18:12:10 <mitr> Right, having the code is awesome, I don't know about advertising the code if it isn't used
18:12:32 <pjones> sgallagh: I'm not sure anything does.  It's sortof beside the point.
18:12:52 <mjg59> mitr: If it's not used then it won't reach 100%. Or am I misunderstanding you?
18:12:59 * limburgher is here Sorry I'm late, $DAYJOB
18:13:05 <sgallagh> I'm +0 on this.
18:13:19 <mitr> mjg59: integrating the code into rel-eng processes isn't in scope AFAICS
18:13:21 <notting> this would also seem to preclude building live images for certain secondary arches
18:13:35 <nirik> I guess I am ok with the feature, but would want to -1 it if we don't use it in rel-eng to produce things... because if we still use the old method, but advertise the new to users it could cause doom.
18:13:45 <mjg59> mitr: The fallback is to carry on using python-imgcreate
18:13:59 <mjg59> mitr: So if we carry on doing that then the feature isn't complete
18:14:06 <mitr> mjg59: oh, right
18:14:26 <mitr> notting: as in, some arches don't have virt at all?
18:14:33 <notting> mitr: yep
18:14:36 <mitr> bcl?
18:14:51 <sgallagh> nirik: I'm leaning more towards -1 for this release and work it in tightly to f18
18:14:52 <pjones> that's what qemu-sh4 is for ;)
18:14:53 <nirik> proposal: +1 to feature, but drop if not able to be used by releng. Ask feature owners to work with rel-eng to come up with a solution?
18:14:56 <bcl> hmm, reading...
18:15:23 <t8m> nirik, that seems like reasonable proposal
18:15:25 * mitr would be +1 to proposal
18:15:25 <mmaslano> nirik: I like your proposal, +1
18:15:27 <notting> pjones: the horror
18:15:27 <sgallagh> Seems kind of late to make that sort of change anyway. Especially since it needs to be finished in time to build the alphas
18:15:36 <sgallagh> I'm going with -1 after more thought.
18:15:54 <bcl> note: you can also use it w/o virt if you are running it from the same release as you are targeting.
18:16:06 <pjones> Well, I don't think we should -1 out of hand just because we don't know what rel-eng things.  We should ask rel-eng instead.
18:16:09 <bcl> so for secondary arches w/o virt that is an option.
18:16:13 <nirik> bcl: in a mock/chroot?
18:16:13 <notting> bcl: hm, that might simplify things
18:16:32 <bcl> not in mock. mock and loops don't always work right.
18:16:33 * nirik nods. that might make things doable for the koji plugin.
18:17:06 <nirik> hum, bummer then.
18:17:13 <notting> i am +1 to the idea of the feature, but final completion really does depend on rel-eng
18:17:23 <pjones> yeah, I'm +1 as well.
18:17:33 <mjg59> +1 on the assumption that if it's not finished then it's not a feature, but that's true of everything isn't it?
18:17:56 <pjones> mjg59: yes.
18:18:10 <nirik> well, I was suggesting we add a requirement on it...
18:18:16 <nirik> that it be used by rel-eng.
18:18:17 * sgallagh remains -1 for F17
18:18:37 <pjones> nirik: that's already implicitly there though
18:18:43 <nirik> notting / pjones / mjg59: is that +1 to my proposal? or just the feature as itself?
18:18:56 <mjg59> +1 to the feature
18:18:58 <nirik> pjones: it is?
18:18:59 <pjones> just to the feature
18:19:05 <nirik> I don't see it on the feature page anywhere.
18:19:23 <mjg59> Contingency Plan
18:19:23 <mjg59> Continue to use python-imgcreate
18:19:52 <bcl> I think it is a separate decision as to whether releng uses it for live media.
18:19:53 <nirik> but it doesn't have a requirement that we produce our live images with it.
18:19:59 <pjones> hence the word "implicitly", yes.  the contingency plan clearly assumes that rolling it out is part of it.
18:20:09 <mjg59> If we use python-imgcreate then we're on the contingency plan
18:20:17 <mjg59> And if we're on the contingency plan then the feature isn't complete
18:20:22 <bcl> There's also the 3rd part spins guys who make lots of live stuff.
18:20:50 <pjones> bcl: so you're saying the feature is really just the availability of it, then?
18:21:01 <nirik> right.
18:21:06 <bcl> yes
18:21:16 <pjones> okay.
18:21:32 <bcl> I would prefer that it had more testing by spins before being used by releng.
18:21:52 <nirik> I'd like to avoid the "I downloaded the desktop ks file and make a live with livemedia-creator and it has diffferent bugs from the official media that can be downloaded"
18:22:00 <bcl> But I think it is a good Feature because it finally gives us a way to make correct images instead of chroot+yum images.
18:22:34 <pjones> nirik: I think we've already got that
18:22:40 <nirik> so, we are -1, +4 to feature + rel-eng requirement, and +1 to the feature as is?
18:22:56 <pjones> nirik: just the fact that you might get updates applied causes that.
18:22:56 <nirik> pjones: how so?
18:23:48 <nirik> if you enable them, but you could also change the ks file, etc, etc. I am talking about reproducing the official media... doing one method then asking users to use another is likely to cause confusion and more bugs. I guess it's not the end of the world...
18:24:22 <bcl> really it should have less. since it uses anaconda :)
18:24:48 * nirik agrees it's the way to go, but just isn't sure we should advertise it before we are using it.
18:25:36 <nirik> so, where are we then? other votes? thoughts?
18:26:03 <pjones> nirik: but how do we get the testing bcl wants to have before it goes into rel-eng if the message we're sending is to not use it? ;)
18:26:19 <nirik> sure there is that...
18:26:23 <sgallagh> pjones: Spins, not official releases.
18:26:49 <nirik> sgallagh: we have official spin releases, no?
18:26:59 <mmaslano> proposal: could we add into ticket condition -> speak with releng about it?
18:27:04 * sgallagh shuts up
18:27:29 <nirik> would folks revote noting if they are ok with the feature as is, or require us to be using it for official live media first?
18:28:18 <mjg59> +1 as is
18:28:46 <sgallagh> -1 For F17
18:28:57 <nirik> +1, but would like to see rel-eng using it or at least a way for them to do so down the road.
18:29:09 <notting> i guess i'm -1 as is - concerned about the fact that it requires kickstart changes
18:29:11 <pjones> I'm still +1 as is as well
18:29:20 <mmaslano> +1 and debate with rel-eng
18:29:21 <mitr> +1 if used by rel-eng (in everything or even in a single small part)
18:29:24 <limburgher> +1 as is, though rel-eng soonish.
18:29:26 <t8m> I really don't care about the rel-eng requirement although it would be clearly nice to have a word from them if they'll be able to use it
18:29:28 <t8m> so +1
18:30:18 <mitr> Alternatively, +1 as is, if the release notes (which are empty currently) explicitly describe the current status
18:30:45 * nirik tries to count votes.
18:31:09 <pjones> I'm all for explaining the current status in the relnotes
18:31:10 <nirik> -2, +3 (with releng) and +4 as is I think.
18:31:43 <nirik> anyone want to change votes? ;)
18:31:56 <notting> hm.
18:32:19 <sgallagh> Perhaps it would be prudent not to have a multiple-choice here?
18:32:25 <notting> if it gets re-defined in the (!releng) case from "here is the new way to build images" to "here is a new way to build images that we're working on...", yes?
18:32:50 <nirik> sgallagh: open to suggestion. ;)
18:33:43 <nirik> ok, how about:
18:33:58 <nirik> proposal: table, ask rel-eng folks for input and revisit next week. ;)
18:34:04 <notting> +1
18:34:04 <sgallagh> nirik: +1
18:34:07 <nirik> (when you can't decide, defer!)
18:34:20 <t8m> nirik, +1
18:34:27 <mmaslano> +1
18:34:34 <limburgher> +1
18:34:39 <mitr> +1
18:34:47 <pjones> sure, why not.
18:34:55 <nirik> Who will take that action item? bcl: can you do so?
18:35:17 <nirik> #agreed will ask rel-eng for input and revisit next week.
18:35:18 <bcl> err, which?
18:35:45 <nirik> talk to rel-eng about this and see if there's a way for them to use this to compose offical images.
18:35:45 <nirik> (ie, talk to dgilmore)
18:35:57 <bcl> sure.
18:36:07 <nirik> #action bcl to talk with rel-eng.
18:36:09 <nirik> thanks
18:36:18 <nirik> #topic F17 Feature: ABRT Backtrace Deduplication - https://fedoraproject.org/wiki/Features/ABRTBacktraceDeduplication
18:36:18 <nirik> .fesco 754
18:36:22 <zodbot> nirik: #754 (F17 Feature: ABRT Backtrace Deduplication - https://fedoraproject.org/wiki/Features/ABRTBacktraceDeduplication) – FESCo - https://fedorahosted.org/fesco/ticket/754
18:36:26 <nirik> +1. less dupes good.
18:36:33 <mitr> +1
18:36:36 <limburgher> +1
18:36:41 <t8m> +1
18:36:41 <notting> doesn't it already do this? +1 anyway
18:36:44 <mmaslano> +1
18:36:45 <mjg59> +1
18:36:51 <nirik> it does, but this is a new and shiny method I gather.
18:37:10 <nirik> #agreed feature is approved.
18:37:10 <sgallagh> +1
18:37:14 <pjones> I feel like I should -1 anything that involves a retrace server.
18:37:37 <dmalcolm> [btw, can I add an agenda item please?]
18:37:39 <nirik> yeah, sadly thats the path we are on tho.
18:37:50 <nirik> dmalcolm: sure, can it wait for open floor at the end?
18:37:57 <dmalcolm> nirik: sure, thanks
18:38:01 <nirik> #topic F17 Feature: Font Configuration Tool - https://fedoraproject.org/wiki/Features/FontConfigurationTool
18:38:01 <nirik> .fesco 755
18:38:04 <zodbot> nirik: #755 (F17 Feature: Font Configuration Tool - https://fedoraproject.org/wiki/Features/FontConfigurationTool) – FESCo - https://fedorahosted.org/fesco/ticket/755
18:38:20 <mitr> pjones: what's the concern? privacy, HW availability, something else?  AFAICS this feature does not depend on doing the retrace
18:38:46 <mitr> +1 to font cfg tools - ideally should be provided by the desktops directly, but having a desktop-independent fontconfig-only tool can't hurt
18:38:50 <pjones> mitr: no, it just makes use of it.  but we should have gone the route of making debuginfo better available on the client end for various reason, privacy included.
18:39:12 <nirik> +1 to this feature, we could use more good font tools. Hope it's done in time.
18:39:15 <t8m> +1 to the feature
18:39:18 <limburgher> +1
18:39:19 <mjg59> This is just making the tool available, right - not the default?
18:39:20 <mmaslano> +1
18:39:21 <pjones> sure, +1
18:39:22 <notting> mitr: well, it gives users a way to botch theiir own config
18:39:32 <sgallagh> mitr: I agree to +1, but I'd like to lobby the devs to make it into an API for easier integration with native desktop environments
18:39:36 <nirik> yeah, just advertising the tool as I read it.
18:39:41 <mjg59> +1
18:40:01 <notting> hey, someone who may have an opinion on this :)
18:40:16 <sgallagh> notting: ?
18:40:23 <nirik> if he's really here. ;)
18:40:37 <notting> nim-nim: as a font person, any comments on https://fedoraproject.org/wiki/Features/FontConfigurationTool ?
18:41:33 <nirik> #agreed feature is approved.
18:41:42 * nirik guesses he's not really around.
18:42:17 <nirik> #topic F17 Feature: English Typing Booster - https://fedoraproject.org/wiki/Features/english-typing-booster
18:42:18 <nirik> .fesco 756
18:42:20 <zodbot> nirik: #756 (F17 Feature: English Typing Booster - https://fedoraproject.org/wiki/Features/english-typing-booster) – FESCo - https://fedorahosted.org/fesco/ticket/756
18:42:27 * notting votes -1 to the prior feature, for the record
18:42:57 <mitr> +1
18:43:03 <notting> "Create dictionary tables from wikipedia dumps for English." hm.
18:43:06 <sgallagh> I read through this and I couldn't find a clear vision of how this works from upstream
18:43:38 <notting> i *think* that should be OK from a licensing standpoint
18:43:45 <limburgher> Why not use existing dicts?
18:44:00 <sgallagh> notting: WP is CC-BY, correct?
18:44:07 <notting> sgallagh: CC-BY-SA
18:44:09 <mjg59> "Since the suggestions come from a validated word dictionary database, the selected words always give 100% accurate spelling."
18:44:09 <sgallagh> They'd need to give credit somewhere.
18:44:13 <t8m> I am +1 - if this is not on by default which I suppose it isn't
18:44:18 <mitr> sgallagh: I'm not sure what you mean - AFAICS it's just one more input method that can be manually enable.  I didn't find any screenshots/videos either :)
18:44:29 <mjg59> I actually had a conversation about this last week
18:44:33 <notting> the experience to set up in how-to-test looks icky
18:44:37 <sgallagh> mitr: Right, I missed the word 'ibus' on my first read
18:44:46 <mjg59> Summary: The copyright status of the output of a model trained on a given text is unclear
18:44:47 <sgallagh> I wasn't sure if this was supposed to work at the console too
18:44:56 <mitr> limburgher: I wondered as well, but I'm not interested in micromanaging that
18:45:18 <mjg59> So if the training text is CC-BY-SA, there is an argument that anything you typed with it would have to follow those terms
18:45:42 <limburgher> mitr:  Yeah.  As long as the licensing is ok. . .
18:45:59 <mjg59> So I'm +1, but would just note that the licensing does need to be checked carefully
18:46:02 <notting> mjg59: that's an odd interpretation
18:46:09 <mmaslano> I don't see why adding such new package is a feature but it's +1
18:46:22 <t8m> I don't think wordlist created of a text is a derived work of that text if the text is sufficiently large.
18:46:23 * nirik is +1 I guess.
18:46:39 <pjones> mjg59: but I think what you're saying is that no amount of checking will actually tell us where we stand?
18:46:43 <sgallagh> I'm -1 while there are legal considerations. Send it to legal@ first
18:46:52 * notting agrees with sgallagh. -1
18:46:59 <notting> pjones: well, switching to /usr/share/dict/words solves that problem
18:47:02 <mjg59> If this only looks at the context of the single word, I suspect it's fine
18:47:17 <mjg59> If it starts producing predictions based on previous words then things get a little more confusing
18:47:40 <mitr> mjg59: https://fedorahosted.org/english-typing-booster/browser/english-typing-booster/tables/english-dict.txt (3M download) - single words AFICS
18:47:42 <mjg59> For instance, if choosing the best prediction each time results in it tending to generate the original work...
18:47:55 * nirik notes his +1 was on the assumption that legal was ok
18:48:24 <sgallagh> nirik: I think it should be vetted before we give any tacit approvals
18:48:41 <notting> mjg59: haha
18:48:42 <limburgher> sgallagh: <nods>
18:48:52 <mjg59> Ok - single words so I guess it's probably ok
18:48:58 <mjg59> Although the words list does claim to be GPLv3
18:49:02 <t8m> I really do not think there is any legal trouble with wordlists
18:49:11 <notting> mjg59: well, that's obviously wrong
18:49:13 <t8m> so +1
18:49:19 <nirik> so, I see +4, -2 ?
18:49:36 <mjg59> +1 to the feature, and unrelatedly I think it should have some legal checking
18:49:39 <notting> mjg59: and i'm not sure if it's even valid
18:49:45 <pjones> I'm +1 to the feature.
18:49:55 <mjg59> notting: Yeah, quite
18:49:56 <mitr> +1 to mjg59
18:50:09 <limburgher> +1 if it's legit.
18:50:15 <pjones> but yeah, it's clear we need to do some legal homework on this one
18:50:35 <mitr> pjones: s/we/feature owners/?
18:50:35 * notting remains -1 until legal homework done
18:51:04 <notting> *shrug* i'm willing to undertake that *with* the feature owners
18:51:36 <nirik> ok, I think thats +6, -2..
18:51:42 <nirik> notting: please do? :)
18:51:48 <pjones> mitr: notting, obviously.
18:52:15 <nirik> #agreed feature is approved.
18:52:34 <nirik> do we want to leave some kind of tracking in place for the legal aspect?
18:53:01 <sgallagh> nirik: What do you propose? File a BZ?
18:53:06 <nim-nim> notting: I'm not sure it's the cleanest approach possible but they're trying to make fontconfig work in in the real world
18:53:26 <nirik> sgallagh: perhaps we leave the ticket open and revisit it in our meetings ?
18:54:04 <sgallagh> worksforme
18:54:19 <nirik> ok, so thats the end of the features that were on our initial agenda...
18:54:26 <nirik> but then we got a pile more.
18:54:38 <nirik> do we want to look at them today? defer to next week? or look at a subset?
18:55:10 <nim-nim> notting: as opposed to the previous wishful thinking (someday someone will create a perfect font set with no overlaps that fontconfig can handle automatically without config)
18:55:10 <t8m> I think we should look at them today
18:55:23 * nirik is fine to look at them today.
18:55:26 <sgallagh> I think we should hit as many as we can in the next, say, hour
18:55:32 <nirik> we can always defer on ones we want more info on
18:55:36 <mmaslano> yes
18:56:07 <mitr> Today, please - the work won't go away if we defer
18:56:37 <mitr> Perhaps there is an uncontroversial set that we could block vote on?
18:56:37 <notting> ok. i have to head out, i can vote in tickets later
18:56:49 <nirik> notting: have fun.
18:57:16 <nim-nim> notting: fontconfig worst weakness is that it only manipulates complete fonts, and since they all overlap in non-obvious way it's not possible to create a single order everyone likes as keithp thought
18:57:37 <nirik> pjones / mjg59 / limburgher: shall we try and go on? or you guys want to postpone?
18:58:07 <mjg59> May as well go on
18:58:28 <nim-nim> notting: and no one has stepped up to do the clean thing (enhance fontconfig so it can work on font subsets that can be defined in non-overlappy way)
18:58:33 <limburgher> Go on.
18:58:40 <pjones> we're still at quorum, so may as well make an attempt with an eye on deferring quickly if consensus isn't clearly reachable.
18:58:50 <nirik> ok, onward.
18:58:51 <nirik> #topic #758	F17 Feature : Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno
18:58:52 <nirik> .fesco 758
18:58:53 <zodbot> nirik: #758 (F17 Feature : Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno) – FESCo - https://fedorahosted.org/fesco/ticket/758
18:59:17 <mmaslano> +1
18:59:24 <nirik> sure, +1
18:59:26 <nim-nim> notting: as far as I understand the i18n feature is to let users reorder fontconfig prefs any way they like, since a perfect distro order is not possible
18:59:34 <limburgher> +1
18:59:40 <sgallagh> Is this filing early?
18:59:56 <sgallagh> It's claiming that the upstream will be released in June
19:00:02 <pjones> this seems like their timeline is f18 not f17
19:00:04 <sgallagh> That seems rather too late for F17
19:00:06 <mjg59> +1
19:00:08 <mitr> sgallagh: they want to ship a prerelease
19:00:09 <t8m> -1
19:00:22 <sgallagh> -1 that's what rawhide is for
19:00:26 <mitr> "Upstream has asked that we clearly communicate that we will be shipping a pre-release in Fedora (due to timing) and will be updating to their final version as soon as it is released. "
19:00:38 <t8m> I do not like shipping prereleases in the final GA releases of Fedora
19:00:42 <mitr> +1 - if this is agreed with upstream, why not
19:00:59 <mjg59> sgallagh: Maintainers get to make judgement calls on whether they think something will be sufficiently stable
19:00:59 <mitr> t8m: We ship a prerelease of GNOME practically the entire development cycle
19:00:59 <pjones> yeah, I don't much like sticking a prerelease in f17 and then updating to a final (plausibly quite different) version in an update.
19:01:00 <pjones> -1
19:01:06 <abadger1999> t8m: There is definitely precendent for that strategy, though.
19:01:11 <t8m> mitr, I don't like it either
19:01:16 <limburgher> It works for Firefox.
19:01:27 <abadger1999> (GNOME, KDE< and firefox have all done it)
19:01:34 <mjg59> As long as the expectation is that changes will be minimal, I'm fine with this
19:01:41 <t8m> abadger1999, I know
19:01:47 <sgallagh> Generally their final releases are going to happen before Fedora's GA
19:01:51 <overholt_> yup
19:01:54 <overholt_> we're always screwed
19:02:00 <overholt_> either early (this case) or late (4 months)
19:02:07 <sgallagh> We're talking about at least a month of additional work here.
19:02:13 <overholt_> I pushed for early this time
19:02:16 <sgallagh> Not including slippage
19:02:20 <nirik> yeah, some upstreams just don't align with our release cycle.
19:02:23 <overholt_> honestly, 99% of upstream is done by April
19:02:30 <overholt_> they have serious ramp-downs
19:02:33 <overholt_> and they don't slip
19:02:34 <sgallagh> nirik: Of course, but they should wait for the next bus
19:02:34 <overholt_> guaranteed
19:02:36 <pjones> overholt_: so we're really talking about very minimal changes?
19:02:39 <overholt_> pjones, yup
19:03:04 <t8m> I count +5 anyway...
19:03:06 <mitr> The schedule says API freeze on March 16, i.e. before our Beta
19:03:15 <overholt_> yup
19:03:19 <pjones> okay, I can be convinced then.
19:03:21 <sgallagh> Personally, I rely on Eclipse rather a lot. I'm leery of having a prerelease in F17
19:03:32 <pjones> no point in holding something up on process formalities if the real changes are already done.
19:03:45 <sgallagh> pjones: If we vote it down, it gets backed out
19:04:01 <pjones> sgallagh: I'm familiar with how voting works, yes.
19:04:09 <mjg59> sgallagh: Er.
19:04:12 <overholt_> I don't want to do an update post-release
19:04:15 <mjg59> sgallagh: No, if we vote it down, it's not a feature.
19:04:19 * nirik counts votes.
19:04:30 <mjg59> sgallagh: We could separately have a discussion on whether to overrule the maintainer
19:04:32 <pjones> nirik: given overholt_'s input I'm +1 as well.
19:05:03 <sgallagh> Obviously I've been outvoted, but I'm -1 (I think this will bite us)
19:05:18 <overholt_> sgallagh, I'd like to work with you personally as an active user to ensure it doesn't
19:05:22 <pjones> mjg59: I assumed he meant backed out as a feature, not from the distro, but on re-read I see what you're saying.
19:05:30 <pjones> either way, it seems to be approved, n'est pas?
19:05:37 <nirik> I think thats +6, -2 ?
19:05:52 <nirik> #agreed feature is approved
19:06:02 <overholt_> thanks
19:06:18 <nirik> #topic #759	F17 Feature: Opa - https://fedoraproject.org/wiki/Features/Opa09
19:06:18 <nirik> .fesco 759
19:06:20 <zodbot> nirik: #759 (F17 Feature: Opa - https://fedoraproject.org/wiki/Features/Opa09) – FESCo - https://fedorahosted.org/fesco/ticket/759
19:06:24 <sgallagh> overholt_: Well, I'll be testing the new release, absolutely :)
19:06:32 <mjg59> +1
19:06:39 <sgallagh> But I'm wary of it being stable enough for Fedora in general
19:06:49 <mitr> +1
19:06:55 <pjones> +1
19:07:01 <pjones> sgallagh: that was a joke, right?
19:07:02 <nirik> +1
19:07:03 <sgallagh> +1 Looks straightforward to me
19:07:14 <mjg59> (Do things built with Opa end up under AGPLv3 as well?)
19:07:23 <limburgher> +1
19:07:26 <mmaslano> +1
19:07:32 <nirik> I sure would think not.
19:07:33 <sgallagh> pjones: You're such a cynic :)
19:08:30 <nirik> #agreed feature is approved
19:08:34 <mjg59> nirik: Seems a slightly odd license to choose in that case, but I don't think it makes any practical difference
19:08:57 <nirik> yeah
19:09:18 <abadger1999> mjg59: Better ask that question of spot if you're concerned/want it documented in Fedora.
19:10:06 <nirik> #topic #760	F17 Feature: Internationalization support for additional Indian languages - http://fedoraproject.org/wiki/Features/Additional_Indic_Langs
19:10:07 <nirik> .fesco 760
19:10:08 <zodbot> nirik: #760 (F17 Feature: Internationalization support for additional Indian languages - http://fedoraproject.org/wiki/Features/Additional_Indic_Langs) – FESCo - https://fedorahosted.org/fesco/ticket/760
19:10:15 <t8m> Sure +1
19:10:16 <mitr> +1
19:10:17 <nirik> might be good to ask that on the package review (which is still open)
19:10:25 <mjg59> +1
19:10:25 <sgallagh> +1
19:10:29 <mmaslano> +1
19:10:29 <pjones> 22 official languages is absurd, even for a country the size of India.  +1.
19:10:41 <nirik> +1
19:10:49 <nirik> #agreed feature is approved
19:10:50 <limburgher> +1
19:11:12 <nirik> #topic #761	F17 Feature: DNSSEC on workstations -  https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
19:11:12 <nirik> .fesco 761
19:11:14 <zodbot> nirik: #761 (F17 Feature: DNSSEC on workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) – FESCo - https://fedorahosted.org/fesco/ticket/761
19:11:15 <t8m> pjones, you mean something like European Union?
19:11:41 <pjones> t8m: not a country.
19:11:52 <pjones> t8m: as they seem hellbent on proving right now.
19:12:12 <mmaslano> dnssec please
19:12:24 <pjones> +1 to dnssec.
19:12:30 <sgallagh> +1 dnssec everywhere!
19:12:39 <mjg59> +1
19:12:42 <limburgher> +1
19:12:47 <mitr> Mildly +1 - like the idea, not absolutely certain about UI
19:12:47 <mmaslano> +1
19:13:03 <nirik> +1
19:13:27 <t8m> +1 same concerns as mitr
19:13:38 <nirik> #agreed feature is approved.
19:13:42 <nirik> #topic #762	F17 Feature: Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno
19:13:43 <nirik> .fesco 762
19:13:44 <zodbot> nirik: #762 (F17 Feature: Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno) – FESCo - https://fedorahosted.org/fesco/ticket/762
19:14:00 <mitr> nirik: we talked about that
19:14:06 <nirik> oops.
19:14:07 <nirik> yeah, sorry.
19:14:08 <nirik> #undo
19:14:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2d797b90>
19:14:28 <nirik> #topic #763	F17 Feature: Ext4 support beyond 16T -  https://fedoraproject.org/wiki/Features/F17Ext4Above16T
19:14:28 <nirik> .fesco 763
19:14:30 <zodbot> nirik: #763 (F17 Feature: Ext4 support beyond 16T - https://fedoraproject.org/wiki/Features/F17Ext4Above16T) – FESCo - https://fedorahosted.org/fesco/ticket/763
19:14:31 <mmaslano> it had different  number
19:14:43 <nirik> +1
19:14:46 <mjg59> +1
19:14:46 <pjones> +1 to letting sandeen do his job.
19:14:47 <mmaslano> +1
19:14:48 <mitr> +1
19:14:49 <limburgher> +1
19:14:52 <sgallagh> +1
19:15:03 <t8m> +1
19:15:08 <sgallagh> Any chance he can send us some 32T drives to test with? :)
19:15:19 <nirik> #agreed feature is approved.
19:15:19 <pjones> you don't want that.
19:15:23 <limburgher> I would totally help with that. :)
19:15:23 <nirik> ha
19:15:35 <nirik> #topic #764	F17 Feature: Haskell Platform 2011.4 -  https://fedoraproject.org/wiki/Features/HaskellPlatform2011.4
19:15:38 <nirik> .fesco 764
19:15:40 <zodbot> nirik: #764 (F17 Feature: Haskell Platform 2011.4 - https://fedoraproject.org/wiki/Features/HaskellPlatform2011.4) – FESCo - https://fedorahosted.org/fesco/ticket/764
19:15:45 <pjones> +1 I guess...
19:15:46 <mitr> +1
19:15:57 <mmaslano> +1
19:16:04 <nirik> sure, why not. +1
19:16:07 <sgallagh> +1
19:16:08 <limburgher> +1  Not loving the lack of a contingency plan,  but. . .
19:16:16 <t8m> +1
19:16:30 <nirik> #agreed feature is approved.
19:16:31 <sgallagh> limburgher: Do enough people use Haskell for us to care about contingencies?
19:16:32 <mjg59> +1
19:16:41 <nirik> #topic #765	F17 Feature:  New Features of IPA v3 -  https://fedoraproject.org/wiki/Features/IPAv3NewFeatures
19:16:41 <nirik> .fesco 765
19:16:43 <zodbot> nirik: #765 (F17 Feature: New Features of IPA v3 - https://fedoraproject.org/wiki/Features/IPAv3NewFeatures) – FESCo - https://fedorahosted.org/fesco/ticket/765
19:16:43 <sgallagh> (Not trying to be flippant, just realistic)
19:16:49 <limburgher> sgallagh: I work with a guy. :)
19:16:57 <mjg59> Haskell updates aren't provably correct?
19:17:14 <mjg59> +1
19:17:21 <nirik> ha.
19:17:25 <pjones> sure, +1
19:17:27 <mitr> +1
19:17:30 <limburgher> sgallagh:  Understood. :)
19:17:31 <mmaslano> +1
19:17:31 <limburgher> +1
19:17:37 <t8m> +1
19:17:47 <nirik> +1 for IPA, full of hops and... oh wait, wrong IPA.
19:17:49 <sgallagh> +1
19:17:58 <nirik> #agreed feature is approved.
19:18:04 <nirik> #topic #766	F17 Feature:  Java 7 - https://fedoraproject.org/wiki/Features/Java7
19:18:05 <nirik> .fesco 766
19:18:06 <zodbot> nirik: #766 (F17 Feature: Java 7 - https://fedoraproject.org/wiki/Features/Java7) – FESCo - https://fedorahosted.org/fesco/ticket/766
19:18:07 <sgallagh> nirik: Come to some of the presentations I give. I occasionally provide FreeIPA-labeled beer :)
19:18:32 <nirik> sgallagh: oooh. good to know. ;)
19:18:44 <mjg59> +1
19:18:46 <nirik> +1 on java. I assume most of this already got rebuilt in the mass rebuild?
19:18:50 <sgallagh> +1 to Java 7. Last I heard, they had worked out the majority of the issues from F16
19:18:53 <mmaslano> +1
19:18:55 <limburgher> +1
19:18:58 <t8m> sgallagh, although the ssh host keys support must be upstream first!
19:19:16 <mitr> +1
19:19:24 <t8m> +1 to java 7
19:19:27 <pjones> +1
19:19:32 <nirik> #agreed feature is approved.
19:19:39 <nirik> #topic #767	F17 Feature -  New mkdumprd for kdump -  https://fedoraproject.org/wiki/Features/NewMkdumprd
19:19:39 <nirik> .fesco 767
19:19:41 <sgallagh> t8m: The Fedora maintainer has agreed to carry it in Fedora
19:19:42 <zodbot> nirik: #767 (F17 Feature - New mkdumprd for kdump - https://fedoraproject.org/wiki/Features/NewMkdumprd) – FESCo - https://fedorahosted.org/fesco/ticket/767
19:19:59 <pjones> +1 better late than never.
19:20:20 <mjg59> +1
19:20:21 <sgallagh> +1
19:20:22 <limburgher> +1
19:20:25 <t8m> +1
19:20:26 <nirik> +1 here.
19:20:28 <mitr> +1
19:20:28 <mmaslano> +1
19:20:31 <nirik> #agreed feature is approved.
19:20:37 <nirik> #topic #768	F17 Feature: Virtualization Sandbox - https://fedoraproject.org/wiki/Features/VirtSandbox
19:20:38 <nirik> .fesco 768
19:20:39 <zodbot> nirik: #768 (F17 Feature: Virtualization Sandbox - https://fedoraproject.org/wiki/Features/VirtSandbox) – FESCo - https://fedorahosted.org/fesco/ticket/768
19:20:44 <mitr> +1
19:20:52 <pjones> +1
19:20:58 <sgallagh> +1 WANT
19:21:03 <nirik> sure, +1
19:21:03 <mmaslano> +1
19:21:05 <t8m> +1
19:21:49 <limburgher> +1
19:21:56 <nirik> #agreed feature is approved.
19:22:29 <nirik> #topic #769	F17 Feature: numad (Non-Uniform Memory Alignment Daemon) - https://fedoraproject.org/wiki/Features/numad
19:22:30 <nirik> .fesco 769
19:22:32 <zodbot> nirik: #769 (F17 Feature: numad (Non-Uniform Memory Alignment Daemon) - https://fedoraproject.org/wiki/Features/numad) – FESCo - https://fedorahosted.org/fesco/ticket/769
19:22:43 <nirik> not sure how many people will care about this one, but sure, +1 for those that do
19:22:51 <t8m> +1
19:22:56 <pjones> it's too bad they couldn't find a way to name it "nomad".  +1.
19:22:58 <mjg59> +1
19:23:05 <mitr> Is this intended to run by default?
19:23:19 <bgray> No, service off by default
19:23:25 <mmaslano> +1
19:23:29 <sgallagh> Excuse my ignorance, but what systems are NUMA-enabled?
19:23:39 <sgallagh> Is this a standard feature of Core processors or something?
19:23:54 <bgray> Multi-socket systems
19:24:01 <pjones> sgallagh: well, amd64 is technically numa on multi-socket...
19:24:02 * rbergeron spreads the plague of spot
19:24:15 <sgallagh> bgray: No impact on multi-core, single-socket then?
19:24:32 <limburgher> bgray: Or cost if enabled and not helpful?
19:24:49 <bgray> No, unless new AMD , which has two NUMA nodes per socket
19:25:07 <sgallagh> +1
19:25:09 <bgray> It won't do anything unless there is >1 NUMA node
19:25:12 <mitr> +1
19:25:19 <limburgher> +1
19:25:25 <nirik> #agreed feature is approved.
19:25:28 <nirik> #topic #771	F17 Feature: OpenStack Quantum - https://fedoraproject.org/wiki/Features/OpenStack_Quantum
19:25:29 <nirik> .fesco 771
19:25:29 <zodbot> nirik: #771 (F17 Feature: OpenStack Quantum - https://fedoraproject.org/wiki/Features/OpenStack_Quantum) – FESCo - https://fedorahosted.org/fesco/ticket/771
19:25:54 <mitr> +1
19:26:01 <mmaslano> +1
19:26:08 <limburgher> +1
19:26:10 <sgallagh> I'm not a huge fan of the contingency plan
19:26:14 <nirik> +1 here
19:26:16 <sgallagh> "If it's not ready, we'll ship it anyway"
19:26:30 <mjg59> +1
19:26:41 <sgallagh> +1 anyway
19:26:47 <nirik> yeah, thats not ideal for sure.
19:26:48 <rkukura> sgallagh: that's just one plugin among several
19:26:52 <t8m> +1
19:27:35 <nirik> #agreed feature is approved.
19:27:40 <nirik> #topic #772	F17 Feature: OpenStack using Qpid - https://fedoraproject.org/wiki/Features/OpenStack_using_Qpid
19:27:41 <nirik> .fesco 772
19:27:42 <zodbot> nirik: #772 (F17 Feature: OpenStack using Qpid - https://fedoraproject.org/wiki/Features/OpenStack_using_Qpid) – FESCo - https://fedorahosted.org/fesco/ticket/772
19:27:51 <t8m> +1
19:27:55 <mitr> +1
19:28:05 <sgallagh> +1
19:28:11 <limburgher> +1
19:28:13 * nirik wonders if some of the openstack features couldn't be folded into one 'better openstack' one... but I guess they might be running at different speeds, etc.
19:28:27 <mmaslano> +1
19:28:32 <pjones> +1
19:28:43 <nirik> +1 anyhow.
19:29:03 <nirik> #agreed feature is approved.
19:29:23 <nirik> #topic #773	F17 Feature:  Ruby 1.9.3 - https://fedoraproject.org/wiki/Features/Ruby_1.9.3
19:29:23 <nirik> .fesco 773
19:29:24 <zodbot> nirik: #773 (F17 Feature: Ruby 1.9.3 - https://fedoraproject.org/wiki/Features/Ruby_1.9.3) – FESCo - https://fedorahosted.org/fesco/ticket/773
19:29:27 <nirik> +1
19:29:28 <mmaslano> +1
19:29:39 <pjones> +1
19:29:41 <mjg59> +1
19:29:41 <sgallagh> +1
19:29:49 <t8m> +1
19:29:49 <mitr> +1
19:30:13 <nirik> #agreed feature is approved.
19:30:42 <nirik> #topic  #774	F17 Feature: SELinux Deny Ptrace - https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
19:30:42 <nirik> .fesco 774
19:30:44 <zodbot> nirik: #774 (F17 Feature: SELinux Deny Ptrace - https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace) – FESCo - https://fedorahosted.org/fesco/ticket/774
19:31:05 <mmaslano> +1
19:31:15 <t8m> +1
19:31:19 <pjones> +1
19:31:29 <nirik> +1. I'd almost want it on by default, but I'm sure that would cause pain and yelling.
19:31:30 <mitr> +1 , and /me would eventually like to be able to enable this by default without impacting normal operation
19:31:32 <limburgher> +1
19:31:38 <sgallagh> +1
19:31:53 <nirik> #agreed feature is approved.
19:32:17 <pjones> though my real question is: how does this interact with abrt?  does abrt wind up using ptrace at all?
19:32:17 <nirik> #topic #775	F17 Feature: PrivateTmp services - https://fedoraproject.org/wiki/Features/ServicesPrivateTmp
19:32:17 <nirik> .fesco 775
19:32:18 <mitr> nirik: I imagine setroubleshoot would make flipping the switch painless, but the number of programs that currently require ptrace for normal operation seems pretty large
19:32:19 <zodbot> nirik: #775 (F17 Feature: PrivateTmp services - https://fedoraproject.org/wiki/Features/ServicesPrivateTmp) – FESCo - https://fedorahosted.org/fesco/ticket/775
19:32:28 <mjg59> Worth mentioning that it also breaks strace?
19:32:30 <mitr> pjones: I think it gets a core file on stdin
19:33:04 <pjones> Well, that was fun.
19:33:31 <sgallagh> +1 to ServicesPvtTmp
19:33:36 <mitr> Is there a general concern WRT kerberos?
19:33:38 <pjones> +1 as well
19:34:00 <nirik> +1 here as well
19:34:05 <sgallagh> mitr: We're hoping to move kerberos over to using /var/run/user
19:34:08 <mjg59> +1
19:34:22 <sgallagh> And updating gssd and friends to look there by default
19:34:37 <mitr> sgallagh: Fair enough, so it's being handled...
19:34:41 <mitr> +1 to feature
19:34:43 <mmaslano> +1
19:35:13 <t8m> ok +1
19:35:15 <nirik> #agreed feature is approved.
19:35:22 <nirik> #topic #753	F17 Feature: Wallaby - https://fedoraproject.org/wiki/Features/Wallaby
19:35:26 <nirik> .fesco 753
19:35:27 <zodbot> nirik: #753 (F17 Feature: Wallaby - https://fedoraproject.org/wiki/Features/Wallaby) – FESCo - https://fedorahosted.org/fesco/ticket/753
19:35:58 <sgallagh> +1 plus disclaimer about the feature process
19:36:03 <t8m> why not +1
19:36:05 <nirik> +1
19:36:12 <mitr> sgallagh: specifically?
19:36:16 <mjg59> +1
19:36:30 <mitr> +1 - sounds vaguely like puppet, but google doesn't know about any connection
19:36:38 <sgallagh> mitr: Eh, just a heavily-targeted feature interesting to a very small subset of users
19:36:40 <mmaslano> +1
19:37:01 <mitr> sgallagh: Ah, ok.
19:37:14 <nirik> #agreed feature is approved.
19:37:25 <pjones> +1 why not
19:37:55 <nirik> ok, thats finally the end, however... we had some more in ready for wrangler...
19:38:02 <nirik> https://fedoraproject.org/wiki/Category:FeatureReadyForWrangler
19:38:11 <nirik> rbergeron: any of those ready? or those for next week?
19:38:28 <abadger1999> (Note for mjg59 and nirik Re: Opa  licensing  -- The OPA upstream considers anything written in OPA to be licensed under the AGPL unless you buy a separate license from them: http://blog.opalang.org/2011/08/opa-license-contributions.html  )
19:38:35 <mjg59> Let's say next week?
19:38:39 <nirik> abadger1999: really? wow.
19:38:39 * mull pinged rbergeron about Euca, but she just got home
19:38:40 <mjg59> abadger1999: Ok that makes sense
19:38:52 <sgallagh> abadger1999: Oof. In that case, should we be shipping it?
19:38:58 <mitr> nirik: Only network-zones has any comment by rbergeron on the talk page
19:39:05 <abadger1999> sgallagh: It's not closed source....
19:39:15 <sgallagh> I... guess?
19:39:21 * nirik is ok with doing any features that are ready by tomorrow next week.
19:39:25 <mitr> sgallagh: does that differ from the old mysql dsituation?
19:39:31 <pjones> abadger1999: wow.  that's bordering on "maybe we shouldn't be shipping this"
19:39:42 <t8m> nirik, I think we can do them next week
19:39:42 <nirik> #topic Opa redux
19:39:50 <mjg59> pjones: Eh, it's along the lines of anything that has a GPL runtime library
19:39:52 <nirik> do we want to revisit that feature/package?
19:40:04 <mitr> Yeah, we've managed 25 features today, so we probably can handle 6 next week :)  all of them are fairly new
19:40:23 <pjones> mjg59: hence the "maybe".
19:40:53 <nirik> I guess it's up to people using that to comply with the license.
19:41:00 <t8m> As this is really open source I don't think we should block the opa package from fedora however it's questionable if the advertising-by-feature is justified here
19:41:01 * abadger1999 thinks opa-agpl shouldn't affect the "feature" or inclusion... will just affect adoption and future license auditing.
19:41:29 <nirik> AGPLv3 is a valid license for fedora packages as well.
19:41:51 <sgallagh> Eh, let's run with it.
19:41:59 <nirik> so, I'm fine with leaving it as is, but perhaps note in the feature page/release notes about the licensing?
19:42:08 <sgallagh> nirik: +1
19:42:26 <sgallagh> Perhaps mandate that the RPM description should include that caveat as well?
19:43:36 * mitr really doesn't know whether to advertise the company or not
19:43:42 <nirik> or perhaps FPC could look at any additional documentation needs for AGPL packages?
19:44:04 <nirik> anything more on this? or shall we move on?
19:44:11 <abadger1999> In the long run, I agree with mjg59 -- it's no different than gpl on runtime libraries.
19:44:14 <mjg59> It's not the AGPL itself that's the problem. It's that the output of the package is considered a derivative work.
19:44:38 <mjg59> That's a little unusual for what's effectively a compiler, but it's not without precedent
19:44:44 <nirik> even that isn't a problem, it's more than people may not expect it and be ready to meet the licensing needs.
19:45:22 <abadger1999> In the shorter term, people might be confused that gcc doesn't demand that the programs compiled against it be gpl licensed whereas opa does make that demand.
19:45:46 * nirik nods.
19:46:01 <nirik> so, document and move on? ask fpc to visit?
19:46:14 * abadger1999 is for document and move on
19:46:27 <mitr> I'd assume that people who want to ignore licenses will ignore this just as well as anything else, and people who are meticulous will notice (BTW some of the LGPL requirements are quite surprising for a binary-only distributor)
19:46:56 <nirik> #info OPA should document the output licensing
19:47:00 * nirik is fine with that.
19:47:12 <nirik> I had one more thing before the lovely open floor...
19:47:12 <sgallagh> +1 document and move on
19:47:14 <pjones> mitr: yes, but there's some expectation that compilers have exemptions, which is sortof a shortcut for not /needing/ to be meticulous about their output.
19:47:43 <pjones> nevertheless, it does appear to comply with our rules, it's just messy.
19:47:47 <mitr> pjones: *shrug* I was thinking about the mandatory runtime
19:47:50 <mitr> +1 document and move on
19:48:01 <nirik> #topic EOL package branches default acls
19:48:11 <nirik> so, I'd like to ask fesco for any opinion on:
19:48:16 <nirik> https://fedorahosted.org/fedora-infrastructure/ticket/3094
19:48:30 <nirik> basically do we care what acls the git repos keep for eol releases?
19:48:43 <nirik> if we nuke them all and default to deny it saves info that pkgdb needs to keep
19:49:00 <notting> worksforme. (wow, this meeting is still going)
19:49:03 <sgallagh> Seems sane to me. We're not realistically allowing changes to be made.
19:49:14 <pjones> +1 to not caring.  EOL is EOL.
19:49:15 <nirik> welcome back notting. ;)
19:49:55 * nirik is fine with defaulting to deny and saving space/time/pkgdb cycles.
19:49:58 <limburgher> +1
19:50:07 <mmaslano> I thought EOL are blocked anyway,so why should allow changes +1
19:50:29 <nirik> #agreed fesco is fine with default acls for eol releases.
19:50:33 <t8m> +1
19:50:43 <nirik> #topic Open Floor
19:50:47 <mitr> +1 to blocking access
19:50:49 <nirik> dmalcolm: you had something?
19:50:54 <dmalcolm> hold on
19:51:03 <pjones> holding.
19:51:05 <dmalcolm> I'm sorry for not being as on top of feature process as I should be; I'm dealing with a Python security vulnerability right now.
19:51:05 <dmalcolm> I suspect this is more a question for rbergeron
19:51:06 <dmalcolm> Questions re: http://fedoraproject.org/wiki/Features/StaticAnalysisOfCPythonExtensions
19:51:06 <dmalcolm> In particular, see the "Current Status":
19:51:06 <mitr> ... but I wonder about archiving the data in case we needed to look up past history
19:51:19 <dmalcolm> F16 shipped with the static checker, but with only some minor tests enabled, that I didn't feel were particularly exciting.
19:51:19 <dmalcolm> Given this, I tried to revoke this for F16, but somehow I think it still got listed as a F16 feature.
19:51:19 <dmalcolm> The "really compelling" part of it described on that feature page *is* now working, and I've been using it to find memory leaks in C Python extension modules (and other bugs).
19:51:51 <dmalcolm> I want to do an F17 feature of this with this new code
19:52:05 <dmalcolm> QUESTION: Do I start a new feature page, or reuse the old one?
19:52:34 <limburgher> I'd do a new one, based on and referencing the old.
19:52:47 <dmalcolm> "StaticAnalysisOfPythonRefCounts" perhaps
19:52:57 <mitr> Yeah, it seems this was in f16 release notes
19:53:02 <dmalcolm> that scopes it better also
19:53:07 <mitr> A clone of the page seems cleanest.
19:53:20 <nirik> yeah, I'd do a new one.
19:53:34 <dmalcolm> mitr: and then hack it into shape? (before the deadline, of course)
19:53:44 <limburgher> That way people don't have to look at the wiki edits to see history.
19:53:49 <pjones> yeah, I'd also say do a new one.
19:53:55 <dmalcolm> ok, thanks.
19:53:56 <dmalcolm> will do
19:54:04 <dmalcolm> thanks.  that was my question
19:54:17 <nirik> dmalcolm: deadline to submit is tomorrow tho... ;( So, get it in and we can talk about it next week?
19:54:21 * dmalcolm goes back to security vuln
19:54:30 <dmalcolm> nirik: it will be a long day :)
19:54:33 <notting> we can also consider exceptions if necessary
19:54:40 <notting> although obviously not encouraged
19:55:06 <nirik> yeah.
19:55:09 <nirik> anything else for open floor?
19:55:10 <dmalcolm> will try to get it in by deadline
19:55:21 <sgallagh> I'd like to bring up the topic of Closed/UPSTREAM (at the risk of starting a flame war)
19:55:33 <nirik> #topic Cloed/Upstream bugs
19:55:52 <mjg59> Given that we're almost at two hours, I'd like to suggest doing this next week
19:56:02 * nirik is fine with that as well.
19:56:04 <mmaslano> great idea
19:56:15 <sgallagh> I'm okay with that
19:56:17 <limburgher> Yes.
19:56:45 <t8m> please
19:56:49 <nirik> #action defer to next week.
19:56:56 <nirik> #topic Open floor again
19:57:10 <nirik> will close out in a minute if nothing more comes up...
19:57:26 <mmaslano> next chair?
19:57:30 <nirik> ah yes.
19:57:36 <nirik> who wants the hot seat next week?
19:57:53 <mmaslano> I can
19:58:04 <nirik> #action mmaslano will chair next week
19:58:06 <nirik> thanks!
19:58:14 <nirik> thanks for coming everyone.
19:58:21 <nirik> #endmeeting