17:56:33 <mmaslano> #startmeeting FESCO (2012-01-30)
17:56:33 <zodbot> Meeting started Mon Jan 30 17:56:33 2012 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:56:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:56:39 <mmaslano> #meetingname fesco
17:56:39 <zodbot> The meeting name has been set to 'fesco'
17:56:44 <mmaslano> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:56:44 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:56:53 * nirik is here.
17:56:58 <pjones> hello.
17:57:07 <sgallagh> Konnichiwa
17:57:19 <mmaslano> hm it's early, let's wait few minutes
17:57:34 <pjones> indeed, it is.
18:00:28 * limburgher here
18:00:42 <mjg59> Here
18:00:55 <sgallagh> mmaslano: Recommendation: let's run through the new Features as quickly as possible. Save any dissention to the end, so we can at least rubber-stamp all the ones that are trivially-acceptable.
18:01:04 * notting is here
18:01:08 <mitr> Hello
18:01:14 <sgallagh> So if there's any question, defer it and come back
18:01:14 <mitr> sgallagh: +1
18:01:17 <limburgher> sgallagh: I concur
18:01:26 <t8m> Hello
18:01:46 <mmaslano> fine, let's start with old business before we drop
18:01:47 <t8m> sgallagh, that seems like a good plan
18:01:55 <mmaslano> #topic init process
18:02:29 <mmaslano> #topic Rework Live CD - https://fedoraproject.org/wiki/Anaconda/Features/ReworkLiveCD
18:02:33 <mmaslano> .fesco 752
18:02:35 <zodbot> mmaslano: #752 (F17 Feature: Rework Live CD - https://fedoraproject.org/wiki/Anaconda/Features/ReworkLiveCD) – FESCo - https://fedorahosted.org/fesco/ticket/752
18:03:00 <nirik> so, this will require work to be used for rel-eng...
18:03:30 <mmaslano> I think there's no other choice than agree with rel-neg
18:03:30 <nirik> so, a) approve feature as is, b) ask them to wait for f18 for rel-eng to be using it
18:03:32 <sgallagh> Rel-eng requests deferral to F18, I'm inclined to agree
18:03:37 <notting> i'm fine with the feature as 'here's a new way you can make livecds'
18:03:49 <nirik> the downside of that is that it gets no testing now. ;) (or not as much)
18:03:54 <mmaslano> #proposal wait for F-18
18:03:58 <mitr> +1
18:03:59 <t8m> mmaslano, +1
18:04:00 <limburgher> mmaslano: +1
18:04:01 <sgallagh> mmaslano: +1
18:04:12 * mmaslano +1
18:04:12 <mjg59> I'm fine with this as an F17 feature (given that the code is going to be there) providing that the language is changed a little
18:04:28 <mjg59> It's something that's still relevant to downstreams
18:04:40 <pjones> yeah, I'm for it with some language change.
18:04:55 <mmaslano> +5
18:04:57 <t8m> (as that does not mean, that they cannot put the code into distribution, just properly anounce it in F18 timeframe)
18:05:13 <mjg59> #proposal Accept as F17 feature providing the language is changed to make it clear it's not being used for the F17 liveCDs
18:05:15 <sgallagh> Yeah, I'd like to see this hit rawhide ASAP
18:05:19 <t8m> mjg59, too late
18:05:24 <mjg59> t8m: Too late for what?
18:05:35 <sgallagh> mjg59: It already has +5 on deferring to F18
18:05:38 <t8m> mjg59, we already voted for defer it seems +5
18:05:48 <mjg59> Yeah uh that's not really the way democracy works here
18:05:50 <mmaslano> is anyone willing to take it back?
18:05:58 <mjg59> These aren't exclusive options
18:06:06 <pjones> t8m: just because 5 people voted doesn't mean discussion is finished.
18:06:31 <mmaslano> really?
18:06:35 <sgallagh> mjg59: In as a feature vs out as a feature aren't exclusive?
18:06:37 <t8m> sure, discussion is not finished
18:06:44 <nirik> if the feature is clear that it's a preview/not yet used for composing our media, I guess I would be ok with it. The downside there is that people will use it and find different bugs, but then at least they are finding bugs. :)
18:06:47 <pjones> mmaslano: it never has before in fesco anyway.
18:06:51 <limburgher> I'm fine with it in rawhide, but waiting for f18 for rel-eng to use it.  So as it site, yes, wait for f18.
18:06:59 <mjg59> Is there anyone who voted for it to be deferred to F18 who would be happy with it in F17 providing that it's made clear it's not being used for the F17 composes?
18:07:10 <limburgher> mjg59: Myself.
18:07:13 <mjg59> Ok
18:07:21 <limburgher> More testing that way.
18:07:28 <mjg59> So shall we vote on that?
18:07:40 <t8m> I have no problem with the code in F17, I just don't want to confuse things with it being announced as F17 feature
18:07:51 <mjg59> t8m: It's something that's relevant to our downstreams
18:07:54 <mmaslano> yes, exactly
18:07:59 <pjones> mjg59: +1 to changing the language to say rel-eng isn't using it yet.
18:08:10 <nirik> t8m: yeah, me too, but if they change wording to make that clear it may be ok.
18:08:10 <sgallagh> mjg59: I doubt that our downstreams are going to use it before we do
18:08:23 <mjg59> sgallagh: It's a feature that is there for our downstreams to use if they wish to
18:08:23 <limburgher> +1 as well.
18:08:25 <pjones> sgallagh: no, but they're going to need to prepare for it just like releng is
18:08:28 <t8m> mjg59, I think the downstreams can use it regardless if it is announced as a feature or not
18:08:39 <pjones> sgallagh: which means it's better to say it's a feature earlier so that they're informed.
18:08:42 <mjg59> t8m: Yes, but anyone can use anything regardless of whether or not it's announced as a feature
18:08:42 <sgallagh> pjones: I realize that, but I think there are better mechanisms for communicating that than Feature pages
18:08:51 <pjones> o_O
18:08:55 <t8m> sgallagh, exactly
18:08:56 <mjg59> sgallagh: Welcome to every fesco meeting about features
18:08:57 * nirik is +1 to allowing it for f17 provided it's clear that it's not being used to compose fedora live media yet.
18:09:06 <mjg59> +1
18:09:08 <mitr> mjg59: I guess the question is - do our downstreams use anything else than Koji?  If they use Koji, they should naturally inherit support for the new software
18:09:13 <sgallagh> -1 for previously-stated reasons
18:09:17 <t8m> -1
18:09:40 <notting> i am +1 to a reworded feature for f17
18:09:53 <mjg59> I make that +5
18:09:53 <mitr> weak -1
18:10:27 <mmaslano> #agreed Accept as F17 feature providing the language is changed to make it clear it's not being used for the F17 liveCDs
18:11:02 <mmaslano> now to new features!
18:11:09 <sgallagh> mmaslano: no
18:11:11 <pjones> wooo.
18:11:16 <mjg59> mmaslano: Do we want to cover the usrmove stuff?
18:11:18 <limburgher> I thought we had usrmove to disucss.
18:11:20 <sgallagh> Actually, I take that back
18:11:25 <mmaslano> sgallagh: we can spent hours on that
18:11:28 <mitr> I'd suggest leaving usrmode for later
18:11:31 <sgallagh> Let's hold UsrMove until after the rubber-stamping
18:11:32 <limburgher> Good point.
18:11:42 <mjg59> Ok
18:11:43 <mmaslano> sgallagh: don't you want close any ticket today?
18:11:53 * nirik doesn't care either way I guess.
18:11:59 <sgallagh> mmaslano: I changed my answer :)
18:12:04 <pjones> maybe we should do the rubber stamping differently.  everybody, list features you've got objections to ;)
18:12:25 <t8m> I'd rather followed the process
18:12:32 <t8m> You know - democracy...
18:12:41 <mmaslano> so please fast and features with question could be defered for next time
18:12:45 <mmaslano> #topic CUPS colord support - https://fedoraproject.org/wiki/Features/CUPS_colord_Support
18:12:50 <nirik> sure, +1.
18:12:51 <mmaslano> .fesco 780
18:12:53 <mjg59> +1
18:12:53 <zodbot> mmaslano: #780 (F17 Feature: CUPS colord support - https://fedoraproject.org/wiki/Features/CUPS_colord_Support) – FESCo - https://fedorahosted.org/fesco/ticket/780
18:12:56 <mitr> +1
18:13:02 <sgallagh> +1
18:13:02 <t8m> +1
18:13:05 <notting> wfm. +1
18:13:12 <limburgher> +1
18:13:12 <mmaslano> +1
18:13:15 <pjones> +1
18:13:38 <sgallagh> Woo! Unanimous :)
18:13:57 <mmaslano> #agreed 9:0
18:14:00 <pjones> t8m: I was suggesting changing the (really awful) proces.
18:14:02 <pjones> process.
18:14:03 <mmaslano> #topic Cloudstack - https://fedoraproject.org/wiki/Features/Cloudstack
18:14:09 <mmaslano> .fesco 781
18:14:10 <zodbot> mmaslano: #781 (F17 Feature: Cloudstack - https://fedoraproject.org/wiki/Features/Cloudstack) – FESCo - https://fedorahosted.org/fesco/ticket/781
18:14:25 <mjg59> +1
18:14:25 <sgallagh> +1
18:14:25 <mitr> +1
18:14:28 <t8m> +1
18:14:31 <mmaslano> +1
18:14:33 <limburgher> +1
18:14:35 <nirik> sure, +1
18:14:39 <pjones> +1, why not.
18:14:46 <notting> +1
18:14:51 <mmaslano> #agreed 9:0
18:14:52 <t8m> pjones, we could debate the process changes for long time :)
18:15:03 <mmaslano> #topic Cluster - https://fedoraproject.org/wiki/Features/Cluster
18:15:07 <mitr> +1
18:15:08 <mmaslano> .fesco 782
18:15:11 <zodbot> mmaslano: #782 (F17 Feature: Cluster - https://fedoraproject.org/wiki/Features/Cluster) – FESCo - https://fedorahosted.org/fesco/ticket/782
18:15:14 <mmaslano> +1
18:15:19 <mjg59> +1
18:15:30 <notting> abadger1999 is taking redoing the feature process as a potential board AI. i'd direct feature rage his way for potential solutions
18:15:38 <t8m> +1 although the name seems really ambiguous
18:15:43 <nirik> sure, +1 on cluster changes.
18:15:46 <notting> +1... please fix the title to be more descriptive
18:16:01 <limburgher> +1 agreed, better title needed.
18:16:11 <sgallagh> +1
18:16:14 <pjones> notting: I really just meant our process for voting on them, not the feature process in general.
18:16:14 <abadger1999> yes please, feature process suggestoins to me.
18:16:21 <pjones> +1 though on this one.
18:16:41 <mmaslano> #agreed on fixing the title to be more descriptive. But agreed 9:0
18:16:47 <mmaslano> #topic Eucalyptus - https://fedoraproject.org/wiki/Features/Eucalyptus
18:16:54 <mmaslano> .fesco 784
18:16:56 <zodbot> mmaslano: #784 (F17 Feature: Eucalyptus - https://fedoraproject.org/wiki/Features/Eucalyptus) – FESCo - https://fedorahosted.org/fesco/ticket/784
18:17:01 <mjg59> +1
18:17:02 <nirik> +1
18:17:04 <t8m> +1
18:17:05 <pjones> obviously we should -1 this just to mess with gdk
18:17:06 <sgallagh> I don't like the completion percentage
18:17:09 <mmaslano> +1
18:17:13 <mitr> +1
18:17:28 <limburgher> +1
18:17:28 <pjones> (seriously though, +1)
18:17:30 <notting> +1... it happens or we punt. *shrug*
18:17:30 <sgallagh> I'm +1 if it'll make it
18:17:31 <limburgher> pjones: :)
18:17:31 <mmaslano> sgallagh: defer or ok?
18:17:49 <gholms> If it doesn't make it we can punt it to F18, right?
18:18:01 <sgallagh> mmaslano: I'm +1. If it doesn't make it, we'll defer it then
18:18:09 <pjones> gholms: if it doesn't make it, it goes away unless they refile for f18.
18:18:10 <mmaslano> #agreed 9:0
18:18:15 <mmaslano> #topic JBoss AS7 - https://fedoraproject.org/wiki/Features/JBossAS7
18:18:20 <mmaslano> .fesco 785
18:18:21 <zodbot> mmaslano: #785 (F17 Feature: JBoss AS7 - https://fedoraproject.org/wiki/Features/JBossAS7) – FESCo - https://fedorahosted.org/fesco/ticket/785
18:18:26 <mmaslano> nice, +1
18:18:28 <mjg59> +1
18:18:34 <limburgher> +1
18:18:34 <nirik> +1, but it's a pretty gigantic task. Good luck. ;)
18:18:38 <notting> +1
18:18:42 <sgallagh> +1
18:18:43 <pjones> +1
18:18:47 <mitr> +1
18:18:47 * mjg59 wonders if he could generate a macro to just +1 the moment a URL with Features in comes up
18:18:49 <t8m> +1
18:19:01 <mmaslano> #agreed 9:0
18:19:04 <pjones> mjg59: we're apparently not going to discuss this inanity.
18:19:07 <mmaslano> #topic NetworkManager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot
18:19:09 <mjg59> +1
18:19:12 <mmaslano> .fesco 786
18:19:13 <zodbot> mmaslano: #786 (F17 Feature: NetworkManager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot) – FESCo - https://fedorahosted.org/fesco/ticket/786
18:19:20 <mitr> +1
18:19:22 <pjones> +1
18:19:29 <mmaslano> +1
18:19:32 <sgallagh> +1
18:19:35 <limburgher> +1
18:19:37 <nirik> +1
18:19:38 <t8m> +1
18:20:00 <mmaslano> notting: ?
18:20:15 <notting> ack. +1
18:20:25 <mmaslano> #agreed 9:0
18:20:30 <mmaslano> #topic XAPI (Xen API) - https://fedoraproject.org/wiki/Features/XAPI
18:20:35 <mmaslano> .fesco 787
18:20:36 <zodbot> mmaslano: #787 (F17 Feature: XAPI (Xen API) - https://fedoraproject.org/wiki/Features/XAPI) – FESCo - https://fedorahosted.org/fesco/ticket/787
18:20:40 <sgallagh> +1
18:20:42 <mjg59> +1
18:20:46 <notting> ewww
18:20:55 <notting> but eh, +1
18:20:55 <sgallagh> notting: ?
18:21:00 <pjones> +1 I guess :/
18:21:03 <gholms> Heh
18:21:06 <pjones> sgallagh: it has the bad x word
18:21:10 <mmaslano> +1
18:21:12 <nirik> +1 I suppose. :)
18:21:13 <limburgher> +1, though I'd like to see a list of the tools to package.
18:21:15 <mitr> +1
18:21:16 <sgallagh> Sure, KVM is better, but we're not going to refuse :)
18:21:48 <mmaslano> t8m: ?
18:22:26 <t8m> +1
18:22:29 <mmaslano> #agreed 9:0
18:22:32 <mmaslano> #topic Open vSwitch - https://fedoraproject.org/wiki/Features/Open_vSwitch
18:22:36 <mmaslano> .fesco 788
18:22:37 <zodbot> mmaslano: #788 (F17 Feature: Open vSwitch - https://fedoraproject.org/wiki/Features/Open_vSwitch) – FESCo - https://fedorahosted.org/fesco/ticket/788
18:22:46 <sgallagh> +1
18:22:50 <t8m> +1
18:22:55 <mmaslano> +1
18:22:57 <nirik> sure, +1
18:23:08 <limburgher> +1
18:23:20 <sgallagh> (personally, I think this is sorely needed)
18:23:34 <mitr> +1
18:23:36 <cdub> *nod* ;)
18:23:41 <notting> +1
18:23:49 <mjg59> +1
18:24:00 <mitr> (does it make any sense to later integrate this into our network config tools?)
18:24:11 <cdub> yes, but i think that's a later step
18:24:23 <pjones> +1
18:24:29 <mmaslano> #agreed 9:0
18:24:30 <cdub> already working on libvirt integration, for example (NM too)
18:24:38 <mmaslano> #topic Enterprise Networking with NetworkManager - https://fedoraproject.org/wiki/Features/NMEnterpriseNetworking
18:24:43 <mmaslano> .fesco 789
18:24:44 <zodbot> mmaslano: #789 (F17 Feature: Enterprise Networking with NetworkManager - https://fedoraproject.org/wiki/Features/NMEnterpriseNetworking) – FESCo - https://fedorahosted.org/fesco/ticket/789
18:24:54 <mjg59> +1
18:24:55 <nirik> +1
18:24:56 <sgallagh> +1
18:24:58 <mitr> +1
18:24:59 <limburgher> +1
18:24:59 <pjones> +1
18:25:03 <mmaslano> +1
18:25:08 <notting> +1
18:25:11 <t8m> +1 hopefully dan will make it :)
18:25:17 <mmaslano> #agreed 9:0
18:25:22 <mmaslano> #topic PowerManagement - https://fedoraproject.org/wiki/Features/PowerManagementF17
18:25:23 <mitr> How close does this bring us to feature parity with /etc/sysconfig/network-scripts?
18:25:33 <mmaslano> .fesco 790
18:25:34 <zodbot> mmaslano: #790 (F17 Feature: PowerManagement - https://fedoraproject.org/wiki/Features/PowerManagementF17) – FESCo - https://fedorahosted.org/fesco/ticket/790
18:25:50 <mjg59> +1
18:25:53 <mitr> +1
18:25:54 <sgallagh> +1
18:26:05 <notting> +1
18:26:08 <pjones> +1
18:26:11 <limburgher> +1
18:26:12 <t8m> +
18:26:13 <t8m> +1
18:26:13 <nirik> +1 I guess...
18:26:23 <mmaslano> +1
18:26:26 <mmaslano> #agreed 9:0
18:26:32 <mmaslano> #topic OpenStack Essex - https://fedoraproject.org/wiki/Features/OpenStack_Essex
18:26:36 <mjg59> +1
18:26:37 <mmaslano> .fesco 791
18:26:38 <zodbot> mmaslano: #791 (F17 Feature: OpenStack Essex - https://fedoraproject.org/wiki/Features/OpenStack_Essex) – FESCo - https://fedorahosted.org/fesco/ticket/791
18:26:38 <pjones> +1
18:26:46 <mitr> +1
18:26:53 <notting> 01%.  nice! +1
18:26:57 <mmaslano> +1
18:26:59 <t8m> 01% completion?
18:27:02 <rwmjones> it's actually more than that
18:27:06 <t8m> +1
18:27:06 <rwmjones> need to update it ..
18:27:09 <gholms> Heh
18:27:15 <limburgher> +1 how much more, roughly?
18:27:15 <nirik> +1.
18:27:19 <sgallagh> rwmjones: Ballpark of realistic percentage?
18:27:19 <mmaslano> rwmjones: you should
18:27:20 <sgallagh> +1
18:27:23 <pjones> of course it is.  the glory of feature pages is that they're always wrong by design.
18:27:25 <rwmjones> 50%
18:27:30 <limburgher> Better. :)
18:27:33 <rwmjones> upstream isn't released yet tho
18:27:53 <sgallagh> rwmjones: Will you have a feature-complete snapshot by the 14th?
18:27:55 <rwmjones> so we're packaging their RCs
18:28:03 <sgallagh> Ok, good
18:28:19 <rwmjones> yes, upstream and our schedules coincide
18:28:24 <mmaslano> #agreed 9:0
18:28:30 <mmaslano> #topic KVM Guest PMU - https://fedoraproject.org/wiki/Features/KVM_Guest_PMU
18:28:35 <mmaslano> .fesco 792
18:28:37 <zodbot> mmaslano: #792 (F17 Feature: KVM Guest PMU - https://fedoraproject.org/wiki/Features/KVM_Guest_PMU) – FESCo - https://fedorahosted.org/fesco/ticket/792
18:28:37 <mjg59> +1
18:28:39 <mitr> +1
18:28:46 <sgallagh> +1
18:28:53 <limburgher> +1
18:29:04 <t8m> +1
18:29:05 <limburgher> And if this doesn't hit mainline 3.3?
18:29:15 <nirik> +1
18:29:21 <jforbes> limburgher: it is already there, and in 1.1 upstream.. F17 has the feature right now
18:29:25 <mmaslano> +1
18:29:26 <notting> +1
18:29:30 <limburgher> jforbes: Excellent.
18:29:41 <jforbes> limburgher: basically the only reason it isn't 100%, it because I haven't written test case documentation :)
18:29:48 <limburgher> jforbes: :)
18:29:57 <mmaslano> #agreed 8:0
18:30:02 <mmaslano> #topic KVM Live Block Migration - https://fedoraproject.org/wiki/Features/KVM_Live_Block_Migration
18:30:08 <mmaslano> .fesco 793
18:30:09 <zodbot> mmaslano: #793 (F17 Feature: KVM Live Block Migration - https://fedoraproject.org/wiki/Features/KVM_Live_Block_Migration) – FESCo - https://fedorahosted.org/fesco/ticket/793
18:30:31 <mitr> +1
18:30:34 <pjones> +1
18:30:34 <limburgher> +1
18:30:36 <sgallagh> +1
18:30:37 <nirik> +2
18:30:37 <mjg59> +1
18:30:38 <t8m> +1 interesting feature
18:30:38 <mmaslano> +1
18:30:45 <notting> +1
18:30:50 <pjones> nirik: a war of escalation, I see.
18:30:53 <t8m> nirik, don't cheat even if you so much want it :D
18:30:57 <mmaslano> nirik: doesn't help
18:30:57 <nirik> :)
18:31:06 <nirik> sorry... yes, I am for the feature.
18:31:13 <mmaslano> #agreed 9:0
18:31:18 <gholms> Looks like +10 to me. :P
18:31:19 <mmaslano> #topic Thin provisioning improvements in KVM - https://fedoraproject.org/wiki/Features/KVMThinProv
18:31:25 <mmaslano> .fesco 794
18:31:27 <zodbot> mmaslano: #794 (F17 Feature: Thin provisioning improvements in KVM - https://fedoraproject.org/wiki/Features/KVMThinProv) – FESCo - https://fedorahosted.org/fesco/ticket/794
18:31:52 <mjg59> +1
18:31:55 <sgallagh> +1 Sounds nifty
18:31:57 <t8m> +1
18:31:58 <mmaslano> +1
18:32:01 <limburgher> +1
18:32:09 <mitr> +1
18:32:10 <nirik> +1
18:32:17 <notting> +1
18:32:39 <mmaslano> #agreed 8:0
18:32:40 <pjones> +1
18:32:49 <mmaslano> #agreed 9:0
18:32:55 <mmaslano> #topic Static Analysis of Python Reference Counts - https://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts
18:33:02 <mmaslano> .fesco 795
18:33:02 <mjg59> +1
18:33:03 <zodbot> mmaslano: #795 (F17 Feature: Static Analysis of Python Reference Counts - https://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts) – FESCo - https://fedorahosted.org/fesco/ticket/795
18:33:06 <nirik> +1 here
18:33:11 <pjones> big +1
18:33:14 <mmaslano> +1
18:33:25 <sgallagh> +1
18:33:33 <t8m> +1
18:33:34 <notting> +1
18:33:37 <limburgher> +1 Yes.
18:33:38 <mitr> +1, great stuff
18:33:54 <mmaslano> #agreed 9:0
18:34:02 <mmaslano> #topic Network Zones - https://fedoraproject.org/wiki/Features/network-zones
18:34:07 <mmaslano> .fesco 796
18:34:08 <zodbot> mmaslano: #796 (F17 Feature: Network Zones - https://fedoraproject.org/wiki/Features/network-zones) – FESCo - https://fedorahosted.org/fesco/ticket/796
18:34:19 <mjg59> +1
18:34:32 <mitr> Shall we talk about firewall-default first?  This is dependent on it.
18:34:35 <nirik> +1. Can custom zones be defined/used?
18:35:05 <limburgher> mitr: might be wise.  Or should they two be one feature?
18:35:14 <limburgher> s/they/the/
18:35:37 <mmaslano> ok what about firewalld
18:35:40 <mmaslano> #topic firewall-d - default firewall solution -- https://fedoraproject.org/wiki/Features/firewalld-default
18:35:41 <t8m> mmaslano, please defer this after the firewalld feature
18:35:44 <mjg59> +1
18:35:46 <t8m> great
18:35:46 <mmaslano> .fesco 797
18:35:49 <zodbot> mmaslano: #797 (F17 Feature: firewall-d - default firewall solution -- https://fedoraproject.org/wiki/Features/firewalld-default) – FESCo - https://fedorahosted.org/fesco/ticket/797
18:36:11 <mitr> So, some concerns:
18:36:43 <mitr> - this lists libvirtd as dependency. What about NetworkManager, wireshark (hardcodes /sbin/iptables), s-c-printer (uses the old D-Bus interface)?
18:36:50 <mitr> - talks about a tray applet, do we even have these?
18:37:02 <mitr> - the fedorahosted repo has not had a single commit since last February
18:37:21 <limburgher> Eek.
18:37:42 <mitr> I'm for the idea, but I really want to avoid a NetworkManager-style situation of two permanent dual stacks.
18:37:54 * nirik agrees with mitr on that
18:38:23 <limburgher> Yes, plus it shouldn't require any particular desktop.  GNOME3 doesn't to tray applets, does it?
18:38:30 <mmaslano> #proposal defer to next week, test this firewall and ask Thomas about details mentioned by mitr
18:38:42 <t8m> mmaslano, +1
18:38:43 <limburgher> mmaslano: +1
18:38:50 <sgallagh> mmaslano: +1
18:39:07 <nirik> sure, ok with me.
18:39:15 <mitr> +1, I'm afraid I didn't have time to discuss this before the meeting
18:39:17 * mmaslano is obviously +1
18:39:19 <notting> i don't think we *need* to do that, but it doesn't hurt
18:39:23 <pjones> limburgher: it does, they're just at a different place.  if my understanding of the term holds true, anyway.
18:39:51 <limburgher> pjones:  K.  I just hadn't needed to know yet. :)
18:40:05 <notting> so, weak +1 to mmaslano, would also potentially be +1 to not doing so
18:40:14 <mjg59> 0
18:40:21 <nirik> also, other desktops? ie, does it do systray at all as well?
18:40:25 <pjones> solid 0 on my part as well.
18:40:53 <mitr> nirik: I suppose we don't want a permanent applet in the UI in any case - Aunt Tillie should never have to observe the status of the firewall
18:41:08 <nirik> perhaps not.
18:41:15 <mitr> but that's not a FESCo level question I think
18:41:18 <mmaslano> #agreed 6:0
18:41:33 <mmaslano> back to previous ticket, which could be also defered...
18:41:33 <mitr> OK, where does this leave network-zones?
18:41:34 <mjg59> Ok so we push the network zones back to next week as well?
18:41:49 <limburgher> I think we have to.
18:41:51 <mmaslano> #topic Network Zones - https://fedoraproject.org/wiki/Features/network-zones
18:41:52 <nirik> yeah
18:41:55 <mjg59> And can we not use the term Aunt Tillie, at least not unless there's an equivalent amount of Uncle Thomas as well?
18:41:56 <mmaslano> .fesco 7976
18:41:57 <zodbot> mmaslano: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:41:59 <mmaslano> .fesco 796
18:42:01 <zodbot> mmaslano: #796 (F17 Feature: Network Zones - https://fedoraproject.org/wiki/Features/network-zones) – FESCo - https://fedorahosted.org/fesco/ticket/796
18:42:24 <mmaslano> #proposal defer to next week because of firewalld
18:42:28 <sgallagh> +1
18:42:31 <limburgher> mjg59: +1 We could just say "My Parents" :)
18:42:32 <mjg59> Because, you know, asserting that 50% of our potential userbase are predisposed to having more naive requirements is kind of insulting
18:42:32 <t8m> +1 to defer
18:42:33 <mitr> mjg59: The only other recognizable therm I could think of involved the F letter, so ... :(
18:42:34 <sgallagh> (to deferring)
18:42:34 <nirik> +1
18:42:57 <mjg59> +1 to deferring
18:42:58 <mitr> +1 to deffering
18:43:00 <notting> sure, defer. +1
18:43:03 <pjones> +1 defer
18:43:05 <mmaslano> +1 to defer
18:43:10 <sgallagh> mjg59: Agreed. My Aunt Tillie runs a botnet :)
18:43:24 <mmaslano> #agreed defet to next week 9:0
18:43:33 <mmaslano> #topic Darkserver GNU Build ID service - https://fedoraproject.org/wiki/Features/Darkserver
18:43:38 <mmaslano> .fesco 783
18:43:39 <zodbot> mmaslano: #783 (F17 Feature: Darkserver GNU Build ID service - https://fedoraproject.org/wiki/Features/Darkserver) – FESCo - https://fedorahosted.org/fesco/ticket/783
18:43:44 <mjg59> +1
18:43:51 <mmaslano> it wasn't filed before deadline
18:43:59 <mmaslano> so, do you want to take it or not?
18:43:59 <t8m> +1 anyway
18:44:01 <nirik> +1 (although not sure many users will know or care about this...)
18:44:07 <pjones> +1 I guess.
18:44:10 <sgallagh> Firmly +0
18:44:15 <mmaslano> +1
18:44:21 <pjones> sgallagh: but at least it's +?
18:44:28 * nirik is ok taking it after the deadline.
18:44:47 <notting> +1-ish? not sure how this is user-visible w/o abrt integration
18:44:53 <sgallagh> pjones: Okay, how about a 0x multiplier? :)
18:44:55 <mmaslano> #agreed on accepting this feature ~6:0
18:45:07 <mitr> +1
18:45:07 <limburgher> +1
18:45:14 <pjones> notting: might be worth it just as a thing you could build other tools to work with
18:45:25 <mmaslano> #agreed on accepting this feature ~8:0
18:45:37 <mmaslano> now we have provenpackager request
18:45:40 <mmaslano> #topic proven Provenpackager request - vondruch
18:45:44 <mmaslano> .fesco 777
18:45:46 <zodbot> mmaslano: #777 (Provenpackager request - vondruch) – FESCo - https://fedorahosted.org/fesco/ticket/777
18:46:01 <mmaslano> I put into ticket why it would be nice to have it approved today
18:46:04 <mitr> notting: I think one diea is to  use this in the retrace server to speed it up
18:46:09 <mmaslano> (yesterday even beter)
18:46:39 * sgallagh voted +1 in the ticket
18:46:43 <notting> no feedback on sponsors list
18:46:52 <mmaslano> could someone look into sponsor list for feedback?
18:46:55 <mmaslano> ah
18:46:59 <mmaslano> I'm +1 too
18:47:09 * nirik is +1 given other folks... I haven't worked with them directly much.
18:47:12 <limburgher> +1
18:47:29 <t8m> +1
18:47:34 <mitr> 25 reviews is ample I think, and given that we've sort of given up on the "experienced in a wide variety of package types" requirement, +1
18:47:37 <mmaslano> I do, he is preparing update of ruby for a long time. Hope, they make it
18:47:40 <notting> per normal procedures, he'd get approved on wednesday at this point
18:48:00 <mmaslano> that's only 2 days for work on 100 packages
18:48:01 <sgallagh> mitr: I think provenpackager is our only reasonable workaround for some other tool limitations as well
18:48:05 <mmaslano> it's better to have 4 ;-)
18:48:14 <sgallagh> (specifically multiple dependencies for bodhi updates)
18:48:38 <mitr> sgallagh: Yeah, weakening the policy wording is on my todo list.
18:48:40 <pjones> I guess I can be +1 to this given our limited ability to provide any kind of real group access.
18:49:01 <mmaslano> I see +1
18:49:09 <mmaslano> I see +6
18:49:38 <mmaslano> #agreed vondruch is provenpackager 6:0
18:49:45 <notting> i'm a -1 merely in that i don't see why we need to jump around procedure here
18:50:28 <mjg59> Given that we've already seemingly decided that following procedure is a great way to spend time
18:50:38 <pjones> mjg59: it sure does accomplish that.
18:51:17 <notting> but... move on.
18:51:20 * mitr will admit to not being vocal about the block voting proposal only because he needed more time to review a few remaining features
18:51:24 <mmaslano> thanks
18:51:47 <mmaslano> #topic proven Provenpackager request - epienbro
18:51:56 <mmaslano> .fesco 757
18:51:57 <zodbot> mmaslano: #757 (Provenpackager request: epienbro) – FESCo - https://fedorahosted.org/fesco/ticket/757
18:52:09 <mmaslano> it's +1:-1
18:52:15 * sgallagh abstains
18:52:43 <rwmjones> I don't get a vote, but I think erik is a very good packager
18:52:57 <nirik> the -1 suggested that we simply add them to all the mingw packages if the maintainer(s) are ok with that.
18:53:14 <t8m> +1
18:53:18 <pjones> but the whole point he was making was that the reason he needs it is for non-mingw packages.
18:53:26 <mmaslano> yes, +1
18:53:27 <limburgher> +1
18:53:31 <t8m> (to be consistent with my vote on vondruch)
18:53:46 <nirik> right. +1 here as well.
18:53:52 <mmaslano> we gave provenpackager to people who need changes in fewer packages.
18:54:00 <notting> i am +1 to granting him pp status as an expediency. he seems well enough adjusted that he does not look like he will run wild
18:54:07 <mitr> +1 to be consistent with vondruch
18:54:10 <mjg59> I'm concerned with the -1
18:54:38 <mjg59> What was the reasoning for that?
18:54:51 <mmaslano> anyone with sponsor list access? ^
18:55:05 <nirik> http://fpaste.org/UfG6/
18:55:21 <nirik> I think they didn't understand that they want to fold back changes into fedora packages.
18:55:27 <rwmjones> remember that mingw packages are like ordinary packages ** 2 .. you often need to read and understand the native package in order to make changes to the mingw-* equivalent
18:55:38 <pjones> yeah, I don't think the -1 understood the request.
18:55:48 <mjg59> Can I just express that I'm incredibly uncomfortable with being asked to overrule people with more experience while unable to see the context of the discussion?
18:55:52 <mitr> So, it's either workaround the process, or workaround the tools :)
18:56:14 <pjones> mjg59: yeah, this process needs some work
18:56:31 <mjg59> So I'm -1 because I don't know who said that or why they said it, but they could be someone I trust to be sensible
18:56:48 <nirik> yeah.
18:56:51 <notting> mjg59: it was ralf?
18:56:52 <mjg59> And I think we need to change this process
18:57:18 <pjones> notting: was it?
18:57:19 * nirik notes aside from the -1 and signature, that was the entirety of the message
18:57:21 <notting> yes
18:57:25 <pjones> meh.
18:57:25 <rwmjones> it was ralf:
18:57:26 <pjones> +1
18:57:27 <rwmjones> -1
18:57:28 <rwmjones> AFAIU, the requestor's request is limited to the mingw packages, many
18:57:28 <rwmjones> of which he already is co-maintainer of.
18:57:28 <rwmjones> I think, it would be more appropriate for somebody with direct access
18:57:29 <mmaslano> and we can review all proven packagers </sarcasm>
18:57:30 <rwmjones> to the packagedb to add him as co-maintainer to all mingw packages,
18:57:32 <rwmjones> instead.
18:57:37 <mjg59> Ok now I'm really unhappy
18:57:44 * nirik sighs
18:57:59 <mjg59> If it is going to be deliberately discussed in private, we shouldn't then just leak the private bits into a public meeting
18:58:17 <pjones> Well, honestly it's absurd that it's private at all.
18:58:17 <rwmjones> ah sorry, is that a private list?  I really didn't know
18:58:20 <abadger1999> <nod>
18:58:27 <abadger1999> I don't believe it's even a list
18:58:28 * nirik thought the content would be fine, but wasn't trying to leak peoples names. :)
18:58:31 <nirik> it's an alias
18:58:38 <abadger1999> so  that there's no archives either
18:58:40 <mjg59> But given that there's more than +5 I think my opinion here is clearly just argument rather than anything that changes the outcome today
18:58:41 <pjones> it's private by accident *because* it isn't a list, mostly.
18:58:45 <mjg59> So we can just defer that discussion to later
18:59:25 <abadger1999> pjones: no
18:59:35 <mmaslano> I see 7:-1
18:59:37 * nirik recalls the 'should all fesco members be sponsors' discussion... wonder if I had some action item there.
18:59:38 <pjones> abadger1999: no?
18:59:48 <abadger1999> It was a conscious decision to have discussion of new sponsors in private.
18:59:53 <pjones> boo.
18:59:55 <abadger1999> You can change that now.
19:00:00 <pjones> indeed.
19:00:01 <mmaslano> nirik: you probably didn't give us link or subscribe us?
19:00:06 <abadger1999> But in the past it was purposeful.
19:00:20 <nirik> well, the emails for that says: "Please respond here, or in the ticket at"
19:00:37 <mmaslano> #agreed epienbro is provenpackager 7:-1
19:00:39 <nirik> mmaslano: no one could recall if that was the policy or not. We discussed it, but never decided it.
19:00:49 <mjg59> I'll file a ticket on this for us to discuss next week?
19:00:56 <mjg59> It's not urgent
19:00:56 <pjones> mjg59: +1
19:00:57 <t8m> mjg59, please do
19:01:00 <nirik> mjg59: sounds good.
19:01:01 <mmaslano> nirik: mjg59: it would be good to think about it and write a draft
19:01:06 <mmaslano> the last ticket
19:01:15 <mmaslano> #topic move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove
19:01:19 <mmaslano> .fesco 690
19:01:21 <rwmjones> can we redact my comments above from the meeting notes?
19:01:22 <zodbot> mmaslano: #690 (F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove) – FESCo - https://fedorahosted.org/fesco/ticket/690
19:01:26 <mjg59> So while I think rel-eng has some valid concerns here:
19:01:34 <nirik> dgilmore: you still around?
19:01:37 <dgilmore> im here
19:01:39 <mmaslano> I had conversation with dgilmore about it
19:01:42 <mjg59> Secondary arches should not hold back work being done on primary architectures
19:01:45 <nirik> rwmjones: not easily. It's not that big a deal. ;)
19:01:52 <mjg59> That's the entire point of them being secondary arches
19:01:57 <pjones> rwmjones: note that somebody else had already pasted an fpaste url to the same thing.
19:02:00 <dgilmore> mjg59: its not about secondary arches
19:02:12 <dgilmore> mjg59: thats just another step of it that needs coordination
19:02:15 <mjg59> dgilmore: You've said that one of the issues is that you need builds for secondary arches
19:02:20 <mmaslano> mjg59: please read the last comment
19:02:35 <dgilmore> mjg59: thats an extra step of what id have to co-ordinate
19:02:44 <mjg59> dgilmore: Yes, but it's not relevant to the decision
19:02:47 <mmaslano> I ment https://fedorahosted.org/fesco/ticket/690#comment:29
19:03:01 <mjg59> dgilmore: Secondary arches are not part of our decision making process
19:03:02 <dgilmore> mjg59: but its not the reason im saying i wont install the updated rpm on the builders
19:03:11 <mjg59> dgilmore: I know. I'm just saying that it's not relevant.
19:03:13 <nirik> kay / haraldh: You guys around?
19:03:25 <haraldh> nirik, yep
19:03:50 <dgilmore> mjg59: it has some relevance, but thats beside the point.
19:04:04 <pjones> it really doesn't.
19:04:06 <mjg59> dgilmore: No, it has no relevance. We do not make decisions on Fedora based on the needs of secondary architectures.
19:04:12 <mmaslano> mjg59: relevant is F-15,16 and EPEL-4,5,6
19:04:27 <nirik> so, what can we do here? a) ask to defer? b) find a way to make rel-eng more happy c) cake ?
19:04:36 <dgilmore> mjg59: maybe you dont. but i do, its a big part of my job
19:04:47 <limburgher> is b) possible?
19:04:52 <mitr> mjg59: Well, if rel-eng declines to do it, do the reasons really matter?  What can we do?
19:04:57 <mjg59> dgilmore: If it's a big part of your job then we need to just drop secondary architectures
19:05:10 <mitr> s/to do/not to do/
19:05:11 <mmaslano> mjg59: please don't go off topic
19:05:22 <dgilmore> limburgher: with lots of testing of the rpm to make sure it does everything its supposed to andf doesnt break anything existing today
19:05:32 <mjg59> mitr: We certainly can't overrule releng
19:05:35 <dgilmore> limburgher: ideally it is also released as a rhel6 update
19:05:37 <mmaslano> as I read in ticket rel-eng and infrastructure decline to do it for F-17
19:06:10 <limburgher> dgilmore:  In Kay's comment #30, it sounds like it might be awhile before RPM even gets in, so that really pushes it back, potentially.  Is there even time?
19:06:12 <pjones> dgilmore: care to make that quantifiable?
19:06:13 <nirik> we did ship a custom rpm in the past. It was a big pain. Having to update it for new updates, having to tell people to get it to build, etc.
19:06:14 <mjg59> So while we've approved it as a feature, if releng won't do it for F17 then it doesn't happen for F17
19:06:19 <limburgher> dgilmore: agreed.
19:06:35 <mjg59> But I think it's perfectly valid for us to disagree with some of releng's reasoning
19:06:41 <jwb> nirik, for the sha change?
19:06:45 * mitr notes that the scope and invasinveness of the changes seems to have grown much since the time it was approved
19:06:48 <nirik> jwb: yep
19:06:55 <jwb> ok
19:07:32 <sgallagh> mitr: I don't think it's grown any more than we originally expected it would (which was to say, too much even when it was approved)
19:07:38 <t8m> mitr, +1
19:08:02 <mmaslano> we are not responsible for deployment, rel-eng is. Their decision is important
19:08:11 <haraldh> mitr, no
19:08:12 <drago01> "<mjg59> So while we've approved it as a feature, if releng won't do it for F17 then it doesn't happen for F17"
19:08:16 <drago01> that sounds broken
19:08:22 <mitr> Frankly, if this feature will be proposed for F18, I'll be voting -1.  Now, I have no idea what that means for F17.
19:08:24 <haraldh> mitr, no, it has not.. elaborate.. what has changed?
19:08:27 <t8m> I'd really expect the switch to usr to happen very early after the F17 branch is open
19:08:28 <mjg59> drago01: What's the alternative? We can't force anyone to do things.
19:08:32 <pjones> mmaslano: but it's not really their decision
19:08:47 <drago01> mjg59: well it is a hard problem
19:08:48 <nirik> t8m: I would have liked to see it land after f16 went out. ;)
19:09:00 <t8m> nirik, yes
19:09:15 <mitr> haraldh: rpm changes were certainly not described in comment #8
19:09:20 <nirik> so, whats the downside to just doing it in f18 and landing it after f17 branches?
19:09:24 <limburgher> I think it needs to happen ASAP after branching for f17, or ASAP after branching for f18.  The more testing the better.
19:09:39 <jwb> er... why the focus on branching?
19:09:42 <mjg59> nirik: It happens a release later and we get to have another 6 months of argument, but otherwise not much
19:09:55 <jwb> this kind of thing should be done as early as possible in whatever release it ships with
19:09:55 <haraldh> mitr, we can remove the rpm changes... they are just a safeguard for our users...
19:10:07 <haraldh> we don't need to have the rpm changes...
19:10:21 <nirik> jwb: right, and that gives it the most time testing it?
19:10:27 <jwb> nirik, correct
19:10:27 <haraldh> it's just to prevent our F15/F16 users to shoot themselves in the foot
19:10:30 <mjg59> haraldh: So what happens if you deploy this now without the builders having an updated rpm?
19:10:52 <haraldh> mjg59, F15/F16 users can shoot themselves in the foot
19:10:57 <haraldh> by installing F17 packages
19:11:07 <nirik> jwb: well, as early as possible for f18 is right after f17 branches from rawhide. ;)
19:11:10 <sgallagh> haraldh: So no upgrade path
19:11:17 <notting> haraldh: doesn't it also affect those currently on rawhide?
19:11:18 <haraldh> which only work with the converted filesystem
19:11:32 <dgilmore> notting: it would.
19:11:37 <haraldh> notting, yes
19:11:38 <mjg59> haraldh: And the build rpm is the one installed on the builders, not in the chroot?
19:11:41 * mmaslano says 15 minute on topic
19:11:46 <jwb> nirik, oh.  assuming we're punting to f18, then yes
19:11:48 * abadger1999 notes that the new rpm wouldn't be in RHEL6 right after branching....
19:11:48 <haraldh> mjg59, right
19:12:12 <mjg59> Ok
19:12:13 <nirik> abadger1999: true, so it would have to wait until it lands.
19:12:15 <mmaslano> haraldh: could you point me where are these changes of rpm mentioned? I couldn't find it before meeting
19:12:30 <mjg59> So from the feature process point of view, and based on what we agreed on, this could absolutely be done for F17
19:12:36 <haraldh> they are not very invasive...
19:12:40 <mjg59> But there's an increased risk to our users if we do that
19:12:42 <haraldh> https://bugzilla.redhat.com/attachment.cgi?id=541981&action=diff
19:13:02 <nirik> mjg59: and additional rel-eng and infra burden. ;)
19:13:06 <haraldh> you can ask panu.. they don't change anything besides providing an internal tag
19:13:20 <haraldh> for "usrmove converted" filesystems
19:13:40 <haraldh> which we will let filesystem-3 conflict with, if it is not set
19:13:49 <haraldh> it's a runtime "provides"
19:13:54 <mjg59> nirik: I don't see how it'd increase rel-eng or infra burdern beyond what we'd agreed to
19:14:12 <mjg59> nirik: If we required the rpm update it would
19:14:13 <haraldh> https://bugzilla.redhat.com/show_bug.cgi?id=761000
19:14:22 <abadger1999> If you don't do the rpm guard... I think fpc gets involved again since that was one of the things we discussed in being okay with it....
19:14:33 <notting> if we don't require an RPM change, everyone on rawhide goes kabloiie
19:14:36 <notting> kablooie, even
19:14:41 <nirik> mjg59: anytime a new rhel6 rpm comes up, we would need to rebuild it. anytime anyone comes yelling that they can't build fedora rpms in rhel6 we would need to point them to the rpm repo and info about it.
19:14:43 <abadger1999> Maybe even both :-)
19:14:55 <mjg59> nirik: Er. Yes. I'm talking about the case where we don't update rpm.
19:15:04 <nirik> mjg59: ah, ok. that seems a very poor option to me.
19:15:10 <haraldh> nirik, point them to me and https://bugzilla.redhat.com/show_bug.cgi?id=761000#c8
19:15:13 <mitr> ( for the record https://fedorahosted.org/fpc/ticket/118 )
19:15:14 <mjg59> nirik: It's an option we were fine with. FPC want it.
19:15:29 <mjg59> So, to summarise:
19:15:34 <mjg59> fesco: Were fine with this
19:15:39 <haraldh> I am willing to take the burden of answering everyone who has problems with the builders and the new rpm !!!!
19:15:40 <mjg59> fpc: Want the rpm update to safeguard users
19:15:42 <nirik> mjg59: ? I don't recall agreeing to break all rawhide users. ;)
19:16:00 <mjg59> releng: won't do the rpm update
19:16:08 <mjg59> I don't think we can do anything here
19:16:21 <dgilmore> mjg59: its not that we wont do the rpm update
19:16:26 <mjg59> There's direct conflicts between the positions of various fedora bodies
19:16:31 <dgilmore> mjg59: its that we want to do it in a supportable manner
19:16:41 <nirik> dgilmore: if haraldh maintains a rpm repo and page with info and we can point all people to him, does that ally your concerns enough?
19:16:48 <mjg59> So either the status-quo is maintained for F17 or the board overrules someone
19:16:58 <mjg59> Or we convince releng to change their mind
19:17:07 <t8m> or we can change our vote even
19:17:29 <mjg59> t8m: I think changing our vote based on something that's not directly related to the feature would be amazingly poor form
19:17:39 <t8m> mjg59, I don't
19:17:44 <pjones> mjg59: yeah, I agree with that, certainly.
19:17:44 <nirik> ideally, I'd prefer it just defer until rpm in rhel6 has the needed support, then land it in rawhide.
19:17:50 <jwb> i doubt the Board is going to do anything.  this is purely technical
19:17:59 <dgilmore> mjg59: that means it needs to be fully tested and vetted. preferablly through the rhel qa process as well as ensuring that we can continue to build everything we build in fedora while also making sure that everything is sustainable
19:17:59 <pjones> jwb: it is?
19:18:09 <mmaslano> mjg59: it's related. The feature was approved because everything was tested and worked like a charm
19:18:12 <dgilmore> nirik: no.
19:18:14 <mitr> mjg59: rel-eng objections rae certainly "direclty related to the feature"
19:18:26 <pjones> it doesn't look at all technical to me.  fpc wants some not-technically-required feature, with good enough reason.
19:18:27 <mjg59> mmaslano: And everything continues to be tested and works like a charm. fpc added an additional requirement.
19:18:39 <jwb> pjones, yes.  it will technically be extremely simple to defer this to f18, when both releng and fpc will be satisfied
19:18:49 <t8m> #proposal Defer the feature to F18
19:18:51 <jwb> pjones, besides.  it's the Board.
19:19:05 <dgilmore> to my understanding filesystem with the extra rpmlib dep is not built and none of it is even properlly testable
19:19:13 <t8m> And I am +1 to that proposal.
19:19:16 <mjg59> So look
19:19:18 <mitr> t8m:  To clarify, is that "defer as accepted", or "defer and vote for f18 again" like other features?
19:19:21 <nirik> haraldh: chances for a rhel6 update with needed support passing out via rhel errata? (dunno how much pain that is)
19:19:34 <mjg59> It's not our job to do anything here
19:19:48 <mjg59> If the feature doesn't reach 100% then it's automatically deferred
19:19:49 <notting> nirik: high.
19:19:58 <mjg59> If fpc want this then it won't reach 100% without it
19:20:07 <sgallagh> mjg59: Except that this particular feature breaks things if it's partially complete
19:20:10 <t8m> mitr, Either way, I don't care if it is done as soon as possible after f17 is branched off rawhide
19:20:16 <notting> so, roughly, the question is "How do we provide the level of testing with the rpm change such that rel-eng is comfortable?"
19:20:24 <mjg59> sgallagh: Yes, and I trust the people involved not to push it unless it's 100%
19:20:26 <limburgher> nottig: <nods>
19:20:38 <mitr> notting: Is that "level of testing + manpower"?
19:20:43 <drago01> mjg59: that's telling the feature owner "go ahead but will get blocked by rel-eng anyway"
19:20:52 <mitr> mjg59: The commits are already in the git repos
19:20:54 <notting> mitr: well, someone's got to do said testing.
19:21:14 <mitr> notting: "manpower to set up and maintain the rpm"
19:21:15 <sgallagh> mjg59: I don't. No disrespect to the people involved, but the changes is so broad in scope that I think it's impossible for it to be accomplished without at least a few mistakes.
19:21:24 <mjg59> drago01: That's saying "This won't happen unless rel-eng agree, so the people you need to convince are rel-eng"
19:21:28 <sgallagh> I'd rather see this land immediately post-branch
19:21:42 <mjg59> I just have no idea why we're involved at this point, unless we're being asked to help convince rel-eng
19:22:22 <haraldh> mjg59, I am asking you to help convince rel-eng :)
19:22:26 <mitr> mjg59: I suppose rel-eng doesn't have the mandate to revert all of the git commits, so it is asking FESCo
19:22:40 <mjg59> I'm against us deferring it, because that means that even if a solution is found that makes rel-eng happy then the feature gets deferred
19:23:00 <mjg59> mitr: We don't have the mandate to revert all of the git commits either
19:23:08 <t8m> mjg59, ugh?
19:23:09 <pjones> yeah, deferring it shouldn't really be on the table.  we agreed that it's a worthwhile feature.  a derail doesn't help anybody.
19:23:10 <jwb> all of the commits were done by the Feature owners, right?  if a defer is the resolution, they can rever what they committed
19:23:33 <mmaslano> mjg59: how so? if feature isn't done on time, then it's defered (with commits)
19:23:35 <mjg59> I guess we could say that they should be reverted, but if the package owners refuse then we still need to get provenpackagers to do it
19:23:54 <mjg59> mmaslano: Yes. Do you have any reason to believe that the feature owners won't do that if the feature doesn't reach 100%?
19:23:54 <sgallagh> pjones: We didn't necessarily "agree". As I recall, this was a 5-4 decision
19:23:57 <t8m> mjg59, there are some provenpackagers among us who can do that
19:24:03 <notting> so, how do we get the testing that rel-eng needs?
19:24:15 <mmaslano> mjg59: that's not the point
19:24:16 <pjones> sgallagh: now you're using semantics?  it won the vote.
19:24:19 <mjg59> mmaslano: It *is* the point.
19:24:19 <limburgher> t8m: <nods>
19:24:20 <nirik> notting: via rhel qa? ;) or is there some external way to test it?
19:24:35 <mjg59> mmaslano: It is absurd for us to say that the feature should be reverted when we haven't reached feature freeze yet
19:24:50 <mjg59> mmaslano: That's not how the process works
19:24:53 <mitr> mjg59: Not if the content of the feature has changed
19:24:56 <t8m> mjg59, sure for such feature it is
19:24:57 <dgilmore> step 1 would be to get a filesystem rpm built that has the extra rpmlib dep
19:25:03 <mmaslano> mjg59: it's absurd to push something what could broke clean update
19:25:07 <dgilmore> we cant test it propperly without that
19:25:09 <pjones> mitr: oh come on.  the content of *every* feature changes.
19:25:17 <mjg59> mmaslano: Nobody is talking about doing that
19:25:19 <mitr> dgilmore / abadger1999: Would hwaiting for f18 even solve the RHEL problem?
19:25:43 <nirik> dgilmore: isn't it in the side tag?
19:25:45 <sgallagh> mitr: If there are plans to land this RPM in RHEL 6.3, the beta at least should be ready before F18 freeze
19:25:46 <dgilmore> mitr: i believe it is scheduled to get into rhel 6 at some point in the future
19:25:54 <dgilmore> which is the prefered way to have the change land
19:26:06 <nirik> http://koji.fedoraproject.org/koji/buildinfo?buildID=295445
19:26:10 <mitr> dgilmore, sgallagh: and rel-eng would be fine with installing a beta?
19:26:15 <mjg59> dgilmore: We've had out of band rpm updates in the past, yes?
19:26:34 <mjg59> dgilmore: Did that end up being painful?
19:26:37 <pjones> dgilmore: preferred?  or "only acceptable"?
19:26:43 <dgilmore> mjg59: yes, it caused extra work. which is why we really dont want to do it again.
19:26:44 <sgallagh> mitr: I suspect they'd be more inclined to install something destined for official release
19:27:01 <mjg59> dgilmore: Ok. What kind of resources would be necessary to make that extra work tolerable?
19:27:39 <mjg59> dgilmore: If harald and/or kay committed to providing rpm builds for the relevant releases, would you be satisfied?
19:27:45 <dgilmore> mjg59: need to ensure we dont break anything and that the extra rpmlib works as expected.
19:27:57 <dgilmore> mjg59: just providing a rpm build is not enough
19:27:58 <mjg59> dgilmore: Testing would obviously be an important part of this
19:27:58 <notting> that seems to be a simple matter of testing.
19:28:18 <haraldh> dgilmore, I am willing to to fix everything which pops up, which works without the patch, and does not work with the patch
19:28:33 <pjones> so how much testing is enough?
19:28:35 <mjg59> dgilmore: The testing required for Fedora is going to be the same regardless of whether the update comes through RHEL or not
19:28:50 <mjg59> dgilmore: So presumably you're worried about unrelated breakage in rpm?
19:28:56 <dgilmore> we need to test rhel 4 5 6  and fedora 15 16 17 builds.  they need to mimic the way koji runs
19:29:01 <mitr> BTW, given that we branch in a week, it's clear that even if we defer, the change couldn't happen in rawhide immediately after branch - only later in the cycle.
19:29:01 <notting> mjg59: i think we need commitment that the update *will* come through RHEL at some point
19:29:02 <dgilmore> so all mock plugins disabled
19:29:04 <t8m> haraldh, will you also provide async updates on time if there are async erratas for rpm in RHEL-6?
19:29:13 <mjg59> haraldh: Is the update already in RHEL CVS?
19:29:24 <notting> mjg59: it's been ACKed.
19:29:32 <mjg59> notting: But not committed?
19:29:35 <haraldh> mjg59, it has all acks..
19:29:42 <t8m> mitr, you're right but a few weeks or even month or two would be much better than a week before feature freeze
19:30:05 <haraldh> mjg59, I didn't want to commit panus packages... but I can ask him to commit it to CVS
19:30:14 <mjg59> haraldh: Ok.
19:30:26 <mjg59> If it's committed to RHEL CVS then the only reason it wouldn't make RHEL is if it fails QA, right?
19:30:37 <mjg59> I mean, the only realistic reason
19:30:37 <dgilmore> mjg59: right
19:30:39 <haraldh> mjg59, although we did for F15,F16,F17 with Panu's permissions
19:30:52 <haraldh> mjg59, right
19:31:02 <mjg59> dgilmore: If it's committed to RHEL, what kind of QA are you looking for?
19:31:21 <haraldh> complete rebuild of all distributions?
19:31:49 <dgilmore> mjg59: i already explained. we need to make sure we can build rhel 4 5 and 6 and fedora 15 16 17. having all plugins in mock disabled.
19:31:52 <mitr> haraldh: Given that we fairly regularly have FTBFS problems...
19:32:09 <mjg59> dgilmore: Rebuild them just as well as is possible with the current rpm, I guess
19:32:09 <dgilmore> there is probably about 10-15 packages we should check for each os release
19:32:23 <mjg59> haraldh: Is that something you or Kay would be able to coordinate with releng?
19:32:31 <dgilmore> mjg59: to ensure that the feature works correctly as well as no regressions
19:32:48 <mjg59> dgilmore: I just mean that any package that fails with the current rpm would be allowed to fail with the new one, too
19:32:52 <haraldh> mjg59, err... if you look at the code path... well, this testing is absolutely useless..
19:33:06 <haraldh> but if you really want to do so... :-(
19:33:08 <dgilmore> mjg59: one of the first things needed is a rfilesystem rpm with the extra dep on the rpmlib so that it can actually be tested
19:33:12 <mjg59> haraldh: That's what we generally say about code changes, yes
19:33:18 <dgilmore> s/rfilesystem/filesystem/
19:33:39 <mjg59> haraldh: But somehow...
19:33:45 <mmaslano> it's half an hour. Do you want to discuss longer or propose something?
19:34:01 <mjg59> haraldh: I think that in terms of the timeline for F17, that's the only way you're going to satisfy releng
19:34:15 <mjg59> So:
19:34:50 <mjg59> #proposal releng and feature owners discuss coming up with an appropriate test plan. Proceed as originally planned assuming this can all be managed before feature freeze.
19:35:08 <mitr> mjg59: What happens to rawhide in the meantime?
19:35:10 <mjg59> (secondary architectures do not get to be blockers in this test plan)
19:35:12 <llaumgui> réu ?
19:35:34 <t8m> mjg59, that's something we do not have to vote on
19:35:37 <mitr> Does that mean all the usrmove commits get reverted now, and reapplied later, something else?
19:35:39 <mjg59> mitr: Right now we have the expectation that this will still land. If it becomes clear that it won't happen, rawhide should be reverted.
19:35:42 <sgallagh> llaumgui: FESCo meeting is running long, sorry.
19:35:47 <t8m> mjg59, it's like saying let's continue
19:35:56 <mitr> mjg59: And until then affected maintainers are not allowed to rebuild their packages?
19:36:16 * nirik is fine with that provided haraldh, kay and dgilmore can work out needed testing quickly. ;)
19:36:25 <notting> mitr: "not allowed to"? they can build non-moved versions and merge changes as they see fit
19:36:30 <notting> it's git, it's not stone tablets.
19:37:02 <t8m> AFAIK that means reverting in the master git branch
19:37:07 <haraldh> ofc, I am willing to help, I just don't know how...
19:37:29 <mitr> notting: It's just that the process is _extremely_ muddy because the changes re on master.  Suppose coreutils reverts the migration, commits a bugfix, or 5...
19:37:58 <nirik> before we merge the /usr side tag, feature owners will need to make sure there are no newer builds...
19:38:12 <eseyman> FTR, the french community meeting is in #fedora-meeting-2, starting now !
19:38:15 <nirik> then make sure the commit (re)lands and a new build is made if it was reverted.
19:38:24 <nirik> eseyman: sorry for running long.
19:38:31 <notting> that's all doable, though
19:38:35 <notting> +1 to mjg59's proposal
19:38:47 <eseyman> nirik, no sweat
19:38:47 <mitr> notting: Sure, but needs to be announced widely.
19:38:52 <notting> although since that is essentially status quo, not sure it requires voting
19:39:01 <sgallagh> I'm ok with mjg59's proposal as well. +1
19:39:11 * nirik still waiting to hear if dgilmore / haraldh and kay are ok with it. ;)
19:39:24 <haraldh> nirik, I am ok, and kay is also
19:39:39 <haraldh> nirik, but I am not sure, how we can help
19:39:55 <haraldh> nirik, but I am not sure, how we can help testing...
19:40:04 <mmaslano> the testing plan could be provided by QA, who has experience
19:40:35 <nirik> well, dgilmore would need to get you what testing needs to be done: a) build filesystem, b) rebuild the following list of packages in mock with no plugins on a rhel6 machine with the new rpm c) repeat by release for all needed releases. d) ?
19:40:45 <kay> we had a qa meeting today, they run tests on install images already
19:41:08 <kay> the other test they did seemed to work fine so far
19:41:24 <haraldh> I think we only have to check:
19:41:28 <haraldh> # rpm --showrc  | grep rpmlib
19:41:29 <mitr> kay: That's entirely different from what dgilmore wants, though
19:41:31 <haraldh> output
19:41:31 <nirik> but the point of this is to test the rhel6 rpm.
19:41:37 <haraldh> before and after the patch
19:41:57 <nirik> no, you need to check for regressions. ;)
19:42:00 <haraldh> for F15,  F15, RHEL-6 it should be the same before and after
19:42:01 <kay> haraldh: there will be zero difference :)
19:42:21 <notting> the point is not "should" it regress, but "does" it regress
19:42:22 <haraldh> for F17 on a converted filesystem it should differ...
19:42:50 <nirik> right.
19:42:57 <haraldh> nirik, ok, how much do you test for "regression" ?
19:43:03 <haraldh> building the world?
19:43:11 <nirik> how about I write up a list/plan and dgilmore acks/edits it and we get it to you guys?
19:43:21 <haraldh> nirik, very cool!
19:43:27 <notting> i thought i did that
19:43:42 <nirik> notting: oh?
19:44:12 <mitr> haraldh: I suppose the testing is "6.3 rpm vs. 6.1 rpm", not "6.1 rpm + patch vs. 6.1 rpm"
19:44:29 <notting> haraldh: kay: can i just bounce the mails from friday, etc. over to nirik?
19:44:29 <mitr> Not that I would know, though - that's for rel-eng.
19:44:31 <kay> we are all aware,t hat we talk about this, right? http://pkgs.fedoraproject.org/gitweb/?p=rpm.git;a=blob;f=rpm-4.9.1.2-rpmlib-filesystem-check.patch;hb=HEAD
19:44:42 <mitr> kay: ^^^
19:44:48 <nirik> kay: no, thats not what we are talking about.
19:44:57 <mmaslano> kay: no, we are not. As I said I din't see were was this change discussed
19:45:03 <kay> i mean what we wouold test in non F17 packages
19:45:04 <haraldh> notting, sure
19:45:06 <nirik> we are talking about the RHEL6 rpm
19:45:09 <dgilmore> notting: we need more than what was in your email, a big one being that we need a filesystem rpm that has the new rpmlib dep
19:45:19 <dgilmore> so that we can test that it actually works
19:45:30 <kay> this code is just dead text on older distros
19:45:31 <notting> dgilmore: that's simple, though
19:45:38 <haraldh> kay, wrong.. we are talking about: https://bugzilla.redhat.com/attachment.cgi?id=541981&action=diff
19:45:57 * nirik doesn't know that this now needs to be in this meeting. How about we move on here, and ask everyone involved to test and hopefully issues will be fixed.
19:46:02 <kay> haraldh: which is the same code
19:46:06 <haraldh> kay, :)
19:46:20 <haraldh> nirik, mmaslano : same patch :)
19:46:27 <pjones> that patch adds unchecked returns.
19:46:52 <notting> can we move on?
19:47:09 <mjg59> I think we've got a path forward
19:47:26 <pjones> yes, move on.
19:47:53 * mitr would still like to know what are the maintainers of the ~200? affected packages supposed to do in git in the mean time
19:48:06 <haraldh> dgilmore, so, you need prove, that our filesystem guard works? fine, we will do that :)
19:48:19 <haraldh> mitr, not 200... 31
19:48:19 <t8m> mitr, that's another topic, but highly interesting one
19:48:22 <mmaslano> pjones: to what? I don't see any decision
19:48:52 <mitr> haraldh: The feature page still says ~260...
19:48:53 <nirik> mitr: if they need to build, revert the usrmove and build.
19:49:09 <nirik> and when/if the usrmove lands, new commit/build will re-add it
19:49:18 <nirik> at least IMHO thats the only sane way forward.
19:49:22 <haraldh> mitr, only 31 are critical and have been built in the usrmove tag
19:49:41 <haraldh> see
19:49:41 <haraldh> <haraldh> mitr, only 31 are critical and have been built
19:49:42 <dgilmore> haraldh: that it works, and that we dont experience any regressions
19:49:45 <haraldh> https://fedoraproject.org/wiki/Features/UsrMove#Buildsystem_Transition
19:50:02 <haraldh> dgilmore, no problem.. I am confident with that :)
19:51:20 <dgilmore> haraldh: your buildsystem transition section has 2 major flaws. we disable all mock caching plugins in koji.
19:51:38 <notting> mmaslano: no proposals passed -> status quo -> move on?
19:51:43 <haraldh> dgilmore, that's void then
19:52:00 <haraldh> dgilmore, ignore the comments with the "cache" then
19:52:02 <mmaslano> notting: probably we won't agree on anything else
19:52:21 * dgilmore would like to propose that for any future feature that may have buildsystem changes as requirements please consult releng
19:52:49 <mmaslano> dgilmore: I'll add it
19:52:50 <dgilmore> we could have avoided all this mess by having releng consulted
19:52:51 * nirik didn't realize this one did until pretty recently. ;(
19:52:55 <mmaslano> #topic Next week's chair
19:53:03 <mjg59> I can do it
19:53:16 <mmaslano> #action mjg59 will be chair next week
19:53:21 <mjg59> Whee
19:53:26 <mmaslano> #topic Open Floor
19:53:57 <mmaslano> I'll close it in few minutes
19:56:35 <mmaslano> #endmeeting