18:00:36 <jwb> #startmeeting FESCO (2015-02-18)
18:00:36 <zodbot> Meeting started Wed Feb 18 18:00:36 2015 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:36 <jwb> #meetingname fesco
18:00:36 <zodbot> The meeting name has been set to 'fesco'
18:00:36 <jwb> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:00:36 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:00:37 <jwb> #topic init process
18:00:46 <jwb> good day.  who is here?
18:00:46 <nirik> good morning everyone.
18:00:52 <sgallagh> .hello sgallagh
18:00:53 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:00:59 <paragan> Hi all
18:01:42 <jwb> i think mitr said he would not be here
18:01:43 <jzb> .hellomynameis jzb
18:01:44 <zodbot> jzb: jzb 'Joe Brockmeier' <jzb@redhat.com>
18:01:54 <jwb> hi joe
18:02:04 * ajax waves
18:02:16 <jwb> anyone seen dgilmore ?
18:02:18 <jwb> "seen"
18:02:29 <nirik> he was just around in fedora-releng. ;)
18:03:00 <dgilmore> hi
18:03:07 <jwb> ah, great.  let's get started
18:03:14 <jwb> #topic F22 System Wide Change: RpmOstree - Server side composes and
18:03:14 <jwb> atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree
18:03:14 <jwb> .fesco 1390
18:03:15 <zodbot> jwb: #1390 (F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree) – FESCo - https://fedorahosted.org/fesco/ticket/1390
18:03:16 <jwb> https://fedorahosted.org/fesco/ticket/1390
18:03:47 <nirik> walters: you around?
18:03:47 * dgilmore is behind on everything from the last couple of weeks still
18:03:47 <jwb> OK.  so based on my reading, this is simply a Change to highlight the underlying tooling Atomic uses
18:04:00 <jwb> jzb, is my summary fairly accurate?
18:04:04 <nirik> jwb: yeah. Thats my understanding as well.
18:04:23 <jzb> jwb: seems reasonable
18:04:26 <walters> i am
18:04:44 <walters> i've made a few updates to the wiki pages
18:04:47 <jwb> ah great
18:04:54 * dgilmore goes to read
18:05:06 <jwb> walters, for RpmOstree, did i miss anything in my summary there that you think is worth pointing out?
18:06:06 <nirik> I'm +1 to this as it's basically like all the other 'new version x.y.z' changes we have... More detailed docs would be nice. Whats changed ? what would people using it care about seeing in release notes, etc
18:06:17 <jwb> nirik, same
18:06:20 <dgilmore> walters: I think this is way too vague still.
18:06:36 <walters> dgilmore, how can I improve it?
18:06:47 <jwb> dgilmore, i don't think this one is really that vague.  it seems to be "new version of RpmOstree"
18:06:56 <jwb> which is no differen than "new version of gcc"
18:07:04 <walters> there was no Change for it previously though
18:07:07 <nirik> or gnome 3.16 or boost uplift, or...
18:07:14 <dgilmore> walters: it only talks about what rpm-ostree is.
18:07:14 <jzb> walters: what if any impact would it have on what we ship or any other products?
18:07:21 <dgilmore> walters: the summary has Server side composes and atomic upgrades
18:07:37 <dgilmore> there is nothing about that in there that I see
18:07:40 <jwb> dgilmore, i think most of that is covered in teh AtomicHost Change
18:07:48 <dgilmore> and we delivered an atomic tree in f22
18:08:04 <jwb> hey, look.  circle.s
18:08:09 <walters> jzb, I don't think much
18:08:23 <dgilmore> walters: I think the change should be about how somoene would build a ostree and deploy it for themselves
18:08:31 <dgilmore> gahh in f21
18:08:32 <walters> see paragraph 3 in summary
18:09:01 <jwb> walters, jzb: i think it is fair to say if this Change page did not exist, RpmOstree would still ship, nothing else would be impacted, and nobody would notice.  correct?
18:09:18 <jwb> so the Change page itself seems to just be to highlight RpmOStree
18:09:43 <walters> jwb, well...if a component RPM changed in such a way to break it, I don't have a reference point to show if it's not a documented change
18:09:56 <walters> (this is not an abstract thing, current systemd git master broke ostree)
18:09:58 <jzb> walters: good point
18:10:26 <jwb> walters, so you believe the existence of the Change page will elevate the tooling to release blocker status?
18:10:55 * rishi is here
18:10:58 <walters> my goal isn't to block the release, merely to support the tooling
18:11:09 <jwb> you are making this... difficult.
18:11:10 <dgilmore> walters: which we are doing.
18:11:23 <jwb> why did you file this Change?  what is your goal with this one specifically?
18:11:46 <dgilmore> walters: I think that using this change to highlight how people can build thier own trees is of imense benefit
18:12:11 <walters> 1) so that other parts of fedora that interact with/depend on the tools would have a reference point for the effort  2) for what dgilmore just said
18:12:32 <jwb> i'm lost as to what you mean by "reference point."
18:12:39 <walters> and that's why i added paragraph 3 in the summary
18:13:35 <jwb> like an answer to "what is rpm-ostree and why do i care that my package foo broke it"?
18:13:59 <walters> yeah
18:14:34 <jwb> ok.  then i still have no problems with this Change page.  it is essentially a documentation/awareness change
18:15:14 <jwb> we're approaching 15min on this one, and i think the AtomicHost change is the larger discussion.  shall we vote?
18:15:19 * nirik nods.
18:15:23 <thozza> yes
18:15:27 <ajax> yes
18:15:44 <nirik> I'm still +1 as this is just a version thing. I'd like more docs/releasenotes blurbs if possible tho
18:15:53 <jwb> proposal: Approve RpmOstree change
18:15:54 <ajax> +1, same
18:15:54 <jwb> +1
18:16:00 <paragan> +1
18:16:01 <thozza> jwb: +1
18:16:03 <sgallagh> +1
18:16:08 * dgilmore is 0
18:16:38 <jwb> rishi, ?
18:16:46 <rishi> +1
18:17:01 <dgilmore> I would like more documentation and clearer messaging
18:17:13 <rishi> I was still reading the Wiki. Sorry for the delay.
18:17:28 <jwb> #agreed Approve RpmOstree change (+1: 7, -1: 0, 0: 1)
18:17:49 <jwb> #info Further documentation and release notes blurbs would be appreciated
18:17:55 <jwb> ok, let's move on
18:18:03 <jwb> #topic F22 System Wide Change: Atomic Host -
18:18:03 <jwb> https://fedoraproject.org/wiki/Changes/AtomicHost
18:18:03 <jwb> .fesco 1396
18:18:03 <jwb> https://fedorahosted.org/fesco/ticket/1396
18:18:04 <zodbot> jwb: #1396 (F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost) – FESCo - https://fedorahosted.org/fesco/ticket/1396
18:18:20 <jwb> ok.  so somehow i missed that this one is proposing to create a new Product
18:18:23 <walters> note i did finally consolidate the bare metal/vagrant chanegs in here
18:18:38 <nirik> yeah, I did too.
18:19:01 <jwb> walters, are you intending AtomicHost to be a Product on the level of Cloud, Server, and Workstation?
18:19:11 <jwb> jzb too.  sorry
18:19:40 <walters> well
18:19:48 <jzb> jwb: speaking just for me - not at this time, though I can see a point where we might explore building Server w/rpm-ostree
18:19:50 <walters> to be honest, i would like to write code
18:19:52 <sgallagh> Or is this intended to consume Fedora Cloud?
18:20:03 <walters> what it's called and stuff, i mean...
18:20:17 <walters> basically if it stays in Fedora Cloud that's totally fine by me
18:20:25 <jwb> walters, that would make things easier.
18:20:27 <nirik> have the anaconda changes been written/landed? or just thought of?
18:20:38 <walters> nirik, almost a year ago now
18:20:43 <nirik> ha. nice
18:20:44 <jwb> essentially, you want to expand the scope of AtomicHost to beyond just the Cloud image
18:20:51 <walters> exactly
18:21:14 <rishi> walters: So are you thinking of an Atomic Workstation? Or Server?
18:21:19 <dgilmore> walters: has the anaconda support changed since f21?
18:21:27 <walters> dgilmore, GRUB2
18:21:28 <stickster> Whether or not walters is, I think Workstation folks are thinking about it
18:21:34 <dgilmore> walters: i.e. are you able to select a atomic tree in the gui?
18:21:36 <jwb> stickster, not for F22 though
18:21:40 <stickster> jwb: correct.
18:21:46 <walters> dgilmore, no...that would be really nice
18:21:48 <rishi> stickster: Yes. :)
18:21:51 <nirik> so, we would make atomic versions of all the products and ship them as images? or ?
18:21:53 <dgilmore> walters: so the only difference is that grub2 and extlinux are suppoorted?
18:22:08 <rishi> stickster: Which is why I asked walters
18:22:09 <stickster> nirik: Not sure, but probably out of scope here if it's not F22 change related... still TBD
18:22:27 <walters> dgilmore, yes...though for the RpmOstree change I might want to add in ARM/other bootloaders into scope...it shouldn't be too hard
18:22:35 <dgilmore> walters: my main question here is whats new from f21? other than talking it up more
18:22:54 <dgilmore> walters: we really should support more than just x86_64
18:22:58 <walters> you raised that concern before, I answered "we promote it for bare metal, and grub2"
18:23:05 <dgilmore> walters: but that is outside of this discussion
18:23:09 <nirik> so I guess new is vagrant images and a pxe image?
18:23:16 <jwb> nirik, and bare-metal?
18:23:27 <jwb> my question is more _what_ is shipping for those?
18:23:29 <dgilmore> jwb: bare metal with extlinux was supported in f21
18:23:31 <walters> so specifically for bare metal, the intention is the installer acts like the DVD, not boot.iso
18:23:32 <nirik> well, thats been there, but we are just advertising it?
18:23:39 <walters> i.e. it embeds the content
18:23:57 <dgilmore> walters: that requires a lot of changes in pungi to support
18:24:04 <dgilmore> walters: I look forward to seeing patches
18:24:09 <walters> rpm-ostree-toolbox implements this now
18:24:11 <jwb> there is no DVD...
18:24:15 * nirik is getting confused. :) Can someone enumerate what new image files this will entail shipping?
18:24:52 <jwb> we have a Workstation Live image, a Cloud image, and a Server DVD.  what will AtomicHost ship in/on/as?
18:24:56 <dgilmore> walters: what exactly do you want to ship in Fedora 22?
18:25:13 <jzb> jwb, dgilmore those were in other changes
18:25:25 <jwb> jzb, what were in other changes?
18:25:33 <walters> dgilmore, the 3 things on the Change page plus the previous cloud images
18:25:36 <jzb> in addition to qcow2 we want a bare metal installer and vagrant image
18:25:59 <walters> qcow2 and AMIs
18:26:02 <dgilmore> walters: okay there is no mention of a dvd there
18:26:06 <dgilmore> so ignore that
18:26:24 <jwb> jzb, so you want an AtomicHost DVD iso
18:26:33 <dgilmore> the new things is that grub2 is supported in addition to the extlinux support from f21
18:26:33 <walters> no
18:26:44 <dgilmore> the vagrant image
18:26:47 <jzb> jwb: well it should be smaller than CD sized...
18:26:52 <walters> the host content fits into a CDROM, and does not support software collection
18:26:52 <jzb> er DVD sized, but yet
18:26:54 <jzb> yes
18:27:02 <walters> s/collection/choice/
18:27:17 <jwb> so you want an AtomicHost iso.
18:27:27 <walters> conceptually it's like http://wiki.centos.org/Manuals/ReleaseNotes/CentOSMinimalCD6.5
18:27:30 <jzb> jwb: yes
18:27:38 <walters> which neither Fedora nor RHEL have, but ^ is very popular
18:28:09 <walters> because it gives you an all-in-one that is useful to install servers without dragging down gigs of multiple desktops, developer tools etc
18:28:19 <jwb> assmuing such an iso is created, a person would use it to install e.g. a bare-metal machine in the Atomic model.  then they would use ... something we already produce to get updates via atomic?
18:28:35 <walters> right, they get updates from a tree
18:28:50 <jwb> and those trees are already generated and provided by fedora infrastructure
18:28:51 <nirik> that seems much like boot.iso... but I guess has a bit more?
18:29:06 <walters> nirik, boot.iso requires downloading packages from network.
18:29:32 <jwb> nirik, i think it seems more like splatting e.g. a live image to disk
18:29:33 <nirik> sure...
18:29:41 <walters> jwb, no, it's like a small DVD
18:30:22 * jwb scrolls back
18:30:34 <nirik> ok, so we would need pungi to create this based on a ks right?
18:30:34 <walters> coreos actually is always boot-to-live, and their installer is a shell script
18:30:51 <walters> well, we've been using rpm-ostree-toolbox
18:30:55 <walters> but ultimately both call into lorax
18:31:29 <jwb> stop
18:31:35 <jwb> ignore low level details just for one second
18:31:57 <jwb> you want an iso.  the iso is used to install bare-metal.  it does so by splatting an atomic tree onto a disk.
18:32:16 <jwb> so how in that model is it like a DVD?  does the iso contain multiple trees a user can choose from?
18:32:32 <walters> it's like a DVD in that it does not require a network
18:32:39 <jwb> neither does a live install
18:32:58 <jwb> so when you say it's like a DVD, you're confusing me
18:32:59 <ajax> that happens to be true, sure
18:33:13 <nirik> it's like a dvd in that it boots to anaconda and has no live env right?
18:33:21 <walters> personally I try to avoid using media terminology
18:33:25 <nirik> well, like the old no longer made fedora install dvd.
18:33:32 <walters> i think of boot.iso and the install DVD as boot-to-anaconda
18:33:42 <walters> so that's one axis
18:33:56 <jzb> walters: maybe this would be easier: aren't you already generating what we want from Rawhide?
18:33:56 <walters> then the second is whether or not content is embedded
18:33:56 <stickster> walters: That's great, but work with it for the sake of understanding :-)
18:34:03 <jzb> walters: this is a matter of making it official
18:34:12 <jzb> and come out of the build system instead of self-generated
18:34:21 <stickster> So this could just as well be an image like our Live images, only the image is an Atomic Host, provided Anaconda knows how to deal with it (or perhaps doesn't matter if image content is irrelevant at that level)
18:34:36 <nirik> can you install a non atomic host with this iso?
18:34:43 <walters> jzb, all of the tools to generate it are packaged yes
18:34:45 <jwb> nirik, at the moment i'm assuming no
18:34:57 <dgilmore> walters: its an install media that the payload is an atomic tree and not rpms to be installed?
18:34:58 <walters> mmm...not easily
18:35:07 <jzb> walters: right, but also - isn't the ISO you've been doing pretty much the model of what we want here?
18:35:11 <jwb> dgilmore, that is my understanding
18:35:22 <walters> dgilmore, exactly.   (However, with more rpm-ostree changes we could support per-client trees, but it's nontrivial)
18:35:36 <nirik> ok.
18:35:38 <dgilmore> walters: thats ouside of the scope for this discussion
18:35:47 <walters> jzb, yes.
18:36:19 <jwb> ok, so let me summarize
18:36:26 <jwb> the Change proposes to:
18:36:35 <dgilmore> walters: I will have to spend some time with you to see how you are producing what you are and figure out how to tie that into our compose process
18:36:56 <jwb> 1) create an iso that can be used to install an atomic tree on e.g. bare metal.  the iso contains the tree in the image.
18:37:08 <jwb> 2) create similar qcow2 and AMIs
18:37:21 <walters> dgilmore, definitely, would be great.  (Ultimately it's a pretty thin lorax wrapper but there are some details)
18:37:39 <jwb> 3) create a different minimal image for PXE usage
18:37:46 <jwb> is all of that correct?
18:37:48 <thozza> jwb: I think you just paraphrased the proposal itself
18:37:49 <thozza> ;)
18:37:53 <nirik> jwb: + vagrant
18:37:57 <dgilmore> jwb: you missed the vagrant image
18:38:04 <walters> right
18:38:07 <jwb> thozza, well, 1 is a hell of a lot more detailed than the first bullet
18:38:24 <walters> I would elaborate more on 3) though because there are two types of PXE
18:38:25 <thozza> jwb: ok, I agree
18:38:29 <thozza> it is more clear
18:38:38 <jwb> which is entirely what we are after here.  clarity
18:38:45 <thozza> sure
18:38:47 <walters> when most of the people in the Fedora+derivatives world talk about PXE they're talking about PXE-to-Anaconda
18:38:53 <thozza> take my note as an ACK ;)
18:38:56 <walters> where #3 is PXE-to-Live
18:39:10 <walters> which is building on livemedia-creator work from the anaconda guys
18:39:13 <jwb> and tooling exists to create all of the image types?
18:39:18 <walters> yes
18:39:23 <dgilmore> jwb: not that we can use
18:39:32 <jwb> dgilmore, that was not my question.
18:39:36 <jwb> one step at a time
18:39:40 <dgilmore> I have on my todo list to integrate livemedia into koji
18:40:06 <nirik> is the content of the install iso the same as the vagrant images? or ?
18:40:15 <walters> nirik, yep, there's just one tree
18:40:16 <jwb> nirik, that was my next question
18:40:41 <walters> now this is an issue, as it means e.g. the cloud image carries linux-firmware.  But...we can revisit multiple trees at some later point
18:40:45 <dgilmore> walters: PXE to live is just the same as people that pxe boot for teh rootfs right
18:40:49 <jwb> and the anaconda changes already landed
18:40:50 <nirik> ok, so 6 images per arch?
18:41:06 <dgilmore> where you load a kernel and initramfs and use a network based filesystem
18:41:14 <dgilmore> nirik: its all x86_64 only
18:41:53 <nirik> install.iso, install.qcow2, install.ami, vagrant.vbox, vagrant.libvirt, minimal-pxe
18:41:55 <nirik> ok.
18:41:58 <walters> nirik, ah...i'm only counting 5: ISO, vagrant-libvirt, vagrant-virtualbox, pxe-to-live, qcow2  (right?)
18:42:08 <jwb> walters, jzb: so what is missing right now that prevents the install iso from being created?
18:42:18 <walters> i hadn't counted AMI as one would expect that to be in Amazon
18:42:26 <nirik> walters: sure, true.
18:42:41 <jzb> jwb: I don't think Koji has the tools to create the ISO from ostree trees.
18:42:56 <stickster> walters: But might need some changes from our fedimg/push-to-cloud tools... /me looks to oddshocks
18:42:57 <walters> jwb, rel-eng integration
18:43:00 <jwb> jzb, but we create the ostrees right?
18:43:17 <dgilmore> jwb: from the rel-eng side all of this is new and needs investigation to see what it will take
18:43:33 <dgilmore> we have the os tree we make today
18:43:48 <jwb> dgilmore, stickster: and to my understanding, we are looking at options from a people perspective to help this along, correct?
18:43:57 <dgilmore> we have tooling to make vagrant images, but have not yet done so
18:44:13 <dgilmore> we do not have the other tooling mentioned in a state to use
18:44:22 <stickster> jwb: Correct, I would like to see the "rel-eng integration" thing spelled out so we know whether there are immediate things that need done apart from re-architecting for Glorious Future
18:44:29 <jzb> jwb: I don't think he's online right now, but I believe imcleod will be able to lend a hand in the short term as well.
18:44:32 <jzb> stickster: ^^
18:44:44 <stickster> jzb: Sure, much appreciated. It shouldn't be a one-man show.
18:45:02 <jwb> i have another question still, but does anyone in FESCo or otherwise feel this is do-able in the F22 timeframe?
18:45:08 <dgilmore> jwb: we are looking at lots of things going forward and pulling in all resources we can, but it is not a magic bullet
18:45:20 <jwb> dgilmore, there are no magic bullets.
18:45:21 <stickster> jwb: And just to further clarify, we are hiring someone to help with this stuff. But I don't like the idea of saying "stuff" without more SME input on what that stuff is'
18:45:29 <jwb> SME?
18:45:33 <jwb> STOP USING ACRONYMS
18:45:34 <stickster> subject matter expert
18:45:36 <stickster> ILA
18:45:40 <jzb> SUA
18:45:43 <jwb> FUCK
18:45:47 <stickster> heh
18:45:51 <jzb> jwb: I'm not familiar with that one
18:45:52 <jwb> (that's an acronym)
18:45:52 <rishi> :-O
18:46:02 <stickster> Such Undeniable Awesomeness.
18:46:05 <nirik> based on this I am +1.
18:46:16 <jwb> nirik, based on what?   for F22?
18:46:26 <jwb> i've yet to see anyone say we can actually contain the rel-eng side in F22
18:46:26 <nirik> I'd like to see the change page tweaked. I'd even do it if folks wanted.
18:46:32 <stickster> jwb: Back on topic, my point is that I would like to have a better understanding of what needs to be done in rel-eng tooling to support each of the items nirik (or walters, take your pick) enumerated above
18:46:42 <jwb> i mean, this all sounds excellent but what exactly are we approving here
18:46:48 <dgilmore> jwb: from my perspective the vagrant image is doable as is the existing cloud/qemu/kvm images.
18:46:57 <nirik> jwb: well, if those things are not done, we hit the change point and punt to next release.
18:47:07 <jwb> nirik, that's like next week
18:47:12 <dgilmore> but the installer iso and the pxe bits I am much less sure of until I look into it
18:47:39 <jwb> let me take a step back
18:47:57 <jwb> does anyone have issues with Fedora producing the requested trees/images in general?
18:48:08 <jwb> i certainly would like to see this.  it would make Atomic much more consumable
18:48:09 <thozza> jwb: no
18:48:09 <ajax> i do not
18:48:11 <nirik> yeah, time flies doesn't it. ;)
18:48:40 <nirik> I don't have any issues with this as a goal, you are right that it's not too likely by next tuesday
18:48:46 <jwb> ok, sounds like we're generally in agreement on the overall goal.  so now it comes down to timeframe and feasibility
18:48:52 <rishi> jwb: No.
18:48:55 <dgilmore> jwb: fedora producing them I have no issues
18:48:57 <rishi> I would like to see this happen too.
18:49:03 <paragan> no
18:49:10 <thozza> I think that the contingency plan is for the situation when the owners/rel-eng realize that something is not doable in F22 time frame
18:49:16 <rishi> But I don't think my voting +1 will automatically make this happen.
18:49:37 <jwb> jzb, walters: if the bare-metal iso isn't produced for F22 and we get just vagrant + cloud, is that acceptable?
18:49:55 <jzb> jwb: well, I guess it'd have to be :-)
18:49:56 <walters> stickster, it's hard to summarize in the space provided by this GtkEntry in my irc client...probably best on a mailing list?
18:50:12 <jzb> jwb: I'm really hoping we can accomplish that, though
18:50:19 <stickster> walters: Yeah, understood, so long as you can actually enumerate somewhere
18:50:45 <walters> jwb, i guess...i'd probably end up making them on alt.fp.org
18:50:46 <jwb> jzb, from a process standpoint, unless it can be done after next week without impacting the release otherwise, then i don't see it happening for f22
18:51:06 <stickster> (Also, I know I'm not FESCo and hope not to be polluting this meeting. OTOH I have a new team person landing in this particular "hot zone" so I'd like to understand it.) :-)
18:51:21 <jwb> if the tooling integration _can_ land just whenever and it doesn't impact the release, then great
18:51:41 * nirik notes we could be adding that to f23/rawhide now too.
18:51:46 <jwb> yes
18:51:53 <msekleta> 279502
18:51:56 <jwb> ok, so here is what i propose
18:52:04 <stickster> jwb: It seems to me that if the contingency plan is simply "fine, don't have it done," the strict Alpha checkpoint may not be so sensible
18:52:05 * dgilmore notes we are just starting on major tooling changes for f23
18:52:31 <jwb> proposal: FESCo tentatively approves the AtomicHost Change.  nirik will work with walters and jzb to clarify things on the Change page
18:52:38 <dgilmore> +1
18:52:54 <jwb> (because you volunteered nirik)
18:52:54 <nirik> sure, +1.
18:53:00 <thozza> jwb: +1 for it
18:53:08 <paragan> proposal looks good +1
18:53:15 <jwb> i'm +1
18:53:15 <rishi> jwb: I guess by "tentatively" you mean if there are people to do the work.
18:53:29 <rishi> Where "people" is basically nirik at the moment.
18:53:29 <jwb> rishi, meaning we're realistic and realize not all of it may land in F22
18:53:35 <rishi> *nod*
18:53:37 <rishi> +1
18:53:50 <jwb> people includes walters, jzb, dgilmore, etc
18:53:56 <jwb> nirik is helping on the documentation front :)
18:54:08 <jwb> ajax, ?
18:54:25 <ajax> +1
18:54:27 <rishi> jwb: Right
18:54:29 <ajax> sorry, multiple windows
18:54:32 <jwb> sgallagh, ?
18:55:17 <stickster> nirik: Feel free to rope me into the conversation as appropriate.
18:55:33 <jwb> #agreed FESCo tentatively approves the AtomicHost Change.  nirik will work with walters and jzb to clarify things on the Change page (+1: 7, -1: 0, 0:0)
18:55:34 <sgallagh> jwb: Sorry, multi-tasking. +1
18:55:38 <jwb> #undo
18:55:38 <zodbot> Removing item from minutes: AGREED by jwb at 18:55:33 : FESCo tentatively approves the AtomicHost Change.  nirik will work with walters and jzb to clarify things on the Change page (+1: 7, -1: 0, 0:0)
18:55:41 <walters> (and a quick check, this all stays under Cloud?)
18:55:43 <jwb> #agreed FESCo tentatively approves the AtomicHost Change.  nirik will work with walters and jzb to clarify things on the Change page (+1: 8, -1: 0, 0:0)
18:55:48 <jwb> walters, i think at this piont, yes
18:55:53 <walters> ok, cool by me
18:55:55 <jwb> it's not ready to be a separate product yet
18:56:01 <sgallagh> walters: I'm pretty sure the Council has to approve any new Products anyway
18:56:09 <jwb> yes
18:56:25 <jwb> #info AtomicHost stays under Cloud for the time being.
18:56:43 <jwb> ok thanks everyone for hanging in there while we work through this
18:56:46 <jwb> let's move on
18:56:55 <jwb> #topic F21 privacy issue, Geolocation done for every install
18:56:55 <jwb> .fesco 1411
18:56:56 <jwb> https://fedorahosted.org/fesco/ticket/1411
18:56:57 <zodbot> jwb: #1411 (F21 privacy issue, Geolocation done for every install) – FESCo - https://fedorahosted.org/fesco/ticket/1411
18:57:21 <jwb> i'm not seeing an issue here
18:58:06 * dgilmore doesnt see an issue here
18:58:24 <dgilmore> I think it gives us less infmation than we can get from mirrormanager hits
18:58:46 <dgilmore> mm gives us arch and release of the install
18:58:49 <ajax> you have the option of not using mirrormanager, if you do an otherwise not-network install
18:58:53 <nirik> I think we should document this somewhere/somehow for concerened users... but otherwise.
18:59:12 <dgilmore> ajax: you have the option to not use this also
18:59:28 <rishi> dgilmore: You mean via the boot option?
18:59:39 <ajax> yeah, kcmdline isn't what i call obvious
18:59:47 <sgallagh> Proposal: Make sure that the kernel boot option is listed on a wiki page somewhere and otherwise do nothing.
18:59:49 <jwb> i'm not going to make a proposal on this one.  someone else dig in :)
18:59:56 <dgilmore> rishi: that or you do the install dvd with no network
19:00:06 <nirik> sgallagh: well, it's on the anaconda boot options page I think. ;)
19:00:47 <ajax> do we have a place to centrally list these kinds of things?
19:01:36 <dgilmore> ajax: doubtful
19:01:38 <nirik> not sure. I guess we could make a wiki page with GeoLoc or something ?
19:01:50 <nirik> but people would have to know to look for it.
19:01:57 <ajax> i mean, yes, they would
19:01:59 <nirik> https://fedoraproject.org/wiki/Anaconda_Boot_Options#geoloc
19:02:34 <ajax> i mean more in the "this is the kind of data that otherwise mundane interaction with fedora might expose about you" sense
19:02:53 <rishi> ajax: Isn't that basically what a privacy policy would say?
19:02:57 <mitr> Ultimately I suppose we should have a Fedora distribution privacy policy… but we have little chance of keeping it comprehensive and accurate.
19:03:25 <jwb> mitr, that's also not really something i think FESCo should do
19:03:37 <ajax> rishi: there's a gap between what fedora would do with that data, and what a mitm could discover
19:03:45 <sgallagh> We asked Legal about that and got a response that said that the privacy policy didn't need updating for this.
19:03:50 <sgallagh> That's about as official as it gets
19:03:51 <ajax> rishi: the former is a "privacy policy"
19:03:56 <nirik> I guess I am +1 to sgallagh's proposal. I might make a Geolocation wiki page explaining our setup in fedora infra...
19:04:21 <mitr> sgallagh: OK, +1
19:04:47 <rishi> ajax: But there should be something that says these are things that Fedora might expose on the network.
19:05:17 <jwb> rishi, that isn't scalable
19:05:22 <ajax> +1 sgallagh i suppose.  i'd like something more comprehensive but i sure ain't volunteering
19:05:31 <jwb> +1 sgallagh
19:05:32 <ajax> and it's _such_ a rathole
19:06:02 <jwb> we have 5 votes if sgallagh is for his own proposal
19:06:09 <thozza> sgallagh: +1
19:06:09 <sgallagh> jwb: +1, for the record
19:06:19 <ajax> i adore the idea of a linux that gets opsec paranoia right, but it's not really a product goal atm
19:06:35 <jwb> anyone else wish to vote?  dgilmore ?
19:06:37 <rishi> +1
19:06:39 <paragan> +1
19:06:56 <dgilmore> +1 to sgallaghś proposal
19:07:19 <sgallagh> ajax: Isn't that pretty much what Tails is for?
19:07:23 <rishi> ajax: A really paranoid user would probably not use a netowkr in the first place.
19:07:26 <rishi> So that there is too.
19:07:39 <jwb> #agreed Make sure that the kernel boot option is listed on a wiki page somewhere and otherwise do nothing. (+1:9, -1:0, 0:0)
19:07:47 <jwb> lets move on
19:07:58 <jwb> #topic anaconda password change is causing consternation among the
19:07:58 <jwb> user community please review this policy decision
19:07:58 <jwb> .fesco 1412
19:07:59 <jwb> https://fedorahosted.org/fesco/ticket/1412
19:07:59 <zodbot> jwb: #1412 (anaconda password change is causing consternation among the user community please review this policy decision) – FESCo - https://fedorahosted.org/fesco/ticket/1412
19:08:23 <ajax> sgallagh: right.
19:08:43 <ajax> oh good this ticket
19:08:43 <jwb> dcantrell posted a summary of what i understand is the anaconda team's view on this
19:09:11 <jwb> we have 3 choices that i can see
19:09:13 * nirik is still somewhat baffled that this has caused such torment.
19:09:18 <jwb> 1) revert the change
19:09:25 <jwb> correction
19:09:30 <jwb> 1) ask the anaconda team to revert the change
19:09:31 <nirik> well, ask anaconda developers nicely to revert
19:09:49 <jwb> 2) ask the anaconda team to work with the WGs on a per-product policy setup
19:09:53 <jwb> 3) do nothing
19:10:10 <jwb> a variant of 1 would be to carry a revert patch in the SRPM, but that gets... weird
19:10:26 <ajax> so, here's my thing with this
19:10:29 <jwb> in the Workstation WG meeting, they expressed a strong desire for solution 2
19:10:30 <sgallagh> 4) Make a wider statement on standardizing password policy across the distro at some level (not necessarily the current one)
19:10:41 <ajax> do we have any product that actively does not want pwquality checks
19:10:49 <jwb> sgallagh, that can be done in all cases.  it isn't a solution
19:10:56 <jwb> ajax, Workstation
19:10:58 <dgilmore> ajax: workstation
19:11:08 <ajax> uhhh
19:11:25 <dgilmore> this change was a decision by anaconda
19:11:34 <jwb> they really want the check disabled because ssh is not enabled by default
19:11:35 <sgallagh> Also, QA is unhappy with the change, since they have a lot of really simple default passwords in their test plans
19:11:38 <thozza> I think the security should not be forced in such a way to users, disrupting their habits
19:11:44 <ajax> how are you getting that impression, given (say) comment 23 in that ticket?
19:11:47 <dgilmore> it wasn't due to something FESCo said should be done
19:11:48 <nirik> sgallagh: /qa/some qa folks/
19:12:02 <rishi> ajax: Which impression?
19:12:15 <ajax> rishi: the impression that workstation doesn't want this
19:12:17 <rishi> I won't say that Workstation doesn't want the checks at all. It doesn't want to hard enforce the checks.
19:12:24 <dgilmore> thozza: I do not see that as an issue. websites enfore so many different policies
19:12:33 <jwb> ajax, uh... i asked the WG this morning and they said they want solution 2 where it's per-product tunable so they can turn it off
19:12:40 <rishi> ajax: The fact that it reverted a similar thing in gnome-initial-setup some time ago.
19:12:41 <jwb> ajax, cantanzaro is not in the WG
19:12:49 <ajax> well okay fine
19:12:54 <jwb> i'm not just pulling this out of my ass here...
19:13:01 <ajax> as someone who cares more about workstation than anything else, i think they're wrong
19:13:07 <thozza> dgilmore: sure, but was the double click really not sufficient? or some warning
19:13:08 <ajax> but i'm not going to fight that here
19:13:33 <thozza> If I want to shoot myself into foot, I want to be allowed to
19:13:33 <rishi> ajax: Why do you think it is wrong? Honest question.
19:14:05 <sgallagh> Speaking as a person who has done a lot of security work, I'm not really happy with the current requirement. It's enforcing complicated passwords instead of strong passwords.
19:14:20 <thozza> I'm not saying we should happily accept weak passwords, but forcing in such a way is not the best approach in my opinion
19:14:37 * dgilmore thinks that as workstation is the ones that want a change, and the new policy was a decision of teh anaconda team that the two of them should work together to find a solution. if they can't then FESCo can intervene
19:14:43 <ajax> rishi: like i said, not here
19:14:55 <nirik> so, perhaps the way to attack this would be to try and improve libpwquality
19:15:01 <sgallagh> dgilmore: I thought that they asked us to intervene...
19:15:22 <rishi> sgallagh: Somehow I managed to use passwords that are easy to remember and makes libpwquality happy.
19:15:26 <dgilmore> sgallagh: no, it seems to be a user
19:15:43 <dgilmore> sgallagh: based on a thread in a forum
19:15:47 <rishi> Sadly I can't tell the world how I did that.
19:15:50 <nirik> it's not hard.
19:16:10 <sgallagh> rishi: Of course it can be done, but it's usually non-obvious.
19:17:02 <ajax> so, okay, two: anaconda ignores unknown kickstart options, right?
19:17:02 <sgallagh> Anyway, I'm also of the opinion that just requiring an "are you really sure?" second click is probably good enough here.
19:17:15 <jwb> sgallagh, so a revert
19:17:35 <sgallagh> jwb: let me phrase it better.
19:17:42 <rishi> sgallagh: Wasn't it done for Server in the first place?
19:18:05 <sgallagh> Proposal: Revert to the confirmation click in F22, ask for improvements to libpwquality in F23 to make the change less painful.
19:18:09 <sgallagh> rishi: We didn't ask for it.
19:18:16 <ajax> i want to be completely clear here: i think fesco asking for a revert is a very very very bad move.
19:18:23 <sgallagh> Most of our installs are done by kickstart, which was unexpected.
19:18:33 <jwb> ajax, as do i
19:18:42 <ajax> and not because i think the strong password checks are entirely unobjectionable, though that happens to be true
19:18:43 <nirik> sgallagh: ks hasn't changed?
19:18:52 <sgallagh> nirik: No, ks can do as it pleases.
19:18:56 <nirik> right
19:19:05 <mcatanzaro> Hi, I'm not on the workstation WG and wasn't at the meeting. But I read the meeting log and another item that was discussed was that we don't really need anaconda creating user accounts for Workstation at all, that's a job for g-i-s. That would sidestep the problem nicely, but obviously requires product-specific configuration.
19:19:15 <rishi> Re: libpwquality improvements - people have suggested that it is not an exact science. So not sure what to expect.
19:19:23 <jwb> mcatanzaro, sigh.  please one issue at a time
19:19:29 <jwb> we aren't here to discuss that right now
19:20:15 <mcatanzaro> jwb: OK :)  Re libpwquality: we could use it and still enforce checks if the scale was different. Right now it rates relatively strong passwords as 0, that is the problem.
19:20:15 <sgallagh> /me rereads above and realizes he typed "which was unexpected" when he meant to say "which was unaffected..."
19:20:32 <nirik> mcatanzaro: have bugs been filed?
19:21:32 <jwb> dcantrell just left a comment in the ticket.  he is requesting that FESCo come up with a guiding principle on password quality enforcement
19:21:40 <rishi> https://fedorahosted.org/fesco/ticket/1412#comment:16 - does this mean that pwquality folks don't like this either.
19:21:41 <jwb> (that's a paraphrase.  see his comment)
19:21:49 <mcatanzaro> nirik: Not sure. Anyway if products could choose their own quality level, and we could get a *dramatically* lower strictness to reach quality 1, then we'd be good....
19:22:18 <ajax> so it sounds like there are avenues available to address this short of outright revert
19:22:47 <mcatanzaro> I think we can work with the pwquality folks. Our concern as I interpret it is that the anaconda devs seem to want a one-size-fits-all for all products.
19:23:00 <jwb> they kind of do, yes
19:23:08 <nirik> mcatanzaro: well, I guess. I am not sure I agree with setting a lower quality, but I guess it's not my call.
19:23:14 <thozza> What was wrong with the previous way of enforcing strong passwords by double acking it?
19:23:24 <rishi> ajax: What avenues? Prod-specific tweaks?
19:23:31 <dgilmore> the change came about because of the proposal to disable root logins via ssh. https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00043.html is where what is implemented was raised
19:23:35 <sgallagh> thozza: Probably that we were just training people to do so
19:24:12 <ajax> rishi: clearly there's a difference in the necessary password strength for a throwaway vm than for a laptop that might get stolen, so, at least that yes.
19:24:13 <thozza> sgallagh: but it was the user's choice
19:24:52 <rishi> ajax: My understanding is that it needs support from Anaconda.
19:25:12 <ajax> rishi: yeah, it would!
19:25:17 <rishi> See: http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/fedora-workstation.py
19:25:24 <ajax> rishi: and the people doing those products would have to actually interact with anaconda
19:25:28 <ajax> you know
19:25:30 <ajax> get a patch in
19:25:33 <jwb> they've started
19:25:38 <ajax> wunderbar
19:25:48 <rishi> ajax: See the URL. :)
19:26:05 <jwb> ajax, so i think you're proposing to push the work to the WGs?
19:26:15 <jwb> which is option 2
19:26:22 <jwb> which requires some amount of complicity from anaconda
19:26:22 <rishi> jwb: Well, not entirely.
19:26:43 <rishi> Because the Anaconda team will need to maintain 2 code paths.
19:26:48 <ajax> jwb: i think we should set the precedent that escalation to fesco is a thing you do when normal polite interaction with the ecosystem has failed
19:27:02 <ajax> and not just because waaah my choice
19:27:10 <rishi> That I totally agree with, ajax
19:27:12 <thozza> I think the anaconda team should reconsider their approach completely
19:27:39 <jwb> ajax, so your proposal is do nothing :)
19:28:15 <rishi> Mine would be "gently nudge".
19:29:10 <ajax> jwb: more like "gently nudge and table until/unless necessary" (thank you rishi)
19:29:11 <jwb> we're already at 20min on this one
19:29:16 <thozza> so any proposala?
19:29:22 <thozza> *s
19:29:29 <thozza> or voting
19:29:29 * nirik is trying to think up one around helping libpwquality improve...
19:29:31 <rishi> ajax: Although I don't think FESCo has worked like that in the past.
19:29:42 <ajax> rishi: be the change, yo
19:29:49 <rishi> eg., that systemd change
19:29:53 <nirik> the problem is that will not placate the qa folks who object or workstation I suppose.
19:30:15 <rishi> Where we basically became referees between 2 sets of developers.
19:30:22 <dgilmore> nirik: right
19:30:23 <rishi> Anyway...
19:30:29 <ajax> i'm pretty sure it's not our job to make people feel warm and fuzzy
19:30:43 <dgilmore> nirik: and afaik its only a small subset of QA that has raised objections
19:30:46 <rishi> ajax: So what are we doing now?
19:31:03 <nirik> proposal: ask interested parties to work with libpwquality folks to improve tests.
19:31:03 <jwb> babysitting
19:31:05 <rishi> Anyway...
19:31:25 <thozza> nirik: I think there are two things 1. how to enforce strong passwords and 2. how to check the password strength.
19:31:32 <rishi> nirik: Did you see the comment from tmraz?
19:31:34 <thozza> and 1. is more of a problem
19:31:49 <rishi> https://fedorahosted.org/fesco/ticket/1412#comment:16
19:32:10 <rishi> I doubt "improve pwquality" is the answer.
19:32:11 <dgilmore> really it comes down to this ticket was filed by a user based on a whinge session in a forum, after anaconda decided to change the password policies in the installer. with workstation chiming in and saying they dont want the password policy applied to them.
19:32:17 <dgilmore> we have two choices.
19:32:19 <mcatanzaro> FYI the next comments in that ticket show I was wrong in comment #16.
19:32:20 <dgilmore> do nothing
19:32:53 <rishi> dgilmore: There were some threads on Fedora MLs.
19:32:55 <nirik> rishi: yes, I did. I guess it's not clear to me that he intends to not change anything or not
19:32:55 <dgilmore> or sit down and write a policy that says what the minimum password requirements are for Fedora the OS
19:33:02 <dgilmore> rishi: sure
19:33:40 <dgilmore> if we write a policy on minimum password requirements we would need to make sure the defaults matched that in anaconda, pam, etc
19:33:42 <nirik> how about we ask anaconda folks to s/password/passphrase/ :)
19:33:54 <rishi> nirik: I saw people mention that it is not an exact science. So, I don't know. I am not an expert on libpwquality.
19:34:22 <thozza> I think we are going in circles here
19:34:27 <jwb> agreed
19:34:28 <dgilmore> thozza: I think so
19:34:37 <mcatanzaro> Because why would you want a passphrase for a local password? workstation != server, products are different....
19:34:38 <nirik> well, me either, but I have heard several people say they picked something that should be strong, but it wasn't scored as they expected. I don't know if this is a bug in libpwquality or how anaconda uses it or what... but that sounds like a bug.
19:35:16 <nirik> mcatanzaro: because a passphrase makes you realize it can be a long thing you can easily remember. So you don't get in bad habbits about other accounts.
19:35:54 <dgilmore> proposal, FESCo to come up with a policy on the minimum default password requirements for Fedora the OS.  (which users would be free to override)
19:35:57 <jwb> the reason we are going in circles is because none of the proposals marry any of the competing view points
19:36:00 <mcatanzaro> https://lists.fedoraproject.org/pipermail/test/2015-February/125074.html
19:36:05 <nirik> % echo "a nice shot of whiskey please" | pwscore
19:36:05 <nirik> 100
19:36:17 <ajax> don't tempt me
19:36:30 <nirik> mcatanzaro: right, that sounds really a lot like a bug...
19:37:00 <thozza> I think we should at least ask anaconda devels to consider some user input on the change and not treat it as the unquestionable solution
19:37:11 <rishi> Just let the products do whatever they want?
19:37:19 <jwb> thozza, i'm fairly sure they've considered it.
19:37:27 <nirik> thozza: I think most of their resistance to changing is that some of the user input has been very hostile
19:37:40 <thozza> like closing those bugzillas as NOTABUG in every second comment?
19:37:46 <nirik> it's hard to want to give in to someone yelling in your face and shouting
19:37:55 <jwb> proposal: defer
19:38:00 <jwb> we aren't making progress here
19:38:05 * nirik nods. +1
19:38:08 <thozza> jwb: I think we have no better solution now
19:38:12 <thozza> jwb: +1
19:38:16 <jwb> i think there IS no better solution
19:38:17 <dgilmore> jwb: +1
19:38:20 <ajax> i would like to revisit this once existing known bugs are addressed
19:38:28 <jwb> ajax, fair.  i'll info that
19:38:34 <sgallagh> Proposal: everyone gets assigned the password "correct horse battery staple". Should be secure enough for anyone.
19:38:36 <nirik> that might be tenable if someone filed them (which I don't think they did)
19:38:42 <ajax> otherwise +1 jwb
19:38:50 <jwb> #agreed FESCo defers on this
19:39:05 <sgallagh> (Obviously, that was not a serious proposal)
19:39:18 <jwb> #info People seeing issue with seemingly strong passwords should file bugs.  FESCo will revisit when all know bugs are resolved
19:39:29 <jwb> moving on
19:39:39 <nirik> well, all known bugs could be... forever...
19:39:40 <ajax> nirik: i'm willing to treat mailing list posts as proto-bugs for the purpose of this particular spat ;)
19:39:49 <jwb> #topic F22 System Wide Change: Systemd Package Split -
19:39:49 <jwb> https://fedoraproject.org/wiki/Changes/SystemdPackageSplit
19:39:49 <jwb> .fesco 1406
19:39:50 <jwb> https://fedorahosted.org/fesco/ticket/1406
19:39:51 <zodbot> jwb: #1406 (F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit) – FESCo - https://fedorahosted.org/fesco/ticket/1406
19:39:51 <nirik> ajax: fair enough
19:40:24 <ajax> this again?
19:40:31 <thozza> :)
19:40:34 * rishi looks at ajax
19:40:38 <jwb> ajax, we did not have consensus or quorum last week
19:40:46 <sgallagh> Proposal: The systemd package maintainer knows the package best. Trust this.
19:41:03 <jwb> sgallagh, taht is a terrible proposal because there are 3 of them and they disagree
19:41:11 <ajax> ah yeah, just now found last weeks minutes
19:41:13 <rishi> Why can't the systemd guys figure it out themselves?
19:41:19 <thozza> I talked to systemd maintainers/upstream and they don't think this is a good idea either
19:41:20 <sgallagh> jwb: Do they? I thought it was a downstream vs. upstream disagreement
19:41:26 <thozza> msekleta: and lnykryn
19:41:27 <nirik> So, I am still at 0... +1 because I don't want to override a packager on their package. -1 because it seems like a lot of work for little gain and upstream is against it... let me see if I can tip that one way or another.
19:41:37 <jwb> sgallagh, lennart and kay are both upstream and in the team that deals with the fedora package
19:41:45 <nirik> true.
19:41:58 <jwb> sgallagh, if you meant zbyszek_afk alone, then say so
19:42:10 <nirik> the ticket has some sizes that would be saved
19:42:14 <rishi> I am still -1.
19:42:24 <sgallagh> jwb: Last I spoke to them, they didn't *want* to be doing that and were happy that zbyszek was taking it off their hands :-/
19:42:25 <thozza> the proposal was intended to package unused tools and daemons in separate subpackage
19:42:51 <sgallagh> (This was in Brno a couple weeks ago)
19:42:58 <jwb> sgallagh, i don't want to be sitting in this damn meeting anymore.  but i am, and you're arguing for an ambiguous proposal
19:43:01 <rishi> sgallagh: Lennart and Kay clearly said "no" on the ML.
19:43:22 <nirik> thozza: more used you mean?
19:43:22 <msekleta> I am against the split, speaking from position of RHEL systemd maintainer
19:43:40 <thozza> nirik: like systemd-networkd/resolved and so on
19:43:47 <nirik> anyhow, I guess I will tip -1 here. The savings aren't worth it.
19:43:49 <ajax> i still have real difficulty understanding how 30M of buildroot space is such a big deal
19:43:49 <thozza> but then they realized they don't want that
19:43:58 <thozza> so systemd-units is what was left
19:43:59 <jwb> -1
19:44:31 <jwb> we're at -3
19:44:36 <dgilmore> i am -1 to the split
19:44:48 <thozza> also shipping a binary (systemctl) in a different package, although it requires the daemon for most commands does not make sense for systemd guys
19:44:59 <jwb> ajax, are you -1?
19:45:02 <thozza> so therefore I'm also -1
19:45:10 <ajax> yeah, -1
19:45:11 <sgallagh> I'd really rather that the maintainers decide this. If they're incapable of agreeing, I guess I'm -1
19:45:19 <jwb> that's -6.
19:45:29 <ajax> i don't love the -1 but at least as proposed i'm not thrilled
19:45:49 <jwb> #agreed FESCo denies this Change request (+1:1, -1:6, 0:0)
19:45:58 <ajax> and i have to believe there exists a comparably effective and less contentious solution
19:45:59 <jwb> #topic Open Floor
19:46:02 <msekleta> sgallagh, pretty much all other maintainers other than zbyszek are against the split
19:46:28 <thozza> proposal: end this meeting :)
19:46:35 <sgallagh> One quick thing
19:46:41 <sgallagh> GSoC: Please file proposals.
19:46:54 <thozza> nothing is really quick on this meeting ;)
19:46:56 <sgallagh> This was unfortunately postponed to the last minute; please file them by EOD tomorrow
19:46:58 <jwb> #info Please file Google Summer of Code proposals if you are interested
19:46:59 <sgallagh> EOF
19:47:39 <jwb> who wants to chair next week?
19:47:40 <nirik> Oh I had one item.
19:48:08 <jwb> nirik, go ahead
19:48:53 <nirik> So, upstream Xfce is it seems trying to finally release 4.12. I was skeptical, but it seems like things are actually happening...
19:49:07 <nirik> I made a change page, but didn't submit it yet.
19:49:20 <jwb> Denied.  Too late.
19:49:21 <jwb> ;)
19:49:50 <nirik> indeed. However, the Xfce package set is pretty self contained... and we would probibly update f22 in any event
19:50:09 <nirik> but I am not sure if I should try to submit the change now or wait until it actually happens.
19:50:10 <dgilmore> nirik: done by next week? ;)
19:50:14 <jwb> there is always the possiblity to do the work
19:50:54 <nirik> dgilmore: nope... beginning of march
19:51:01 <nirik> is when they are claiming. ;)
19:51:18 <nirik> they also is not any kind of massive release... just lots of bug fixes and translation updates.
19:51:30 <nirik> no gtk3 switch or anything
19:51:36 <sgallagh> nirik: It's not release-blocking, so I'd be okay with it coming in as a late Self-Contained Change
19:51:53 <dgilmore> nirik: I think its up to you. I would be okay with it. but I also use Xfce
19:51:54 <nirik> https://fedoraproject.org/wiki/Changes/Xfce412 is the change page. I need to ping jreznik about it I guess.
19:52:03 <sgallagh> Any chance of getting a snapshot in for Alpha though?
19:52:18 <jwb> sometimes it is better to ask for forgiveness than permission.
19:52:26 <nirik> sgallagh: well, the problem is... we could push 4.11 stuff in... and they could fail to actually release 4.12 again
19:52:38 <nirik> it's been several years
19:52:42 <jwb> #info nirik to investigate late Xfce change
19:52:53 <jreznik> nirik: I'll take a look
19:52:53 * rishi trusts nirik
19:52:54 <sgallagh> nirik: If it's primarily a set of bugfixes, is that really a problem?
19:53:16 <jwb> whilst you continue to discuss this: who wants to chair next week?
19:53:33 <jreznik> also there's lxqt change, I hope guys agreed already on who's going to do what
19:53:34 <nirik> sgallagh: well, I don't want to be stuck shipping 4.11 for 2 more years and have people say "no, can you duplicate it with 4.10"
19:53:43 <jreznik> not sure if it was already updated to reflect it
19:53:57 <nirik> anyhow, I guess I'll submit it, and see what happens. ;)
19:54:03 <nirik> jwb: I guess I could.
19:54:24 <sgallagh> nirik: If it's in that sort of shape, I guess I'd be more inclined to tell you to wait until F23, then
19:54:27 <jwb> nirik, ok.  i was hoping someone else would
19:54:44 <nirik> sgallagh: well, I am paranoid. ;)
19:54:55 <nirik> jwb: me too, but I also want the meeting to end
19:54:56 <sgallagh> nirik, jwb: I think it's probably my turn
19:55:00 <jwb> sold
19:55:00 <sgallagh> I'll take it.
19:55:06 <jwb> #info sgallagh to chair next week
19:55:07 * nirik cheers
19:55:07 <jreznik> well, it's last week before the first change checkpoint...
19:55:17 <jwb> anything else?
19:55:49 <ajax> nothing from me
19:55:49 <mitr> yeah.  mass rebuild timing on f23
19:56:01 * jwb hangs head
19:56:18 <jwb> isn't the answer "as soon as jakub says it's ready"?
19:56:29 <mitr> With the gcc 5 ABI change, C++ seems breaking left and right.  Do we want an early mass rebuild?
19:56:41 <mitr> jwb: AFAICT he was saying gcc was already ready for F22.
19:56:58 <nirik> I didn't get that impression
19:57:04 <mcatanzaro> mitr: On the mailing list we decided that a mass rebuild would not help the C++ ABI situation, because packages need to be built topologically but a mass rebuild would be unordered.
19:57:11 <dgilmore> mitr: we really need to build some new mass rebuidl tooling
19:57:15 <jwb> nirik, nor i.  i saw something about some PRs that need to be fixed first
19:57:22 <mitr> mcatanzaro: OK, never mind then.
19:57:31 <nirik> "There are bugs being fixed both on the gcc side and on the side of packages,
19:57:31 <nirik> I think it is too early for the final mass rebuild, but gcc should be ready
19:57:31 <nirik> for that in a short time. "
19:57:37 <dgilmore> mitr: as the c++ abi change needs some special handling we currently can not account for
19:58:12 <nirik> it would be awesome to say 'rebuild all things that depend on/use gcc. go'
19:58:27 <nirik> (in the order needed with buildrootupdating)
19:58:28 <jwb> it would be awesome to discuss this outside the context of this meeting.
19:58:33 <nirik> yep
19:58:43 <jwb> #info NEED MOAR BUILD TOOLS
19:58:46 <jwb> #endmeeting