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