18:00:48 #startmeeting FESCO (2013-07-17) 18:00:48 Meeting started Wed Jul 17 18:00:48 2013 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:50 #meetingname fesco 18:00:50 The meeting name has been set to 'fesco' 18:00:52 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:00:52 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:00:54 #topic init process 18:01:01 Hi all 18:01:04 * abadger1999 here 18:01:07 morning everyone. 18:01:23 Greetings from sunny Microsoft Building 20 18:01:35 (this is a first, right?) 18:01:39 pjones: :) 18:01:46 * masta looks in 18:01:52 sunny? 18:01:52 hello! 18:01:57 notting: bizarrely, yes 18:02:10 lots of sparc hardware there? ;) 18:02:35 so what should I buy you guys at the Microsoft Company Store this afternoon? 18:03:27 *crickets* 18:03:28 pjones: buy the whole ms :) 18:03:32 (Oh actually I guess I did this from MS last year too.) 18:03:37 pjones: ... the seahawks? or the sounders. 18:03:43 you can buy me a surface tablet. but even microsoft probably doesn't want them. 18:03:59 eh? you have to pay money for them now? 18:04:04 kylem: I have only gotten "hey, that's not a surface..." while using my nexus 7 once. 18:04:11 they were giving them away free simply to have people using them 18:04:18 Apologies to mattdm 18:04:21 /nsa here 18:04:26 i mean /me here 18:04:26 #action mitr Update FESCo meeting process page for election results 18:04:49 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:04:49 Current chairs: abadger1999 jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:05:35 fossjon: your secret is out 18:05:43 sgallagh and mmaslano said they wouldn't be available, so that's everybody 18:05:53 #topic #1132 libtool + %global _hardened_build 1 = no full hardening 18:05:55 .fesco 1132 18:05:57 https://fedorahosted.org/fesco/ticket/1132 18:05:58 mitr: #1132 (libtool + %global _hardened_build 1 = no full hardening) – FESCo - https://fedorahosted.org/fesco/ticket/1132 18:06:59 We have a comment from ajax: https://bugzilla.redhat.com/show_bug.cgi?id=978949#c8 18:08:08 So, it looks like the decision is between this "kludge it on the fly" approach vs. "patch system libtool & force relibtoolize"? 18:08:26 * nirik wonders who is lucky enough to maintain libtool. 18:09:01 Not so much of the second I think, the recentish libtool macros are calling /usr/bin/libtool IIRC 18:10:35 mitr so, "just patch system libtool" should cover it? What am I missing here? 18:10:39 I'd vote for the second option 18:11:04 I'd slightly prefer the second option as well, however I'm not sure this needs us micromanaging. 18:11:05 mattdm, perhaps not for everything that should be hardened and that we ship, but libtoolize call should fix it 18:11:21 What is the outcome we are looking for here? Let's try: 18:11:43 proposal: Add the #978949 bug to the F20 blockers list and ask the redhat-rpm-config + libtool maintainers to solve it 18:11:46 mitr: we do need a decision to be made so that hte mass rebuild can proceed. Other than that I can agree with you. 18:12:08 (that's admittedly one extreme of the spectrum, kind of hoping for counterproposals) 18:12:15 right, mass rebuild is likely very soon... 18:12:19 mitr: We decision sooner than F20 blockers would typically be processed b/c of the rebuild dependency. 18:12:27 *we need the decision 18:12:38 decision and implementation. 18:13:06 abadger1999: good point. Though this only affects shared libraries. 18:13:07 proposal: apply kludge to redhat-rpm-config now, ask libtool maintainer to come up with a more sustainable/better fix in libtool and drop kludge when no longer needed? 18:13:34 mitr: yes, but we very strongly encourage a use of shared libraries through our policies, so that doesn't limit very much ;) 18:13:57 nirik: i'm fine with that 18:14:07 nirik: wfm +1 18:14:08 nirik: I'm +1 there 18:14:22 nirik: also +1 18:14:36 nirik: I don't "like" that, but this has been dragging for long enough that +1 gives us best chance to get the right fix.. So +1 18:14:52 yeah, it's not ideal, but we have to do mass rebuild soon... so... 18:15:49 #agreed apply kludge to redhat-rpm-config now, ask libtool maintainer to come up with a more sustainable/better fix in libtool and drop kludge when no longer needed (+5) 18:16:02 Now for new items... I'd like to discuss ARM at the end, to make sure everything else gets done. Any objections? 18:16:09 fine with me 18:16:50 #topic #1135 F20 System Wide Change: Fedora 20 Boost 1.54 Uplift - 18:16:52 https://fedoraproject.org/wiki/Changes/F20Boost154 18:16:54 .fesco 1135 18:16:56 https://fedorahosted.org/fesco/ticket/1135 18:17:01 +1 18:17:03 +1 18:17:11 +1 18:17:16 biennial-+1 18:17:39 mmaslano was +1 in the ticket 18:17:46 +1 18:17:48 mitr: #1135 (F20 System Wide Change: Fedora 20 Boost 1.54 Uplift - https://fedoraproject.org/wiki/Changes/F20Boost154) – FESCo - https://fedorahosted.org/fesco/ticket/1135 18:18:45 +1 18:19:12 #agreed F20 System Wide Change: Fedora 20 Boost 1.54 Uplift was accepted (+6) 18:19:32 #topic #1137 F20 Self Contained Changes 18:19:34 .fesco 1137 18:19:36 https://fedorahosted.org/fesco/ticket/1137 18:19:38 See the ticket for a full list of features. 18:19:40 Would anyone like to discuss any of the features individually? 18:19:57 * nirik notes something is going on with hosted, looking now. 18:20:13 timing! 18:20:29 abadger1999: You had questions about shared certificates, Stef has just answered on devel@ 18:20:38 mitr: cool. 18:20:40 * abadger1999 looks at ml 18:21:00 the ones in the agenda e-mail all are ok with me 18:21:26 I'm OK with all the self contained changes in this ticket 18:21:31 Since the ticket may not be accessible: 18:21:34 - Hadoop - https://fedoraproject.org/wiki/Changes/Hadoop 18:21:36 - Shared Certificate Tools - 18:21:38 https://fedoraproject.org/wiki/Changes/SharedCertificateTools 18:21:40 - SDDM as the default KDE DM - 18:21:42 https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM 18:21:44 - KDE Plasma Workspaces 4.11 - https://fedoraproject.org/wiki/Changes/KDE411 18:21:46 - Yesod Web Framework - https://fedoraproject.org/wiki/Changes/YesodWebFramework 18:21:48 - ARM on x86 with libvirt/virt-manager - 18:21:50 https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001181.html 18:21:52 - VM Snapshot UI with virt-manager - 18:21:54 https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots 18:21:56 I'm also OK with all of them 18:21:57 * nirik is fine with all of them. 18:22:08 I'm okay with all of those 18:22:22 me too 18:22:26 mitr: Cool. I think that's an answer to my question. It sounds like: admins already know to only modify the master copy and sync from there. This tool just makes it easier for them to do that. 18:22:38 +1 to all 18:23:10 #agreed Self-contained changes from ticket #1137 are accepted (+7) 18:23:25 #topic #1136 F20 System Wide Change: ARM as primary Architecture - 18:23:27 https://fedoraproject.org/wiki/Changes/ARM_as_Primary 18:23:29 .fesco 1136 18:23:31 https://fedorahosted.org/fesco/ticket/1136 18:24:05 * dgilmore is here 18:24:18 hi dennis 18:24:20 * bconoboy is here too 18:25:02 hi guys 18:25:21 How do we stand against https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements ? 18:25:21 you have questions, we have answers :-) where to begin? 18:25:41 so, I think we're still on path to do this, but last time this came up we basically said we wanted one release where ARM /acted/ like a primary, infrastructurewise, before we declared it such 18:25:42 1. yes 18:25:49 2. yes 18:25:56 3. yes 18:26:00 4. yes 18:26:16 I still think that's the route forward - make it more and more like primary, and the act of calling it primary should really just be what we call it when we're there. 18:26:32 ... 18:26:49 what about the issues raised on the list? (stack-protector, libGL ..) 18:26:52 yes, ellipses for sure. 18:26:54 pjones: We're not really after a name, we're after technical adjustments 18:27:08 stack protector is being worked on 18:27:08 EG, merged build system 18:27:09 bconoboy: by all means, proceed with technical adjustments :) 18:27:13 well, f19 was that release I thought? arm secondary released at the same time, etc. 18:27:16 pjones, there is the switch between blocking koji builds or not - and that is not just "what we call it" 18:27:18 we belived it was implemented 18:27:27 nirik, +1 18:28:00 nirik: indeed 18:28:04 t8m: no, that's a thing we need to make happen and make sure works correctly before we grant it the status. 18:28:08 the llvm and stack protector bugs must be fixed, but they can be added to the f20 blocker. 18:28:36 yeah, I'm not honestly all that worried about individual bugs. They need to be fixed, but they'll get fixed as they're raised. 18:28:43 * nirik nods. 18:28:48 nirik: FWIW I'm not _that_ concerned about OpenGL. 18:29:01 i mean, looking at that list, the one's that seem the sketchiest were #6 and #11. #10 i don't know about, and #8 would need querying 18:29:07 well, it's a think people expect from a primary arch 18:29:14 Though notting's argument that the ARM release should match the ARM community's products is very compelling. 18:29:17 mitr: i do believe its something that will be fixed 18:29:22 There is a mesa build underway right now that largely resolves the opengl issue. 18:29:38 notting: note: #8 is contrary to the packaging guidelines. 18:29:45 bconoboy: largely means what? working llvmpipe? 18:29:53 drago01: yes 18:29:56 closer to working. 18:29:57 mitr: if you're shipping desktop images, even if the desktop doesn't use libGL directly, i think it's expected that libGL doesn't explode for any app that might want to use it 18:30:01 it renders... something. 18:30:08 kylem has been making good progress there. 18:30:11 6 - I'm working on access for packagers to some socs... perhaps also we could look at another pool of hw too 18:30:45 10 - websites worked with arm folks for making the secondary arm page/info in f19. There's good communication there I think. 18:30:53 nirik: i believe that the change for working libvirt for arm on x86 will help also 18:31:07 http://stg.fedoraproject.org/en/get-fedora-options#2nd_arches 18:31:11 abadger1999: the guideline allows excludearch for 'does not work' with no provision for 'making it work'? 18:31:16 oops. not stg, there. 18:31:28 notting: no provision beyond filing a bug I believe 18:31:36 nirik: "stack protector bugs must be fixed, but they can be added to the f20 blocker" don't we need a mass rebuild to apply the fix or did I get that wrong? 18:31:48 nirik: #10 i'd be concerned about docs too - relnotes, etc. 18:32:05 drago01: unclear to me. I don't know what the fix is... or what all is broken. Could be a mass rebuild is needed, not sure. 18:32:19 nirik, drago01: But worth tracking I think. 18:32:22 notting: Correct: https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Architecture_Support 18:32:25 drago01: That's a good question. It has been asserted (but not confirmed) that gcc's stack protection may be covering the lack of support in glibc- we're looking into it 18:32:41 abadger1999: although given https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-arm i'm not sure how well we're following it 18:32:42 notting: It's MUST build on one primary arch. 18:32:52 And also, must be able to track the problems. 18:33:11 so that hte arch teams can go through and fix problems specific to their arch. 18:33:16 what happens with arch specific pkgs, like x86 only ones 18:33:20 abadger1999: that's kind of a terrible requirement :/ 18:33:32 Are the opengl and stack protector issues the only things that fesco wants to discuss with regard to this proposal? 18:33:35 bconoboy: ok, my concern is just that if it gets in late (the fix) we would need a mass rebuild which will take a long time causing a slip 18:33:39 abadger1999: in general, non-arch-specific things should work on /all/ primary arches. otherwise what's the point of them being primary? 18:33:42 bconoboy: would be nice to avoid that 18:33:56 * nirik notes much of this is probibly historical. 18:34:02 bconoboy: There's timing also. Per https://fedorahosted.org/rel-eng/ticket/5655 we are looking at starting the mass rebuild _in 3 days_. Is that feasible? 18:34:04 drago01: agree. conversely, we have enough build hardware that a mass rebuild on arm is probably faster than x86 18:34:09 (Is that mass rebuild date feasible even for x86*?) 18:34:15 pjones: +1 18:34:27 pjones: depends..... It's a terrible requirement when thinking about gcc, for instance... but it's not so horrible if the package you are considering is some random, seldom used game, for instance. 18:34:28 mitr: I don't believe the mass rebuild needs to be done with arm as primary 18:34:30 bconoboy: but if it is a primary arch we can't just rebuild one arch iirc 18:34:33 dgilmore: ^^? 18:34:41 mitr: f20 schedule might nt really be feasible 18:35:03 pjones: The point of them being primary was that they share the same resources like the build system. 18:35:04 but adding arm and doing mass rebuild with it is feasable 18:35:20 abadger1999: and updates system, and package signing, and release images, and qa and docs and.... 18:35:22 abadger1999: I did say "should", but primary vs secondary should reflect user expectations as well 18:35:29 nirik: yep. 18:36:28 so, the disabling of a primary is pretty easy. what is the specific process of enabling a primary? just import from secondary, or...? 18:36:45 notting: one of two ways 18:36:56 notting: import matching builds from secondary 18:37:09 or setup external repo and do mass rebuild 18:37:29 importing thematching builds is likely best 18:37:48 we then update mash configs and releng scripts 18:37:56 dgilmore: that implies arm is doing the mass rebuild one way or another 18:38:09 notting: right 18:38:43 I think I have to go grab lunch right this minute or risk not getting any at all. brb. 18:38:56 i would prefer to enable arm prior to mass rebuild, but its not required 18:39:10 pjones: to some extent... I think I'm in closest agreement with notting that there is some base level of the OS that there should be a requirement that it works everywhere. But we should define that better than it is now. 18:39:43 could we define that as base critpath? or @standard ? 18:39:59 must all build and generally function the same on all primary arches? 18:40:13 I think now, we're debating opengl but not stack-protesctor b/c people are all willing to put stack-protector in their particular "base level" but not everyone considers opengl in that bucket. 18:40:45 I didn't recall seeing anyone saying opengl wasn't something to fix? 18:40:56 or do you mean, if we ran into this before release would it be a blocker? 18:41:47 Well... it might have been hypothetical but bconoboy, were you positing that opengl shouldn't be a blocker to acceptance? 18:41:48 nirik: We also have a third option "not release blocking but resulting in ARM not being a primary architecture for F20" 18:41:54 Though that's pretty harsh on the ARM team. 18:42:10 mitr: that's a bit weird in that you then... unbundle the primary builds? 18:42:16 well, promoting then demoting has costs. 18:42:29 (if thats what you are suggesting) 18:43:04 yeah, that seems impractical. i think slipping is the answer then 18:43:08 notting: kind of weird but feasible I think. (One advantage of this is that we would have "real-world experience" on the increased bug load / build time impact on all maintainers, without irrevocably committing.) 18:43:22 * nirik is with notting on that 18:43:26 abadger1999: It's not really for me to say which category that goes into- the base question is the same: PA means things have to be fixed or the release is blocked. I'm interested in the "how" that goes with ARM promotion for resolving stack protector, or whatever issue comes up a week or a month from now 18:43:29 mitr: its always an option 18:43:51 If consensus is opengl must be fixed, we'll work with that 18:44:01 abadger1999: yeah, I certainly won't maintain "every non arch package has to work" as the criteria - that's much too high a barrier. but I want to be clear to package maintainers that not working for BS reasons isn't really okay either ;) 18:44:04 we're going to fix it regardless, people are showing up who want it 18:44:12 pjones: +1 18:44:16 right. 18:44:44 * jreznik is not happy with blocking/slipping current PA 18:44:50 pjones: +1. llvmpipe is kind of special because even on x86 the maintainership is limited. 18:44:57 abadger1999: repoquery --whatrequires mesa-libGL | wc -l 18:44:57 671 18:45:05 not even counting stuff that just dlopen it 18:45:25 jreznik: sorry, parse error on that 18:45:52 anyhow, I guess I'm personally +1 to the promotion. I am sure there will be tons of things we need to update or consider, but I think it's good for Fedora to support the growing arm world. 18:45:59 jreznik, blockng should only be necessary if the plan is to release a release blocking spin on arm ( like gnome ) if plan is not do ( only to release minimal or KDE ) that well then it's not a blocker I would think 18:46:19 notting: better - I'd like to avoid blocking current PA on ARM stuff, if it would be possible to demote, I'd be more this way 18:46:33 Viking-Ice: yep 18:46:34 Viking-Ice: and i find the idea of "arm is now primary. oh, btw, we now release only 1/4 of the things we did before" to be silly 18:47:01 which would be the result of 'only release minimal or kde' 18:47:01 jreznik: its possible if after beta we think its not working to seperate arm and make it secondary again 18:47:02 mitr: fair. but again - kylem is making good progress on that 18:47:02 notting: yeah primary should be "same but other arch" 18:47:04 well, boot/netinstall is blocker on x86. 18:47:27 dgilmore: possible, but it's not a switch that can be easily flipped 18:47:41 notting: its actually not that hard 18:48:00 dgilmore: import back into secondary? 18:48:05 i mean, i can give you working opengl 5 minutes from now if nobody notices i switch from llvmpipe back to swrast... 18:48:06 notting: yep 18:48:16 notting, sorry not following 18:48:17 so, what deliverables would be blocking then? 18:48:28 kylem: You know, that would actually work for me personally :) 18:48:37 kylem: we will notice by having stuff not working 18:48:40 notting: import latest mash into koji and update mash configs etc, and koji arches 18:49:17 kylem: (I'd even say working opengl means real drivers but that's a bit too much for now) 18:49:30 Viking-Ice: as secondary, ARM already released 5 desktops, minimal, install tree, etc. retargeting it to be a headless release on promotion to primary seems backwards. 18:50:42 notting: headless is not being proposed 18:51:00 or maybe that's better directed at viking-ice 18:51:17 so, minimal / gnome /kde images are blocking, the rest are best effort? 18:51:38 do we have to decide release criteria as part of this discussion? 18:52:06 well, you need to meet the existing critera or propose changes to it? 18:52:06 nirik: blocking or reason to demote to SA? 18:52:24 notting, it should be entirely up to the relevant sub-community which architecture they release on so for example if the Gnome community wants to release on arm they do so and to the necessary work to achieve that with any help they can from the arm sig but making any thing other but build requirement on architectures for PA is what's silly 18:52:33 bconoboy: you said "[if opengl was only objection] I would say let's drop graphics from official Fedora ARM support for the purposes of the move and make all graphical images respins or remixes.". not sure how else to take it. 18:52:54 jreznik: I don't think we should talk demotion until there's some horrible concrete thing. 18:52:56 notting: I also said it was a thought exercise to understand the parameters of people's thinking. It is not being proposed. 18:52:59 Viking-Ice: +1 18:53:02 In either case I think we should have a rough but sufficient consensus of the criteria now to avoid surprises by RC1 - but a consensus on who decides the criteria would be enough for me 18:53:33 Viking-Ice: That's not how things work right now I think. 18:53:50 mitr: why should they be different? we don't have different criteria x86 vs x86_64 (neither vs ppc back then) 18:53:54 okay what did i miss? 18:54:25 dgilmore: http://www.fpaste.org/26002/74087259/ 18:54:30 dgilmore: http://www.fpaste.org/26003/40872651/ 18:54:37 Question -- if we made arm primary now but didn't want to block release if certain features weren't finished in time for release -- could we and would we want to leave it as a primary arch for koji and bodhi purposes but not make it a supported platform for the general public? ie -- don't build spins for it and don't announce it as part of the f20 release? 18:54:40 drago01: "They shouldn't" is a quite valid answer. bconoboy asked whether they have to be nailed down now. 18:55:14 * odonell waves 18:55:15 notting, how the lego bricks ( components ) get's puzzled together to make a release is irrelevant to the architect sig their first and foremost concern should be that those lego brick are available and can be pieced together for the sub-community to use right 18:55:22 abadger1999: well, thats a disservice to arm folks... then they would have 0 f20 release? 18:55:44 Viking-Ice: a linux distribution is more then a collection of packages 18:55:55 I guess that's a subquestion -- could they make the arm spins like they do now, just with packages from the primary koji/repos? 18:56:04 drago01, and ? 18:56:12 abadger1999: we could 18:56:33 abadger1999: we could only mash x86 as primary 18:56:43 and mash arm seperately 18:56:51 though that would be more work for me 18:56:56 that would lead to tree skew 18:57:18 it wouldnt be good 18:57:23 but could be done 18:57:30 Viking-Ice: that means we are not building "lego bricks" but a product 18:57:32 k 18:57:55 * mitr formally notes that the discussion has been going on for > 30 minutes. Continue? 18:58:19 drago01, the sub-communities are building an product which they have pieced together from the bits we ship 18:58:23 proposal: promote arm now, ask everyone to review critera and propose any changes based on this promotion. 18:58:26 mitr: are people willing to vote? 18:58:52 dgilmore: (typically these clock alarms have been ignored ...) 18:59:07 mitr: okay. 18:59:13 nirik, dgilmore: I'm still really unclear about what this means for the F20 schedule. 18:59:25 for what its worth i like nirik's proposal 18:59:25 nothing? 18:59:35 mitr: nothing 18:59:38 nirik, +1 18:59:49 nirik: +1 18:59:50 nirik: +1 19:00:03 dgilmore: You've said that F20 is infeasible anyway, but that ARM can be done if I'm not mistaken 19:00:20 Viking-Ice: well, that's not exactly how ARM (or even primary) works now. unless the various desktops are spending more efforts building and testing ARM than they are x86. *shrug* 19:00:35 mitr: the f20 schedule is extremely crammed. 19:01:00 mitr: normally we would have an extra 3 or 4 weeks for the planned mass rebuild 19:01:04 dgilmore, it is no-earlier-than schedule 19:01:15 yeah, so the question is - do we have to replan now? 19:01:38 (or once ARM is approved) 19:01:45 dgilmore: does ARM make it more crammed, or just 'another thing that would benefit from more time' 19:01:52 the perl guys wanted 4 weeks for their version bump. i could give them one week 19:02:12 notting: it doesnt make it more crammed 19:03:20 So now, per https://fedorahosted.org/rel-eng/ticket/5655 , we are looking at Jul 20 start of mass rebuild, Jul 27 end of mass rebuild (with Perl unknown), "no earlier than " Aug 8 change freeze + branch. 19:03:24 At which point would ARM "join"? 19:03:51 mitr: id like to do it before mass rebuild 19:04:23 though the mass rebuild could happen as secondary and it can be folded in after 19:04:40 i think the sooner the better 19:05:50 OK, I'm +1 19:06:23 I'm not convinced this is the /best/ path, but I think it's probably one that will work (assuming the various speed questions and whatnot are actually surmountable ;) 19:06:37 (with the release criteria subject to nirik's process, and my expectaton that _some_ libGL will exist, even if swrast, and that ARM release criteria will not substantially differ from other architectures) 19:07:18 We are at +4-0 unless I'm mistaken 19:07:39 Any more votes? 19:07:46 pjones? 19:07:53 eh, I'm still on the fence. 19:08:07 (sorry I'm late) what's the current topic? 19:08:09 mattdm, notting? 19:08:10 +3 explicit; +4 if nirik is voting for his own proposal 19:08:49 I think we should make promote it in action before we promote it officially; promoting it officially sets a lot of expectations, and we should set everything up to the point where we think we can fulfill those before we tell everybody it's a done thing. 19:09:09 +1 on a condition would be reasonable 19:09:13 pjones: i can live with that 19:09:31 pjones: I can live with that but I would like to see those criteria well defined 19:09:42 'promote arm now' is obvs. not that simple. dgilmore: are you signing up for *all* of the script munging to enable rawhide, branched, etc.? do we have a releng0x for composes? 19:10:06 notting: yes i am signing up for that 19:10:08 I think it will be very hard to explicitly list everything, we are going to have to learn as we go. 19:10:17 pbrobinson: they're the same criteria we've mentioned before - kernel and large package builds can't be delayed for large amounts of time as a result, etc. 19:10:19 notting: i have 4 arm releng boxes 19:10:33 pbrobinson: to be frank, we've been *very* explicit about these things over and over. 19:10:48 pjones: that's fine as long as we don't move the goal posts :-) 19:11:18 so yeah, the list may not be comprehensive - I don't think it ever will be. But the point I'm making is that arm being officially primary should be a routine assumption of the current state before we make it so. 19:12:09 pjones: OTOH that won't happen by itself without FESCo or somebody similar making clear that this is a routine assumption from now on. 19:12:16 I like pjones' "promote in action" 19:12:46 that helps us get there without raising expectations wrongly 19:13:38 revote? 19:14:33 how does promote in action differ from promote? 19:14:36 just not announce it? 19:15:03 pjones: does "promote it in action" mean we enable arm builds on koji and wait till we hit some milestone where we can decide to say its done and move forward, or revert back? 19:15:22 dgilmore: yes 19:15:32 pjones: just wanted to be clear 19:15:44 dgilmore: pjones: presumably create images and test and various other release related things as well 19:15:52 nirik: effectively - don't change wikis to call it primary until we're sure making it primary /has/ worked. 19:15:55 pbrobinson: yes 19:16:00 nirik Maybe a different way to say is "promote in infrastructure / releng" 19:16:09 pjones: hm. so weighing the cost of deciding late that it's primary vs the cost of having to do a revert *from* primary when it's announced earlier 19:16:30 notting: the political cost of the latter is huge. 19:16:37 pjones: i agree 19:16:51 I agree with that very much 19:16:52 pjones: We are an open project, we can't really hide the fact that it is now being treated "as if" primary. 19:17:05 mitr: no, and I'm not suggesting we even try to "hide" anything 19:17:05 mitr: it's on the road to primary 19:17:07 that's fine 19:17:14 yeah, in fact, hiding it would be wrong 19:17:18 and this is the next step 19:17:28 so 19:17:35 pbrobinson: That's a nice way to solve it. 19:17:47 pjones: so your proposal would be "build ARM on primary infrastructure. whether it is released as a primary Fedora 19 or as 'Fedora 19 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time"? 19:18:02 notting: +1 19:18:10 +1 19:18:14 notting: but you mean F20 ;) 19:18:19 erm, yes. 19:18:29 but was mainly trying to figure out what you were proposing 19:18:35 :-D 19:18:35 notting: ive made that same mistake this week 19:18:35 * abadger1999 watches notting roll the delorean back into the garage 19:19:10 notting: With said criteria being same as primary / different / will be solved $sometime later (when)? 19:19:13 so, when would we decide to call it primary fully? 19:19:22 * nirik is worried we would leave it in limbo 19:19:55 mitr: i believe that release criteria will only need minimal changes 19:20:00 Perhaps we could decide to have the criteria nailed down by Alpha release? 19:20:06 nirik: well, I would assume blc and jcm and pbrobinson eventually do have to tell their management that it's done, so they're going to come back and keep asking us ;) 19:20:16 I suspect there's not a huge risk of us forgetting. 19:20:23 pjones: i'm ok with the proposal. (sorry, drive-by) 19:20:27 you can count on me ;-) 19:21:01 well, I'm ok I guess, but I would rather it be announced sooner than later... 19:21:11 Is leaving it in limbo a bad thing compared to the status quo? does it increase work or prevent spins from being made or anything? 19:21:21 pjones: my $dayjob doesn't even cover ARM, I'm still doing it on my own time so my management can stick it in their pipe and smoke it ;-) 19:21:22 can we say its safe to go with pjones's proposal? 19:21:34 pbrobinson: well, okay, but bconoboy's does. 19:21:43 so I guess we should vote on that 19:22:06 pjones: yep! 19:22:48 pjones: On notting's proposal I see pjones +1, mattdm +1 19:22:53 notting: for clarity, are you +1 as well? 19:22:57 * mitr is +1 19:23:09 +1 19:23:16 +1 19:24:27 6 * +1 assuming notting was a +1 as it seemed 19:24:46 #agreed "build ARM on primary infrastructure. whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time" (+5) 19:24:59 (will add notting's vote to the minutes if notting agrees later) 19:25:08 thanks all 19:25:08 #topic Next week's chair 19:25:10 #info Marcela has volunteered to be the next week's chair 19:25:15 #topic Open Floor 19:25:20 Anything for open floor? 19:25:23 so, mass rebuild? 19:25:31 should we fire it off on the 20th? or ? 19:25:43 #topic Mass rebuild - https://fedorahosted.org/rel-eng/ticket/5655 19:26:07 Per the ticket, we are waiting on https://fedorahosted.org/fesco/ticket/1132 (libtool vs. hardened build), on which we made a decision today. 19:26:42 Well, we're waiting on the /action/ there, right? not just the decision 19:26:43 mitr: do you want to give perl some time to get done first? 19:26:48 pjones: yes 19:27:07 looking on changes proposed, I'm not see anything else to be approved that needs mass rebuild (except already approved Perl) 19:27:42 jreznik: boost will need a side tag. or to be done outside of the mass rebuild 19:27:46 Does Perl actually have an ordering dependency in any direction on the mass rebuild, or is it just that the two would interfere? 19:28:09 mitr: the two will interfere 19:28:42 ... and the perl rebuilds have actually already started. 19:28:44 dgilmore: I did not mention it based on your comment in the ticket 19:29:16 mitr: they have started already 19:29:56 how much time before branching f20 mass rebuilds has to be done? 19:30:35 jreznik: we could branch right after 19:30:57 it will mean that all clean ups need a rawhide and f20 build 19:31:15 which is why we usually leave two weeks 19:31:27 a week for mass rebuild 19:31:39 dgilmore: ok, I count it together, I got it now 19:31:54 mass rebuild + cleanup as one period 19:32:03 2 weeks to clean up failures 19:32:13 * jreznik understands now 19:32:13 I'd have said "start the mass rebuild as soon as the first attempt to rebuild all of perl finishes" (to share the cleanup time for perl and mass rebuild) but perl being built in dependency order breaks that, doesn't it? 19:32:14 then branch 19:32:28 mitr: yes 19:32:58 mitr: as soon as we can merge perl back in we should start 19:33:08 to avoid stepping on toes 19:33:14 So, options? 1) wait/not wait on perl, 2) wait/not wait on hardened build fixed in libtool? 19:33:27 where would be the point to move the schedule then? 19:33:30 Well, it sounds like we have to wait for perl 19:33:41 since they interfere and it's already started 19:34:01 seems like 19:34:11 we can see what we can do to speed up perl 19:34:21 2) I'd wait... that's why we passed "make changes to redhat-rpm-config for now", right? 19:34:28 abadger1999: +1 19:34:48 abadger1999: I'm thinking about the redhat-rpm-config change 19:35:03 * jreznik will try to talk to ppisar tomorrow 19:35:07 pjones: Technically we could just start the mass rebuild and let the Perl SIG deal with the conflicts. That's fairly horrible, but if we were strongly attached to the original schedule proposal... 19:35:07 abadger1999: that's what he was saying... 19:35:27 I was imprecise, sorry 19:36:24 Proposal: start mass rebuild as soon as perl rebuild is merged back and redhat-rpm-config is patched for libtool, but no earlier than Jul 20 19:36:52 (with the assumption that if it is delayed till next week's FESCo meeting, we'd look at other options) 19:38:09 mitr seems sane +1 19:38:26 mitr: +1 19:38:32 +1 19:38:38 im okay with that 19:38:41 ok. 19:39:13 #action mitr ask Perl SIG to think about ways of speeding the Perl rebuild up 19:39:16 I'd like to remind everyone there's also a koji storage outage tomorrow/friday. I guess we should mention that to perl folks as well? Or they will figure it out when builds stop getting submitted? 19:39:26 mitr: +1 19:39:38 #info There is a Koji storage outage tomorrow/friday 19:39:51 mitr: ok, if you're going to ask, I proposed it too above :) 19:40:12 nirik: better to tell them 19:40:26 #agreed pjones: Technically we could just start the mass rebuild and let the Perl SIG deal with the conflicts. That's fairly horrible, but how (+6) 19:40:28 * nirik nods. 19:40:30 jreznik: sorry, missed that 19:40:32 #undo 19:40:32 Removing item from minutes: 19:40:45 #agreed start mass rebuild as soon as perl rebuild is merged back and redhat-rpm-config is patched for libtool, but no earlier than Jul 20 (+6) 19:40:49 #topic Open Floor 19:40:53 Anything else for open floor? 19:40:58 https://fedoraproject.org/wiki/Changes/NoBinDeps -- submitted this week so I don't know if we want to discuss it -- I think the question as stated in the Change is not a Change but an FPC issue -- but it would be helpful to FPC if fesco discussed the basic issue of whether we want UsrMove to imply that we've "merged /bin with /usr/bin" or that we've "replaced /bin with /usr/bin" 19:41:55 FPC meets tomorrow so if we wanted to discuss this now -- I'd be able to discuss it at tomorrow's FPC meeting. 19:42:03 I am strongly against anything that asks packagers to patch and move things around for a fedora specific reason that does not provide any obvious end-user benefit. 19:42:08 abadger1999: i.e. "whether anything is allowed to be packaged for /bin", is that right? 19:42:22 Which I guess comes down to "merged /bin with /usr/bin" 19:42:26 mitr: basically -- it's really about where RPM thinks things live ie: 19:42:27 %files 19:42:35 /bin/bash 19:42:37 vs 19:42:38 I think we should create a list of packages that should keep requiring/providing /bin deps - such as /bin/sh 19:42:39 %files 19:42:44 %{_bindir}/bash 19:42:56 because I think telling everyone that they need to patch #!/bin/bash to #/usr/bin/bash is a clear sign that we've gone off the rails 19:43:01 please no /usr/bin/sh 19:43:05 (#!/usr/bin/bash) 19:43:05 mattdm, +1 19:43:10 19:43:30 mattdm: +1 - allow the non-/usr paths again 19:43:54 t8m: Do you want a list to make sure that those say in /bin, or a list of the only exceptions allowed in /bin? 19:44:00 So I've discussed this with mattdm and others... I think that if we think of it as merging /bin and /usr/bin it makes htings easiest for FPC to let maintainers do what's best. 19:44:18 mitr, perhaps for the first purpose 19:44:34 mitr, we should not randomly move things 19:44:39 packagers can use %files /bin/sh which will match what autodeps will find in scripts. 19:45:06 packagers who have things that people may need but not know if they are in /bin/ or /usr/bin/ can explicitly have a virtual provide. 19:45:55 packagers where the thing historially just lives in /bin/ don't have to do anything to make /usr/bin/ requires work. 19:46:23 It seems like the least work for everyone. 19:47:22 * mattdm nods 19:48:09 * nirik is fine with the least work plan. 19:48:48 That's +5 19:49:03 Cool. Thanks, I'll take that viewpoint to FPC tomorrow. 19:49:13 * pjones +1 as well 19:50:59 #topiid "merged /bin and /usr/bin" vs. "replaced /bin with /usr/bin" 19:51:01 #agreed FESCo prefers "merged /bin and /usr/bin" 19:51:21 Anything else? 19:51:48 * mitr will close the meeting in 2 minutes if not 19:53:35 Thanks everyone! 19:53:38 #endmeeting