18:02:12 #startmeeting FESCO (2015-01-28) 18:02:12 #meetingname fesco 18:02:12 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:02:12 #topic init process 18:02:12 Meeting started Wed Jan 28 18:02:12 2015 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:12 The meeting name has been set to 'fesco' 18:02:12 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:02:20 Hello 18:02:25 hello 18:02:43 hi 18:03:14 half here -- leaving for the airport soon for fosdem 18:03:24 hola 18:04:06 hi all 18:04:06 .hello sgallagh 18:04:07 sgallagh: sgallagh 'Stephen Gallagher' 18:04:20 cool. We have a long agenda today so I guess we should get started. 18:04:30 is there anything in particular folks would like to do first? 18:04:37 or shall I just go via the agenda order? 18:04:53 as for me - just go ahead 18:05:02 Full speed ahead 18:05:16 alrighty 18:05:23 #topic ticket #1326 change to fesco replacement process? 18:05:23 https://fedorahosted.org/fesco/ticket/1326 18:05:24 .fesco 1326 18:05:26 nirik: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326 18:05:35 we tabled this to discuss more in ticket. 18:05:39 which we... didn't do. 18:05:47 so, punt further down the road? 18:05:54 Yes 18:05:58 like after the Change deadline 18:06:11 +1 to punt 18:06:21 jwb: We're past the Change Submission Deadline already 18:06:26 +1 to punt 18:06:32 sgallagh, but we're not done reviewing them 18:06:36 But yeah, let's punt it 18:06:41 until we are, i don't see this being discussed 18:06:52 sure. Next meeting is new fesco? or the one after that? 18:07:08 #info will table this for now and discuss more as time permits. 18:07:18 /me wonders when the magazine interviews will be up 18:07:21 #topic ticket #1392 Review scope of "Python 3 as default" Change for F22 18:07:22 https://fedorahosted.org/fesco/ticket/1392 18:07:22 .fesco 1392 18:07:25 nirik: #1392 (Review scope of "Python 3 as default" Change for F22) – FESCo - https://fedorahosted.org/fesco/ticket/1392 18:07:59 adamw: did your concerns get answered here? 18:08:09 or do we still need to determine the real scope? 18:09:19 so, it reads to me like f23 might be a better cycle for this. 18:09:34 nirik, I think that as well 18:09:39 This Change is kind of the new system units change. It could be years before everything moves. 18:09:41 there's also a proposal just posted to the mailing list about mass filing bugs for python apps to switch to python3 18:09:57 we already ship both Python 2 and Python 3 on the install media, so it's kind of incremental process converting indivial apps 18:10:05 kalev, +1 18:10:07 nirik: I'm in favor of the mass-filing. 18:10:15 I guess it comes down to when we want to _advertise_ that we're using python 3 by default 18:10:21 If nothing else, it will help keep track of how far along we are 18:10:43 sgallagh: I'm ok with it, but perhaps after branch and targeting rawhide. 18:10:51 we are already using it in some capacity, but not _everything_ is using it -- maybe it would make sense to advertise the python 3 porting when everything is done in the default install? 18:11:10 kalev, agreed 18:11:15 nirik: The Change (as its title says) is targeting F22 18:11:33 kalev: Either that, or at least require the default install to call to python2 explicitly and make /usr/bin/python -> /usr/bin/python3 18:11:34 nirik: sorry, just caught the ping, let me catch up 18:11:34 not that it is a blocker for the release or feature, but none of the compose tools have been looked at porting yet 18:11:35 mitr: yeah, I am wondering if it shouldn't retarget for f23. 18:11:39 That effectively makes it "default" 18:11:52 sgallagh: we shouldn't do that ever, imho. ;) 18:12:12 sgallagh: afaik upstream recommends that /usr/bin/python die in a fire 18:12:21 the key point for me is to get clarity on whether anaconda is going python3 for f22, because that would worry me. 18:12:22 dgilmore: acknowledged 18:12:23 and that you call explicitly python2 and python3 18:12:40 (PEP 394) 18:13:03 adamw: I think the answer to that is no 18:13:38 I think the answer should be no, but it's not clear. ;) 18:13:40 Anaconda can probably be excused from the "default" argument since it's really only run in a private environment. So what's left of the Change proposal? 18:13:47 if the answer is no, then the Change page should be amended not to cover it (so we don't have confusion later in the process and in PR and stuff) 18:14:21 for example there is no chance we would have authconfig-gtk gui in Python3 any time soon 18:14:35 on the other hand the command line ui could be ported easily 18:14:42 anaconda using python2 will also mean that bullet point " Python 3 is the only Python implementation on the LiveCD " is not going to be true either 18:15:00 adamw: right 18:15:01 and I am not sure about the dnf point 18:15:04 I am currently thinking about dropping the gui altoghether for F23 18:15:08 maybe cloud can be python3 only 18:15:08 DNF has its own Change, so we probably don't need to discuss it much here 18:15:28 (but obviously if that Change gets pushed out, this page should be updated too) 18:15:38 adamw: I meant dnf using python3 18:15:42 and postponing the switch of the command line ui to F23 as well 18:15:47 right now, it does not. 18:15:49 does anyone see value in highlighting an on-going porting effort in F22? 18:16:06 because if not, then we punt this to F23 and we can stop talking about it 18:16:07 nirik: ah, heh, hadn't even thought about that. 18:16:20 jwb: some. but it really depends on how much lands 18:16:20 jwb: Well, there's one advantage. 18:16:35 No one ever works on a porting effort until there's a time constraint. 18:16:38 jwb: right, that's what my point earlier was as well -- I don't think it's worth highlighting the on-going porting for F22 18:16:49 The further out it gets punted, the less likely it becomes that anyone will do the work. 18:17:00 (Until the eventual upstream death of Python 2.7) 18:17:05 sgallagh, i don't even think F23 is a realistic target. i also don't think magic porting is going to happen because FESCo accepts a feature. 18:17:11 At which point now we have a fire-drill 18:17:16 I do see a fair bit of work... 18:17:26 I see a crap ton of work 18:17:32 it's just that IMHO trying to land it for f22 will result in lots of pain and slippage 18:17:37 i see ponies. 18:17:49 nirik, +1 18:18:12 Yeah, I don't think this will be *complete* in F22 18:18:15 I see a big city whose fame touches the stars. 18:18:18 I think we should encourage individual apps to go on with porting if they feel it's safe to do so 18:18:21 there's a python3-dnf (just don't know how well it works), there's dnf support in anaconda now, there's a ton of upstream patches. 18:18:23 but don't require it 18:18:26 jwb: I don’t think we will ~ever get _everything_ ported, but a smaller target of more popular/frequently used packages (like the default Product installs) must be feasible, or what is FESCo really doing here? 18:18:59 Considering the scope of this, it might be worth proposing "Update software to use modern interpreters" as one of the Council Goal positions. 18:19:00 mitr, FESCo isn't doing anything here. why do you think this is something FESCo is doing? 18:19:08 well, the question here is: is there enough work or things landing to make it worth highlighting as a change? 18:19:11 Thereby assigning it a high-level shepherd 18:19:20 mitr, or, more specifically, what action do you think FESCo should take? 18:19:27 (that was my poor translation of a Czech prophet Libuše's words) 18:19:33 :S 18:19:35 :D 18:19:51 I'm ok with: a) rescoping this change to what really will happen in f22, or b) moving to f23... but if a) is small, it seems like it might not be worth it. 18:19:59 jwb: That’s not what I mean—if we can’t get a cross-distribution effort done then why have a voted cross-distribution decision body (instead of e.g. just letting adamw decide what daily build is a GA release)? 18:20:18 mitr, again, what action(s) do you see FESCo needing to take to accomplish that? 18:20:43 i'm not disagreeing with you. i'm asking you what we need to do. 18:20:49 mitr, +1 18:20:50 mitr: Someone has to decide whether such an effort is a) desirable and b) feasible 18:21:11 And then ideally act as a coordinating force to see it done. 18:21:14 I think it is, it's just too late to land some of it this cycle. ;) 18:21:17 sgallagh: and i think we all say its desirable but question feasibility for f22 18:21:26 jwb: Dunno. Write Fedora Magazine articles? Ping people individually? Slip the release? Reject any commits that aren’t porting Python until Python is ported? 18:21:27 As far as the latter, I think we can improve on the coordination 18:21:42 Part of that would be approving the mass-bug-filing request (which I am in favor of) 18:21:50 (and fwiw this ticket did cause people to be individually pinged, at least by anaconda developers) 18:21:58 * jwb sighs 18:22:14 what can we decide here? 18:22:18 proposal: defer this to F23, file bugs against rawhide after branch 18:22:25 jwb: +1 18:22:26 jwb: +1 18:22:27 jwb: +1 18:22:40 Proposal: Check status at the Change checkpoint, and _then_ decide. 18:22:42 jwb, +1 18:22:44 * nirik wishes the change owner could be here... oh well 18:22:59 but i can be mitr +1 as well 18:22:59 +1 18:23:15 mitr: that was -3 days ago? 18:23:34 Do we specifically need to be hasty now? Would deferring this free up critical resources needed elsewhere or something? 18:23:34 sorry... 18:23:49 2-24 18:23:49 nirik: Feb 24 = completion deadline / alpha freeze 18:23:57 mitr: Well, Anaconda has plenty on their plates 18:24:02 mitr: well, my 2 concerns are: 18:24:19 If they could spend the next month porting to python 3 or fixing bugs, I know where I'd rather see them spend the time 18:24:23 a) qa says they would be ok with that anaconda change landing 2 weeks ago... but not now. 18:24:34 b) things like python3-dnf haven't been used likely by anyone. 18:24:52 * mitr counts +6 to jwb’s proposal (if he is voting for that proposal as well) 18:24:59 i am :) 18:25:17 fwiw, i don't think we're being hasty. i think we're being realistic 18:25:31 jwb: agreed 18:25:35 I agree 18:25:37 .hello corey84 18:25:38 #agreed defer this to F23, file bugs against rawhide after branch (+6,0,0) 18:25:38 Corey84: corey84 'Corey84' 18:25:57 #topic ticket #1393 Making perl-sig a watcher on all perl packages 18:25:57 https://fedorahosted.org/fesco/ticket/1393 18:25:57 .fesco 1393 18:25:58 +1 from thozza in ticket. 18:25:58 the python3 switch of anaconda should bake in rawhide at least for a while, not to be developed after branch 18:25:59 nirik: #1393 (Making perl-sig a watcher on all perl packages) – FESCo - https://fedorahosted.org/fesco/ticket/1393 18:26:15 I'm +1 to this since it's just watching. 18:26:19 +1 watch 18:26:24 t8m: thats the kind of thing that should land the day after branching :) 18:26:34 +1 to this 18:26:35 +1 to adding perl-sig to watch 18:26:40 dgilmore, yeah 18:26:41 +1 18:26:48 +1 18:26:51 Assuming all members of the PERL SIG are okay, with this, +1 18:26:54 that +5 so far 18:26:57 Note: this is an one-time request. Would it be easy to make this apply automatically for future packages? 18:27:05 (If they are not, this could lead to a lot of surprising extra emails for them) 18:27:14 actually I am not sure why they are requesting it now that I think about it. 18:27:24 Corey84: Please don’t add +- votes if you are not on FESCo, it makes counting more difficult. 18:27:39 watchbugzilla and watchcommits are automatically granted I thought. 18:27:53 so they could just do it. 18:28:10 nirik: They're saying there are hundreds of them to go through. 18:28:11 nirik, I suppose they did not want to manually go through all the packages 18:28:22 pkgdb-cli is your friend. ;) 18:28:34 i was under the impression they wanted to be included by default on all future perl packages 18:28:39 maybe i misread 18:28:42 t8m: (for hundreds == 83) 18:28:56 jwb: well, if the request has it, it would be added. 18:29:04 if not, how do we know something is a 'perl' package? 18:29:18 nirik: prefix of "perl-"? 18:29:18 nirik, don't we have packaging guidelines that say perl packages start with perl- ? 18:29:58 not everything does 18:30:00 perl using applications don't need that do they? 18:30:09 if its a program written in perl it does not have to have it 18:30:19 and i don't think the perl sig cares about those? 18:30:30 but we could add logic if it starts with perl- we add it 18:30:37 but it will not catch all users of perl 18:30:56 I guess automating it for perl- and missing some users would still be an improvement? 18:31:00 better catch some than nothing? 18:31:02 proposal: have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing 18:31:03 i mean, i'm certainly doing a lot of reading between the lines here, but yeah 18:31:16 because "everything that uses perl" probably isn't what they really want 18:31:31 i doubt they want to get bug reports for the kernel, which they would if you take that stance because perf uses it 18:31:36 WELCOME TO BUG HELL 18:31:38 yeah I think they care only about libraries 18:31:42 the ticket does say perl-* 18:31:51 nirik: +1 18:32:00 nirik: +1 18:32:03 nirik: +1 18:32:04 they have definitely cared about non library/module ones in the past, but I don't want to speak for them 18:32:14 note that some perl-* packages might be subpackages of something that isn't perl-* package 18:32:21 those can go through the manual process if needed 18:32:29 sure 18:32:36 nirik, +1 18:32:40 anyway, +1 to nirik's proposal 18:32:59 #agreed have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+6,0,0) 18:33:11 \o/ 18:33:12 #undo 18:33:12 Removing item from minutes: AGREED by nirik at 18:32:59 : have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+6,0,0) 18:33:16 #agreed have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+7,0,0) 18:33:27 #topic ticket #1394 Use timedatex when an NTP package is installed 18:33:27 https://fedorahosted.org/fesco/ticket/1394 18:33:27 .fesco 1394 18:33:27 +1 from thozza in ticket. 18:33:28 nirik: #1394 (Use timedatex when an NTP package is installed) – FESCo - https://fedorahosted.org/fesco/ticket/1394 18:34:35 * nirik isn't sure what to think of this really 18:34:39 mclasen: do you know what Lennart's stance is here? 18:34:49 i haven't had enough time to actually understand this 18:34:56 so i'm not voting on anything 18:35:03 * mclasen missed the question 18:35:12 oh, timedated 18:35:24 I have escalated this to FESCo to allow for a sanity check at least; we will end up with two implementations providing the same interface 18:36:13 I don’t see any reason why it would be problematic but it does seem risky/unusual so I wanted a few more experienced eyes 18:36:17 If I read this correctly, the fundamental issue here is that the systemd guys decided to only support their NIH NTP alternative and have broken compatibility with traditional NTP sources 18:36:41 IIRC the devel@ discussions didn't bring up any specific technical objections 18:36:47 from timedated API user's point of view, I think it makes a lot of sense to keep using the same API for controlling both daemons 18:36:55 gnome-control-center for example doesn't overly care what's the underlying NTP implementation, as long as the API stays the same 18:36:56 /me notes that chrony and ntpd are still in wide use (and that Fedora Server's Domain Controller role relies on and sets up ntpd) 18:36:58 not going to speak for lennart here, but my take it that I don't really want a full ntp server implemenation on my laptop 18:37:26 mclasen: More to the point, a full NTP _client_? 18:37:32 sgallagh: yeah. I run ntp everywhere 18:37:38 mclasen: the NTP server and client are the same daemon 18:37:40 using ntpd 18:38:03 The only difference is whether you allow it to also listen for incoming connections 18:38:03 chrony is a pretty full featured client. 18:38:06 mclasen: I _think_ the proposal allows that -- if we don't install chrony, we'd get the systemd implementation and thing should keep on working 18:38:06 sgallagh: you're getting to the core of the issue... 18:38:30 i am +1 to this going ahead 18:38:33 so the systemd thingy is a client-only implementation? 18:38:43 whereas chrony and ntpd provide both client and server? 18:38:54 jwb: yes, and it's also only SNTP 18:38:55 jwb: client-only for “sntp“ 18:39:01 is the server really so big addition to the code that is needed for client? 18:39:19 t8m: the difference in size is fairly big 18:39:25 fwiw, chronyd doesn't listen on ntp port by default 18:39:54 how big? 18:40:03 given http://lists.freedesktop.org/archives/systemd-devel/2014-August/022523.html I think lennart is wrong. there are a lot of good reasons to configure your own ntp servers 18:40:32 to talk to your ipa server. in a corporate environment that block outbound ntp requests 18:40:35 500 kBytes of chrony does not seem big to me 18:40:36 * nirik is a weak +1 to this as well. 18:40:44 still 0 18:40:48 so I am +1 as well 18:41:25 Wait, timedated can *only* talk to the root servers? 18:41:29 That's... that's horrible. 18:41:50 I am unsure which implementation would make more sense for Workstation, but my current understanding is that the proposal allows individual products to choose if they want systemd implementation or the timedatex one 18:41:52 Proposal: 1) FESCo knows no technical reason why this change would break anything. 2) We prefer a timedated implementation that can allow using chrony or ntpd as the NTP client being used. 18:41:55 sgallagh: it has a configured list of servers 18:41:58 with this in mind, I am +1 as well 18:41:59 sgallagh: it can only talk to the servers it has configured apparently 18:42:17 sgallagh: compile time default, overridable in config file, or through dhcp 18:42:19 (would splitting this discussion help?) 18:42:35 I am weakly +1 (to both) 18:42:40 zbyszek: Well, if a config file can change it, that's not unreasonable. 18:43:29 sgallagh: Sorry, I meant that the compile time default is set to e.g. pool.ntp.fedora.org or something like that, and in addition it can be overriden by config file. 18:43:34 mitr: +1 to both 18:43:57 mitr, +1 to both 18:44:42 +1 to both 18:44:57 So currently, timedated can only talk to timesyncd? 18:45:07 sgallagh: that is the takeaway yes 18:45:11 Which only supports sntp as a protocol, not traditional NTP? 18:45:19 sgallagh: In f22. In f21 the old schme is in place. 18:45:21 sgallagh: and only one server 18:45:24 yes, thats my understanding 18:45:45 dgilmore: It cycles through servers on error. 18:46:08 (after some timeout without a valid answer) 18:46:09 zbyszek: Any plans to support a round-robin or other alternative mechanism? 18:46:14 zbyszek: okay, that is not what is said in the email thread I am reading on systemd-devel 18:46:51 zbyszek: but realistically you should check 2 or 3 sources at all times. just to make sure that you are not trustinga source that is wildly off 18:46:57 sgallagh: SNTP is a subset of NTP (less features but interoperable) 18:47:25 Yeah, the SNTP design case of single-master-server seems not to be too well suited for the actual usage of pool.ntp.org 18:47:33 mlichvar: (or am I wrong?) 18:47:48 dgilmore: I don't really have a position on this issue. I think timesyncd is not yet ready for wide consumption. 18:48:24 so, we are at +4 I think... 18:48:39 OK, so do we as FESCo want to mandate that timedated must be backed (or at least capable of being backed) by chrony and/or ntpd? 18:48:55 mitr: are you +1 to your proposal 18:49:08 sgallagh: not sure what good it would do if upstream doesn't want to do that? 18:49:23 kalev: you were +1 to mitr's ? 18:49:30 mitr: sorry missed your vote 18:49:36 I was +1 to the original proposal in the ticket 18:49:46 nirik: I'd like to believe that upstream will occasionally listen to the needs of its users. 18:50:37 ok, so what do we want to do here... mitr's more detailed proposal is +4, but the ticket proposal is probibly +6? 18:50:59 nirik: I think the original proposal is equivalent to my 1), so make the original proposal pass. 18:51:11 ok. 18:51:23 #agreed This use is approved (+6,0,0) 18:51:28 sgallagh: I do think that it would be good to support all of them, I am not quite sure that it is important enough to mandate by FESCo. Effectively, through, if we allow 1) then de facto the situation will change and we will not strictly _need_ the mandate :) 18:51:32 do we want to discuss the second part more? or just move on? 18:51:52 what is the systemd preset file that the ticket is talking about ? there's different preset files per product, no ? 18:51:57 Move on…. let me formally withdraw it to save time. Someone can repropose if necessary. 18:52:01 mitr: Until upstream decides they know better than FESCo and breaks API... 18:52:22 mclasen: There's a global one and per-product add-ons to it 18:52:34 (Which can add or subtract from the common one) 18:53:03 #topic ticket #1407 F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud - https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic 18:53:03 https://fedorahosted.org/fesco/ticket/1407 18:53:03 .fesco 1407 18:53:04 sgallagh: I’d rather not be angry about the _possibility_ about either of the upstreams being stupid right now 18:53:04 nirik: #1407 (F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud - https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic) – FESCo - https://fedorahosted.org/fesco/ticket/1407 18:53:59 +1 as written. 18:54:08 is it realistic that we're going to get the koji changes in place to do this? 18:54:27 dgilmore, nirik: what's releng's position here, anything that would make it difficult to deliver the new deliverables? 18:54:30 jwb: it should actually all be tehre 18:54:42 +1 from me 18:54:43 everything should be in place as of last night 18:54:47 dgilmore, that is a pleasant surprise! 18:54:51 Though, there are several Changes that propose adding new rel-eng deliverables (and mirror space requirements?); should we just let rel-eng deal with the requests as they think best? 18:54:58 note i'm trying to consolidate these: https://lists.fedoraproject.org/pipermail/devel/2015-January/207240.html 18:55:11 jwb: dgilmore upgraded our builders/hubs to the latest git head koji to pick up a bunch of things (even your xz change I hope) 18:55:29 most of the atomic changes seem to be things we delivered in f21 18:55:37 nirik, sure, i knew that. it wasn't clear the koji patches for this were actually written yet 18:55:58 jwb: the vagrant patches are and are deployed elsewhere 18:56:23 +1 from me 18:56:33 so, to be clear on the vagrant thing, the "out of the box on VirtualBox/VMWare" goal for this change does not include vbox/vmware guest additions, correct? 18:56:45 walters: yeah, there were questions about some of those changes... if they were already done, etc. 18:57:10 walters: main concern is that most of what is proposed we did in f21 18:57:14 jwb: Didn’t we approve VMWare guest additions as a package installed by default about a year ago? 18:57:23 the bare metal atomic was not done in f21 18:57:23 so it was really unclear as to what was actually being proposed 18:57:44 walters: yes it was 18:57:48 mitr, i'm specifically thinking about the kernel modules vbox requires. pretty sure we didn't approve random kernel module packages 18:58:04 i'm just interested to hear how "out of the box" the experience will be without those 18:58:13 walters: you can use anaconda to install atomic on bare metal in f21. that is how we do it for the cloud image. 18:58:21 but its not really well documented 18:58:41 i dunno man, i mean i wrote most of the anaconda patches and maintained the content and actively debug it 18:58:50 one other question on this: QA and release critera? I guess the cloud wg is going to do the testing here ? 18:59:12 among other things the switch to grub2 only landed post f21 18:59:22 so technically you're right some components are in f21 18:59:33 walters: right, but you can deploy it on bare metal. what you likely really want is more anaconda work to make it easier and more integrated 19:00:25 i'd say it this way; i tell people who ask about f21 atomic anaconda not to do it and wait for f22 19:00:47 as to the vagrant images. I guess we will find out if it works well without external kernel modules and is a feasible option 19:00:53 besides grub2, the partitioning defaults are also not in f21 19:00:58 jwb: I guess we find out 19:01:16 so, we are at +3 for this change... 19:01:17 partitioning: https://github.com/projectatomic/fedora-productimg-atomic 19:01:26 do we want to consider all teh atomic changes right now 19:01:30 dgilmore, i'm find with wait and see, but i want the proposal owners to be aware of the potential issue if they aren't already 19:01:33 since walters wants to make them one? 19:01:35 dgilmore: if it would help, sure. 19:01:44 nirik: +1 here too 19:01:45 walters: you want to go to 1? or 2? from 3 19:01:51 we are kinda mixing them anyway 19:01:52 dgilmore: I’d rather work with the text as it is today instead of trying to group-edit it in 10 people right now 19:02:01 mitr, agreed 19:02:02 mitr: no problems 19:02:09 the RpmOstree change is strongly related to but technologically independent of AtomicHost 19:02:14 walters: lets table this until we get to the relevant ticket 19:02:34 right now we are talking pure vagrant images 19:02:43 Perhaps we will end up consolidating them but let's actually talk about the individual items. 19:02:50 sure. 19:02:53 so thats +4 19:02:53 so the status is the koji changes are landed already 19:03:07 there is concerns over the experience and kernel modules 19:03:27 i don't have concerns as much as i'm just curious if they even thought about it 19:03:38 if they didn't, it doesn't concern me one bit :) 19:03:47 anyway, +1 from me 19:03:49 jwb: likely they didn't as its not mentioned 19:03:54 but we can ask 19:04:12 nirik: so with jwb +5? 19:04:14 yep 19:04:22 #agreed Change is approved (+5,0,0) 19:04:24 that lets it pass 19:04:44 #topic ticket #1374 F22 Self Contained Changes 19:04:44 https://fedorahosted.org/fesco/ticket/1374 19:04:44 .fesco 1374 19:04:44 +1 for all from thozza in ticket. 19:04:46 nirik: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374 19:05:32 +1 19:05:40 +1 here 19:05:52 +1 to all of them 19:05:55 +1 to all 19:06:05 sure, +1 19:06:13 there was a +1 in the ticket also 19:06:24 +1 to all 19:06:24 #agreed All self contained changes approved (+7,0,0) 19:06:29 #undo 19:06:29 Removing item from minutes: AGREED by nirik at 19:06:24 : All self contained changes approved (+7,0,0) 19:06:31 +1 19:06:36 Also, sorry. I got distracted for the last conversation, but I'm also +1 to the Vagrant change. (Feel free not to edit the minutes) 19:06:53 #agreed All self contained changes approved (+7,0,0) 19:06:57 #undo 19:06:57 Removing item from minutes: AGREED by nirik at 19:06:53 : All self contained changes approved (+7,0,0) 19:07:02 #agreed All self contained changes approved (+9,0,0) 19:07:12 #topic ticket #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - 19:07:12 https://fedoraproject.org/wiki/Changes/RpmOstree 19:07:12 https://fedorahosted.org/fesco/ticket/1390 19:07:12 .fesco 1390 19:07:15 nirik: #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 19:07:35