18:00:48 <mitr> #startmeeting FESCO (2013-07-17)
18:00:48 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:50 <mitr> #meetingname fesco
18:00:50 <zodbot> The meeting name has been set to 'fesco'
18:00:52 <mitr> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:00:52 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:54 <mitr> #topic init process
18:01:01 <t8m> Hi all
18:01:04 * abadger1999 here
18:01:07 <nirik> morning everyone.
18:01:23 <pjones> Greetings from sunny Microsoft Building 20
18:01:35 <pjones> (this is a first, right?)
18:01:39 <dgilmore> pjones: :)
18:01:46 * masta looks in
18:01:52 <notting> sunny?
18:01:52 <mattdm> hello!
18:01:57 <pjones> notting: bizarrely, yes
18:02:10 <nirik> lots of sparc hardware there? ;)
18:02:35 <pjones> so what should I buy you guys at the Microsoft Company Store this afternoon?
18:03:27 <mattdm> *crickets*
18:03:28 <jreznik_> pjones: buy the whole ms :)
18:03:32 <pjones> (Oh actually I guess I did this from MS last year too.)
18:03:37 <notting> pjones: ... the seahawks? or the sounders.
18:03:43 <kylem> you can buy me a surface tablet. but even microsoft probably doesn't want them.
18:03:59 <fenrus02> eh? you have to pay money for them now?
18:04:04 <pjones> kylem: I have only gotten "hey, that's not a surface..." while using my nexus 7 once.
18:04:11 <fenrus02> they were giving them away free simply to have people using them
18:04:18 <mitr> Apologies to mattdm
18:04:21 <fossjon> /nsa here
18:04:26 <fossjon> i mean /me here
18:04:26 <mitr> #action mitr Update FESCo meeting process page for election results
18:04:49 <mitr> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:04:49 <zodbot> Current chairs: abadger1999 jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:05:35 <abadger1999> fossjon: your secret is out
18:05:43 <mitr> sgallagh and mmaslano said they wouldn't be available, so that's everybody
18:05:53 <mitr> #topic #1132 libtool + %global _hardened_build 1 = no full hardening
18:05:55 <mitr> .fesco 1132
18:05:57 <mitr> https://fedorahosted.org/fesco/ticket/1132
18:05:58 <zodbot> mitr: #1132 (libtool + %global _hardened_build 1 = no full hardening) – FESCo - https://fedorahosted.org/fesco/ticket/1132
18:06:59 <mitr> We have a comment from ajax: https://bugzilla.redhat.com/show_bug.cgi?id=978949#c8
18:08:08 <mattdm> 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 <mitr> Not so much of the second I think, the recentish libtool macros are calling /usr/bin/libtool IIRC
18:10:35 <mattdm> mitr so, "just patch system libtool" should cover it? What am I missing here?
18:10:39 <t8m> I'd vote for the second option
18:11:04 <mitr> I'd slightly prefer the second option as well, however I'm not sure this needs us micromanaging.
18:11:05 <t8m> mattdm, perhaps not for everything that should be hardened and that we ship, but libtoolize call should fix it
18:11:21 <mitr> What is the outcome we are looking for here?  Let's try:
18:11:43 <mitr> proposal: Add the #978949 bug to the F20 blockers list and ask the redhat-rpm-config + libtool maintainers to solve it
18:11:46 <abadger1999> 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 <mitr> (that's admittedly one extreme of the spectrum, kind of hoping for counterproposals)
18:12:15 <nirik> right, mass rebuild is likely very soon...
18:12:19 <abadger1999> mitr: We decision sooner than F20 blockers would typically be processed b/c of the rebuild dependency.
18:12:27 <abadger1999> *we need the decision
18:12:38 <abadger1999> decision and implementation.
18:13:06 <mitr> abadger1999: good point.  Though this only affects shared libraries.
18:13:07 <nirik> 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 <pjones> 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 <notting> nirik: i'm fine with that
18:14:07 <abadger1999> nirik: wfm +1
18:14:08 <pjones> nirik: I'm +1 there
18:14:22 <mattdm> nirik: also +1
18:14:36 <mitr> 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 <nirik> yeah, it's not ideal, but we have to do mass rebuild soon... so...
18:15:49 <mitr> #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 <mitr> 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 <nirik> fine with me
18:16:50 <mitr> #topic #1135 F20 System Wide Change: Fedora 20 Boost 1.54 Uplift -
18:16:52 <mitr> https://fedoraproject.org/wiki/Changes/F20Boost154
18:16:54 <mitr> .fesco 1135
18:16:56 <mitr> https://fedorahosted.org/fesco/ticket/1135
18:17:01 <mitr> +1
18:17:03 <nirik> +1
18:17:11 <abadger1999> +1
18:17:16 <notting> biennial-+1
18:17:39 <mitr> mmaslano was +1 in the ticket
18:17:46 <t8m> +1
18:17:48 <zodbot> 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 <mattdm> +1
18:19:12 <mitr> #agreed F20 System Wide Change: Fedora 20 Boost 1.54 Uplift was accepted (+6)
18:19:32 <mitr> #topic #1137 F20 Self Contained Changes
18:19:34 <mitr> .fesco 1137
18:19:36 <mitr> https://fedorahosted.org/fesco/ticket/1137
18:19:38 <mitr> See the ticket for a full list of features.
18:19:40 <mitr> 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 <notting> timing!
18:20:29 <mitr> abadger1999: You had questions about shared certificates, Stef has just answered on devel@
18:20:38 <abadger1999> mitr: cool.
18:20:40 * abadger1999 looks at ml
18:21:00 <notting> the ones in the agenda e-mail all are ok with me
18:21:26 <t8m> I'm OK with all the self contained changes in this ticket
18:21:31 <mitr> Since the ticket may not be accessible:
18:21:34 <mitr> - Hadoop - https://fedoraproject.org/wiki/Changes/Hadoop
18:21:36 <mitr> - Shared Certificate Tools -
18:21:38 <mitr> https://fedoraproject.org/wiki/Changes/SharedCertificateTools
18:21:40 <mitr> - SDDM as the default KDE DM -
18:21:42 <mitr> https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM
18:21:44 <mitr> - KDE Plasma Workspaces 4.11 - https://fedoraproject.org/wiki/Changes/KDE411
18:21:46 <mitr> - Yesod Web Framework - https://fedoraproject.org/wiki/Changes/YesodWebFramework
18:21:48 <mitr> - ARM on x86 with libvirt/virt-manager -
18:21:50 <mitr> https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001181.html
18:21:52 <mitr> - VM Snapshot UI with virt-manager -
18:21:54 <mitr> https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
18:21:56 <mitr> I'm also OK with all of them
18:21:57 * nirik is fine with all of them.
18:22:08 <pjones> I'm okay with all of those
18:22:22 <mattdm> me too
18:22:26 <abadger1999> 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 <abadger1999> +1 to all
18:23:10 <mitr> #agreed Self-contained changes from ticket #1137 are accepted (+7)
18:23:25 <mitr> #topic #1136 F20 System Wide Change: ARM as primary Architecture -
18:23:27 <mitr> https://fedoraproject.org/wiki/Changes/ARM_as_Primary
18:23:29 <mitr> .fesco 1136
18:23:31 <mitr> https://fedorahosted.org/fesco/ticket/1136
18:24:05 * dgilmore is here
18:24:18 <mattdm> hi dennis
18:24:20 * bconoboy is here too
18:25:02 <masta> hi guys
18:25:21 <mitr> How do we stand against https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements ?
18:25:21 <bconoboy> you have questions, we have answers :-) where to begin?
18:25:41 <pjones> 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 <bconoboy> 1. yes
18:25:49 <bconoboy> 2. yes
18:25:56 <bconoboy> 3. yes
18:26:00 <bconoboy> 4. yes
18:26:16 <pjones> 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 <bconoboy> ...
18:26:49 <drago01> what about the issues raised on the list? (stack-protector, libGL ..)
18:26:52 <pjones> yes, ellipses for sure.
18:26:54 <bconoboy> pjones: We're not really after a name, we're after technical adjustments
18:27:08 <dgilmore> stack protector is being worked on
18:27:08 <bconoboy> EG, merged build system
18:27:09 <pjones> bconoboy: by all means, proceed with technical adjustments :)
18:27:13 <nirik> well, f19 was that release I thought? arm secondary released at the same time, etc.
18:27:16 <t8m> pjones, there is the switch between blocking koji builds or not - and that is not just "what we call it"
18:27:18 <dgilmore> we belived it was implemented
18:27:27 <t8m> nirik, +1
18:28:00 <dgilmore> nirik: indeed
18:28:04 <pjones> 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 <nirik> the llvm and stack protector bugs must be fixed, but they can be added to the f20 blocker.
18:28:36 <pjones> 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 <mitr> nirik: FWIW I'm not _that_ concerned about OpenGL.
18:29:01 <notting> 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 <nirik> well, it's a think people expect from a primary arch
18:29:14 <mitr> Though notting's argument that the ARM release should match the ARM community's products is very compelling.
18:29:17 <dgilmore> mitr: i do believe its something that will be fixed
18:29:22 <bconoboy> There is a mesa build underway right now that largely resolves the opengl issue.
18:29:38 <abadger1999> notting: note: #8 is contrary to the packaging guidelines.
18:29:45 <drago01> bconoboy: largely means what? working llvmpipe?
18:29:53 <dgilmore> drago01: yes
18:29:56 <kylem> closer to working.
18:29:57 <notting> 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 <kylem> it renders... something.
18:30:08 <pjones> kylem has been making good progress there.
18:30:11 <nirik> 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 <nirik> 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 <dgilmore> nirik: i believe that the change for working libvirt for arm on x86 will help also
18:31:07 <nirik> http://stg.fedoraproject.org/en/get-fedora-options#2nd_arches
18:31:11 <notting> abadger1999: the guideline allows excludearch for 'does not work' with no provision for 'making it work'?
18:31:16 <nirik> oops. not stg, there.
18:31:28 <mitr> notting: no provision beyond filing a bug I believe
18:31:36 <drago01> 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 <notting> nirik: #10 i'd be concerned about docs too - relnotes, etc.
18:32:05 <nirik> 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 <mitr> nirik, drago01: But worth tracking I think.
18:32:22 <abadger1999> notting: Correct: https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Architecture_Support
18:32:25 <bconoboy> 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 <notting> 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 <abadger1999> notting: It's MUST build on one primary arch.
18:32:52 <abadger1999> And also, must be able to track the problems.
18:33:11 <abadger1999> so that hte arch teams can go through and fix problems specific to their arch.
18:33:16 <fossjon> what happens with arch specific pkgs, like x86 only ones
18:33:20 <pjones> abadger1999: that's kind of a terrible requirement :/
18:33:32 <bconoboy> Are the opengl and stack protector issues the only things that fesco wants to discuss with regard to this proposal?
18:33:35 <drago01> 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 <pjones> 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 <drago01> bconoboy: would be nice to avoid that
18:33:56 * nirik notes much of this is probibly historical.
18:34:02 <mitr> 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 <bconoboy> drago01: agree.  conversely, we have enough build hardware that a mass rebuild on arm is probably faster than x86
18:34:09 <mitr> (Is that mass rebuild date feasible even for x86*?)
18:34:15 <nirik> pjones: +1
18:34:27 <abadger1999> 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 <bconoboy> mitr: I don't believe the mass rebuild needs to be done with arm as primary
18:34:30 <drago01> bconoboy: but if it is a primary arch we can't just rebuild one arch iirc
18:34:33 <drago01> dgilmore: ^^?
18:34:41 <dgilmore> mitr: f20 schedule might nt really be feasible
18:35:03 <abadger1999> pjones: The point of them being primary was that they share the same resources like the build system.
18:35:04 <dgilmore> but adding arm and doing mass rebuild with it is feasable
18:35:20 <nirik> abadger1999: and updates system, and package signing, and release images, and qa and docs and....
18:35:22 <pjones> abadger1999: I did say "should", but primary vs secondary should reflect user expectations as well
18:35:29 <abadger1999> nirik: yep.
18:36:28 <notting> 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 <dgilmore> notting: one of two ways
18:36:56 <dgilmore> notting: import matching builds from secondary
18:37:09 <dgilmore> or setup external repo and do mass rebuild
18:37:29 <dgilmore> importing thematching builds is likely best
18:37:48 <dgilmore> we then update mash configs and releng scripts
18:37:56 <notting> dgilmore: that implies arm is doing the mass rebuild one way or another
18:38:09 <dgilmore> notting: right
18:38:43 <pjones> I think I have to go grab lunch right this minute or risk not getting any at all.  brb.
18:38:56 <dgilmore> i would prefer to enable arm prior to mass rebuild, but its not required
18:39:10 <abadger1999> 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 <nirik> could we define that as base critpath? or @standard ?
18:39:59 <nirik> must all build and generally function the same on all primary arches?
18:40:13 <abadger1999> 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 <nirik> I didn't recall seeing anyone saying opengl wasn't something to fix?
18:40:56 <nirik> or do you mean, if we ran into this before release would it be a blocker?
18:41:47 <abadger1999> Well... it might have been hypothetical but bconoboy, were you positing that opengl shouldn't be a blocker to acceptance?
18:41:48 <mitr> nirik: We also have a third option "not release blocking but resulting in ARM not being a primary architecture for F20"
18:41:54 <mitr> Though that's pretty harsh on the ARM team.
18:42:10 <notting> mitr: that's a bit weird in that you then... unbundle the primary builds?
18:42:16 <nirik> well, promoting then demoting has costs.
18:42:29 <nirik> (if thats what you are suggesting)
18:43:04 <notting> yeah, that seems impractical. i think slipping is the answer then
18:43:08 <mitr> 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 <bconoboy> 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 <dgilmore> mitr: its always an option
18:43:51 <bconoboy> If consensus is opengl must be fixed, we'll work with that
18:44:01 <pjones> 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 <bconoboy> we're going to fix it regardless, people are showing up who want it
18:44:12 <abadger1999> pjones: +1
18:44:16 <nirik> right.
18:44:44 * jreznik is not happy with blocking/slipping current PA
18:44:50 <mitr> pjones: +1.  llvmpipe is kind of special because even on x86 the maintainership is limited.
18:44:57 <drago01> abadger1999: repoquery --whatrequires mesa-libGL | wc -l
18:44:57 <drago01> 671
18:45:05 <drago01> not even counting stuff that just dlopen it
18:45:25 <notting> jreznik: sorry, parse error on that
18:45:52 <nirik> 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 <Viking-Ice> 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 <jreznik> 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 <jreznik> Viking-Ice: yep
18:46:34 <notting> 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 <notting> which would be the result of 'only release minimal or kde'
18:47:01 <dgilmore> jreznik: its possible if after beta we think its not working to seperate arm and make it secondary again
18:47:02 <pjones> mitr: fair.  but again - kylem is making good progress on that
18:47:02 <drago01> notting: yeah primary should be "same but other arch"
18:47:04 <nirik> well, boot/netinstall is blocker on x86.
18:47:27 <notting> dgilmore: possible, but it's not a switch that can be easily flipped
18:47:41 <dgilmore> notting: its actually not that hard
18:48:00 <notting> dgilmore: import back into secondary?
18:48:05 <kylem> 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 <dgilmore> notting: yep
18:48:16 <Viking-Ice> notting, sorry not following
18:48:17 <nirik> so, what deliverables would be blocking then?
18:48:28 <mitr> kylem: You know, that would actually work for me personally :)
18:48:37 <drago01> kylem: we will notice by having stuff not working
18:48:40 <dgilmore> notting: import latest mash into koji and update mash configs etc, and koji arches
18:49:17 <drago01> kylem: (I'd even say working opengl means real drivers but that's a bit too much for now)
18:49:30 <notting> 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 <bconoboy> notting: headless is not being proposed
18:51:00 <bconoboy> or maybe that's better directed at viking-ice
18:51:17 <nirik> so, minimal / gnome /kde images are blocking, the rest are best effort?
18:51:38 <bconoboy> do we have to decide release criteria as part of this discussion?
18:52:06 <nirik> well, you need to meet the existing critera or propose changes to it?
18:52:06 <jreznik> nirik: blocking or reason to demote to SA?
18:52:24 <Viking-Ice> 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 <notting> 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 <nirik> jreznik: I don't think we should talk demotion until there's some horrible concrete thing.
18:52:56 <bconoboy> 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 <masta> Viking-Ice: +1
18:53:02 <mitr> 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 <mitr> Viking-Ice: That's not how things work right now I think.
18:53:50 <drago01> mitr: why should they be different? we don't have different criteria x86 vs x86_64 (neither vs ppc back then)
18:53:54 <dgilmore> okay what did i miss?
18:54:25 <bconoboy> dgilmore: http://www.fpaste.org/26002/74087259/
18:54:30 <drago01> dgilmore: http://www.fpaste.org/26003/40872651/
18:54:37 <abadger1999> 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 <mitr> 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 <Viking-Ice> 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 <nirik> abadger1999: well, thats a disservice to arm folks... then they would have 0 f20 release?
18:55:44 <drago01> Viking-Ice: a linux distribution is more then a collection of packages
18:55:55 <abadger1999> 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 <Viking-Ice> drago01, and ?
18:56:12 <dgilmore> abadger1999: we could
18:56:33 <dgilmore> abadger1999: we could only mash x86 as primary
18:56:43 <dgilmore> and mash arm seperately
18:56:51 <dgilmore> though that would be more work for me
18:56:56 <notting> that would lead to tree skew
18:57:18 <dgilmore> it wouldnt be good
18:57:23 <dgilmore> but could be done
18:57:30 <drago01> Viking-Ice: that means we are not building "lego bricks" but a product
18:57:32 <abadger1999> k
18:57:55 * mitr formally notes that the discussion has been going on for > 30 minutes.  Continue?
18:58:19 <Viking-Ice> drago01, the sub-communities are building an product which they have pieced together from the bits we ship
18:58:23 <nirik> proposal: promote arm now, ask everyone to review critera and propose any changes based on this promotion.
18:58:26 <dgilmore> mitr: are people willing to vote?
18:58:52 <mitr> dgilmore: (typically these clock alarms have been ignored ...)
18:59:07 <dgilmore> mitr: okay.
18:59:13 <mitr> nirik, dgilmore: I'm still really unclear about what this means for the F20 schedule.
18:59:25 <dgilmore> for what its worth i like nirik's proposal
18:59:25 <nirik> nothing?
18:59:35 <dgilmore> mitr: nothing
18:59:38 <t8m> nirik, +1
18:59:49 <abadger1999> nirik: +1
18:59:50 <masta> nirik: +1
19:00:03 <mitr> dgilmore: You've said that F20 is infeasible anyway, but that ARM can be done if I'm not mistaken
19:00:20 <notting> 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 <dgilmore> mitr: the f20 schedule is extremely crammed.
19:01:00 <dgilmore> mitr: normally we would have an extra 3 or 4 weeks for the planned mass rebuild
19:01:04 <t8m> dgilmore, it is no-earlier-than schedule
19:01:15 <jreznik> yeah, so the question is - do we have to replan now?
19:01:38 <jreznik> (or once ARM is approved)
19:01:45 <notting> dgilmore: does ARM make it more crammed, or just 'another thing that would benefit from more time'
19:01:52 <dgilmore> the perl guys wanted 4 weeks for their version bump. i could give them one week
19:02:12 <dgilmore> notting: it doesnt make it more crammed
19:03:20 <mitr> 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 <mitr> At which point would ARM "join"?
19:03:51 <dgilmore> mitr: id like to do it before mass rebuild
19:04:23 <dgilmore> though the mass rebuild could happen as secondary and it can be folded in after
19:04:40 <dgilmore> i think the sooner the better
19:05:50 <mitr> OK, I'm +1
19:06:23 <pjones> 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 <mitr> (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 <mitr> We are at +4-0 unless I'm mistaken
19:07:39 <mitr> Any more votes?
19:07:46 <bconoboy> pjones?
19:07:53 <pjones> eh, I'm still on the fence.
19:08:07 <BCrookAtRA> (sorry I'm late) what's the current topic?
19:08:09 <mitr> mattdm, notting?
19:08:10 <abadger1999> +3 explicit; +4 if nirik is voting for his own proposal
19:08:49 <pjones> 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 <bconoboy> +1 on a condition would be reasonable
19:09:13 <dgilmore> pjones: i can live with that
19:09:31 <pbrobinson> pjones: I can live with that but I would like to see those criteria well defined
19:09:42 <notting> '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 <dgilmore> notting: yes i am signing up for that
19:10:08 <nirik> I think it will be very hard to explicitly list everything, we are going to have to learn as we go.
19:10:17 <pjones> 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 <dgilmore> notting: i have 4 arm releng boxes
19:10:33 <pjones> pbrobinson: to be frank, we've been *very* explicit about these things over and over.
19:10:48 <pbrobinson> pjones: that's fine as long as we don't move the goal posts :-)
19:11:18 <pjones> 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 <mitr> 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 <mattdm> I like pjones' "promote in action"
19:12:46 <mattdm> that helps us get there without raising expectations wrongly
19:13:38 <bconoboy> revote?
19:14:33 <nirik> how does promote in action differ from promote?
19:14:36 <nirik> just not announce it?
19:15:03 <dgilmore> 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 <pjones> dgilmore: yes
19:15:32 <dgilmore> pjones: just wanted to be clear
19:15:44 <pbrobinson> dgilmore: pjones: presumably create images and test and various other release related things as well
19:15:52 <pjones> nirik: effectively - don't change wikis to call it primary until we're sure making it primary /has/ worked.
19:15:55 <pjones> pbrobinson: yes
19:16:00 <mattdm> nirik Maybe a different way to say is "promote in infrastructure / releng"
19:16:09 <notting> 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 <pjones> notting: the political cost of the latter is huge.
19:16:37 <dgilmore> pjones: i agree
19:16:51 <pbrobinson> I agree with that very much
19:16:52 <mitr> 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 <pjones> mitr: no, and I'm not suggesting we even try to "hide" anything
19:17:05 <pbrobinson> mitr: it's on the road to primary
19:17:07 <mattdm> that's fine
19:17:14 <mattdm> yeah, in fact, hiding it would be wrong
19:17:18 <pbrobinson> and this is the next step
19:17:28 <pjones> so
19:17:35 <mitr> pbrobinson: That's a nice way to solve it.
19:17:47 <notting> 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 <pjones> notting: +1
19:18:10 <mattdm> +1
19:18:14 <pjones> notting: but you mean F20 ;)
19:18:19 <notting> erm, yes.
19:18:29 <notting> but was mainly trying to figure out what you were proposing
19:18:35 <pbrobinson> :-D
19:18:35 <dgilmore> notting: ive made that same mistake this week
19:18:35 * abadger1999 watches notting roll the delorean back into the garage
19:19:10 <mitr> notting: With said criteria being same as primary / different / will be solved $sometime later (when)?
19:19:13 <nirik> 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 <dgilmore> mitr: i believe that release criteria will only need minimal changes
19:20:00 <mitr> Perhaps we could decide to have the criteria nailed down by Alpha release?
19:20:06 <pjones> 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 <pjones> I suspect there's not a huge risk of us forgetting.
19:20:23 <notting> pjones: i'm ok with the proposal. (sorry, drive-by)
19:20:27 <bconoboy> you can count on me ;-)
19:21:01 <nirik> well, I'm ok I guess, but I would rather it be announced sooner than later...
19:21:11 <abadger1999> 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 <pbrobinson> 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 <dgilmore> can we say its safe to go with pjones's proposal?
19:21:34 <pjones> pbrobinson: well, okay, but bconoboy's does.
19:21:43 <pjones> so I guess we should vote on that
19:22:06 <pbrobinson> pjones: yep!
19:22:48 <mitr> pjones: On notting's proposal I see pjones +1, mattdm +1
19:22:53 <mitr> notting: for clarity, are you +1 as well?
19:22:57 * mitr is +1
19:23:09 <t8m> +1
19:23:16 <abadger1999> +1
19:24:27 <dgilmore> 6 * +1 assuming notting was a +1 as it seemed
19:24:46 <mitr> #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 <mitr> (will add notting's vote to the minutes if notting agrees later)
19:25:08 <dgilmore> thanks all
19:25:08 <mitr> #topic Next week's chair
19:25:10 <mitr> #info Marcela has volunteered to be the next week's chair
19:25:15 <mitr> #topic Open Floor
19:25:20 <mitr> Anything for open floor?
19:25:23 <nirik> so, mass rebuild?
19:25:31 <nirik> should we fire it off on the 20th? or ?
19:25:43 <mitr> #topic Mass rebuild - https://fedorahosted.org/rel-eng/ticket/5655
19:26:07 <mitr> 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 <pjones> Well, we're waiting on the /action/ there, right?  not just the decision
19:26:43 <dgilmore> mitr: do you want to give perl some time to get done first?
19:26:48 <mitr> pjones: yes
19:27:07 <jreznik> looking on changes proposed, I'm not see anything else to be approved that needs mass rebuild (except already approved Perl)
19:27:42 <dgilmore> jreznik: boost will need a side tag. or to be done outside of the mass rebuild
19:27:46 <mitr> 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 <dgilmore> mitr: the two will interfere
19:28:42 <mitr> ... and the perl rebuilds have actually already started.
19:28:44 <jreznik> dgilmore: I did not mention it based on your comment in the ticket
19:29:16 <dgilmore> mitr: they have started already
19:29:56 <jreznik> how much time before branching f20 mass rebuilds has to be done?
19:30:35 <dgilmore> jreznik: we could branch right after
19:30:57 <dgilmore> it will mean that all clean ups need a rawhide and f20 build
19:31:15 <dgilmore> which is why we usually leave two weeks
19:31:27 <dgilmore> a week for mass rebuild
19:31:39 <jreznik> dgilmore: ok, I count it together, I got it now
19:31:54 <jreznik> mass rebuild + cleanup as one period
19:32:03 <dgilmore> 2 weeks to clean up failures
19:32:13 * jreznik understands now
19:32:13 <mitr> 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 <dgilmore> then branch
19:32:28 <dgilmore> mitr: yes
19:32:58 <dgilmore> mitr: as soon as we can merge perl back in we should start
19:33:08 <dgilmore> to avoid stepping on toes
19:33:14 <mitr> So, options? 1) wait/not wait on perl, 2) wait/not wait on hardened build fixed in libtool?
19:33:27 <jreznik> where would be the point to move the schedule then?
19:33:30 <pjones> Well, it sounds like we have to wait for perl
19:33:41 <pjones> since they interfere and it's already started
19:34:01 <jreznik> seems like
19:34:11 <dgilmore> we can see what we can do to speed up perl
19:34:21 <abadger1999> 2) I'd wait... that's why we passed "make changes to redhat-rpm-config for now", right?
19:34:28 <pjones> abadger1999: +1
19:34:48 <mitr> abadger1999: I'm thinking about the redhat-rpm-config change
19:35:03 * jreznik will try to talk to ppisar tomorrow
19:35:07 <mitr> 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 <pjones> abadger1999: that's what he was saying...
19:35:27 <mitr> I was imprecise, sorry
19:36:24 <mitr> 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 <mitr> (with the assumption that if it is delayed till next week's FESCo meeting, we'd look at other options)
19:38:09 <mattdm> mitr seems sane +1
19:38:26 <pjones> mitr: +1
19:38:32 <t8m> +1
19:38:38 <dgilmore> im okay with that
19:38:41 <nirik> ok.
19:39:13 <mitr> #action mitr ask Perl SIG to think about ways of speeding the Perl rebuild up
19:39:16 <nirik> 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 <abadger1999> mitr: +1
19:39:38 <mitr> #info There is a Koji storage outage tomorrow/friday
19:39:51 <jreznik> mitr: ok, if you're going to ask, I proposed it too above :)
19:40:12 <jreznik> nirik: better to tell them
19:40:26 <mitr> #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 <mitr> jreznik: sorry, missed that
19:40:32 <mitr> #undo
19:40:32 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x172e3a50>
19:40:45 <mitr> #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 <mitr> #topic Open Floor
19:40:53 <mitr> Anything else for open floor?
19:40:58 <abadger1999> 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 <abadger1999> 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 <mattdm> 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 <mitr> abadger1999: i.e. "whether anything is allowed to be packaged for /bin", is that right?
19:42:22 <mattdm> Which I guess comes down to "merged /bin with /usr/bin"
19:42:26 <abadger1999> mitr: basically -- it's really about where RPM thinks things live  ie:
19:42:27 <abadger1999> %files
19:42:35 <abadger1999> /bin/bash
19:42:37 <abadger1999> vs
19:42:38 <t8m> I think we should create a list of packages that should keep requiring/providing /bin deps - such as /bin/sh
19:42:39 <abadger1999> %files
19:42:44 <abadger1999> %{_bindir}/bash
19:42:56 <mattdm> 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 <t8m> please no /usr/bin/sh
19:43:05 <mattdm> (#!/usr/bin/bash)
19:43:05 <t8m> mattdm, +1
19:43:10 <abadger1999> <nod>
19:43:30 <mitr> mattdm: +1 - allow the non-/usr paths again
19:43:54 <mitr> 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 <abadger1999> 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 <t8m> mitr, perhaps for the first purpose
19:44:34 <t8m> mitr, we should not randomly move things
19:44:39 <abadger1999> packagers can use %files /bin/sh which will match what autodeps will find in scripts.
19:45:06 <abadger1999> 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 <abadger1999> packagers where the thing historially just lives in /bin/ don't have to do anything to make /usr/bin/ requires work.
19:46:23 <abadger1999> 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 <mitr> That's +5
19:49:03 <abadger1999> Cool.  Thanks, I'll take that viewpoint to FPC tomorrow.
19:49:13 * pjones +1 as well
19:50:59 <mitr> #topiid "merged /bin and /usr/bin" vs. "replaced /bin with /usr/bin"
19:51:01 <mitr> #agreed FESCo prefers "merged /bin and /usr/bin"
19:51:21 <mitr> Anything else?
19:51:48 * mitr will close the meeting in 2 minutes if not
19:53:35 <mitr> Thanks everyone!
19:53:38 <mitr> #endmeeting