16:11:20 #startmeeting FESCO (2016-09-02) 16:11:20 Meeting started Fri Sep 2 16:11:20 2016 UTC. The chair is Rathann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:11:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:11:20 The meeting name has been set to 'fesco_(2016-09-02)' 16:11:23 maxamillion: I happen to work for a large bank whose new branches are coffee shops with lots of power plugs and faster internet access... 16:11:28 #meetingname fesco 16:11:28 The meeting name has been set to 'fesco' 16:12:23 jsmith: I have heard that ... if only there were one near me ;) 16:12:37 jsmith: we talked about that at OSCON 16:13:04 #chair Rathann maxamillion sgallagh nirik jwb dgilmore kalev paragan jsmith 16:13:04 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:13:16 kinda here 16:13:19 #topic init process 16:13:23 .hello sgallagh 16:13:24 sgallagh: sgallagh 'Stephen Gallagher' 16:13:31 morning 16:13:37 .hellomynameis jsmith 16:13:38 jsmith: jsmith 'Jared Smith' 16:13:38 morning 16:13:46 .hello Rathann 16:13:47 Rathann: Sorry, but you don't exist 16:13:51 :) 16:13:54 .hello rathann 16:13:54 .hello pnemade 16:13:54 Rathann: rathann 'Dominik Mierzejewski' 16:13:57 paragan: pnemade 'Parag Nemade' 16:14:13 /me is kind of half here today. 16:14:27 I'm debugging at the same time, so I may not be as talkative as usual 16:14:29 .hello maxamillion 16:14:31 maxamillion: maxamillion 'Adam Miller' 16:15:24 dgilmore? 16:16:00 ok, let's move on 16:16:14 starting with new business 16:16:17 #topic #1622 F26 System Wide Change: Python 3.6 16:16:22 .fesco 1622 16:16:24 Rathann: #1622 (F26 System Wide Change: Python 3.6) – FESCo - https://fedorahosted.org/fesco/ticket/1622 16:17:20 jsmith: will stuff stop working if it's not rebuilt? 16:17:21 +1 here 16:17:27 No complains from me here -- seems logical 16:17:28 +1 16:17:31 +1 16:17:32 +1 here as well 16:17:52 +1 16:17:53 +1 with my normal comment of "this happens every release and now we're approaching the point where process is extraneous" 16:17:58 I just have one comment here 16:18:04 the change page says, "Packages will be rebuilt during mass rebuild. If there is no mass rebuild for whatever reason, a targeted mass rebuild for all python packages will be required. " 16:18:25 this sounds like they want to piggyback on the the mass rebuild for python package rebuilds 16:18:37 jwb: ? 16:18:46 I think this should be separate since the mass rebuild doesn't go in dep order and wouldnt' be able to rebuild all of python stuff 16:18:48 kalev: What's the problem? 16:18:58 kalev: right, it should be a targeted one in a side tag 16:19:08 maxamillion: we've never not approved a python update. 16:19:20 nirik, kalev: What's the advantage of a side-tag? 16:19:32 nirik: let's just make a fesco statement about that, otherwise it might come surprise ... there's new python people handling it this time around 16:19:46 Assuming we got the python package in the buildroot before the mass rebuild, is that meaningfully different? 16:19:47 there's no contact for python-maint team in the Change page 16:19:51 jwb: ah 16:19:55 well, I suppose if they can get it done in one day it's fine just doing it. 16:20:18 aside from that I have no complaints, so +1 16:20:25 jwb: yeah, for language stacks that are just a version bump and not introducing anything non-compat I'm not sure they need a change proposal but meh 16:20:37 nirik: We don't actually assume that the gcc mass-rebuild works perfectly in a single sweep; why would we treat python differently? 16:20:53 sgallagh: the thing is that for the rebuild to work, it has to be done in dependency order. the mass rebuild doesn't go in dep order. therefore, it should be done separately. since it's a large number of packages to rebuild, it's reasonable to do it in a side tag to avoid breaking rawhide during that time. 16:20:53 sgallagh: the mass rebuilds _are_ done in a side tag 16:21:05 maxamillion: I think it still makes sense to do for scheduling purposes 16:21:11 kalev: not sure they have that level of rebuild control/care. 16:21:32 sgallagh: yeah, that's a good point 16:21:37 * nirik hasnt looked at the dep tree. 16:22:18 But like I said: is there a meaningful reason to force them to use a different side-tag than the standard mass rebuild? 16:22:35 anyway, +1 from me, just let's say: #info Python 3.6 rebuilds need to happen separately from the mass rebuild and complete by the time of the mass rebuild 16:22:41 If they have a script that figures out dependency order, I guess that would make sense. 16:22:47 But I suspect that's wishful thinking 16:22:52 sgallagh: yes. mass rebuild doesn't do dep order which is needed for large scale rebuilds that change ABI 16:22:59 ok 16:23:23 #info Python 3.6 rebuilds need to happen separately from the mass rebuild and complete by the time of the mass rebuild 16:23:59 if they have such a script, great, but I am not sure they do. ;) 16:24:20 I'm not convinced we need to levy that restriction on them, but I don't care enough to fight about it 16:25:17 #info Python 3.6 rebuilds should ideally be done in dependency order 16:25:51 I count 8 in favour 16:26:33 #accepted F26 System Wide Change: Python 3.6 (8:+ 0:- 0:0) 16:27:17 now, followups 16:27:20 #topic #1609 Fedora 26 schedule proposal 16:28:02 I haven't seen much progress on this 16:28:31 .fesco 1609 16:28:32 nirik: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609 16:29:03 sgallagh: I guess you don't have the updated schedule proposal? 16:29:16 so, perhaps we should reach out to gcc folks agaain? 16:29:34 nirik: I think that sounds wise 16:29:53 Rathann: I sent the proposed schedule last week and little discussion happened 16:31:17 sorry I am late, I had some doctors appointments 16:32:11 dgilmore: no worries, I was late opening the meeting 16:32:16 So, regarding GCC, I think it's unreasonable at best to ask them to try to move up their schedule by two weeks at this point. 16:32:35 We could *maybe* ask about next year, but I don't think we're likely to get any movement for this year 16:32:37 sgallagh: indeed 16:32:44 agreed, it would be more reasonable to ask for next year, yes 16:32:46 yep, I was more like thinking of asking it now for _next year_ 16:32:49 ah 16:33:00 I thin at this point for this time round we are stuck with whats there 16:33:09 I think we should accomodate gcc 16:33:21 yes. I think so too 16:33:25 if we could get them to move up next year we could slide everything eariler... but I don't see how we can this year. ;( 16:33:27 but we can talk to them about adjusting future schedules 16:33:35 given our past relationship, definitely yes 16:33:45 but also make it clear that next year we'd much appreciate doing it a few weeks earlier 16:33:52 So I see the following possibilities: 1) We take one of the schedules that nirik or I proposed from last week. 2) We schedule the mass rebuild early and take a chance that code generation errors might creep in and force a second rebuild. 3) We skip the mass rebuild and do it in F27. 16:34:21 we kinda need one for aarch64 enablement at least 16:34:23 (I'm fine with asking about next year, but our pressing need is to schedule F26, so let's put a pin in that) 16:34:34 OK, so that probably rules out 3) 16:34:56 i remain in the "accommodate gcc" camp 16:35:10 mattdm: you around? any additional imput here? 16:35:12 given mattdm's feedback I think we need to look at other options long term 16:35:31 * nirik is ok going with 1 for now, but work to change it for next year if we can 16:35:31 I honestly do not see us being able to do April/May instead of May/June 16:35:38 mattdm's feedback is fine, but it's immaterial to the technical work 16:36:00 there's no reason we can't use a schedule and then sit on the final bits for an extra week to avoid memorial day 16:36:22 I think we should go with https://fedorahosted.org/fesco/ticket/1609#comment:16 16:36:34 jwb: indeed 16:36:40 we can wait to release 16:36:58 better to have it sitting there waiting than be scrambling to get it together 16:37:05 (or even do a soft release with a big announcement delayed) 16:37:19 sgallagh: an option 16:37:29 we can decide what to do when we get there 16:37:33 Right 16:37:34 we could try to go with nirik's schedule and do a soft release with announcements delayed, yep 16:37:46 I think for now we should go with sgallagh's proposal in comment 16 16:37:53 ok so 16:37:54 * nirik is fine with either 16:38:09 * paragan too 16:38:17 Proposal: Accept schedule from https://fedorahosted.org/fesco/ticket/1609#comment:16 16:38:20 dgilmore: Is that because of rel-eng concerns with the bodhi enablement? 16:38:24 I am fine with either, although I would prefer the shorter schedule as we seem to be able to do it and mattdm is asking for shorter schedules 16:38:26 +1 Rathann 16:38:29 +1 16:38:30 +1 Rathann 16:38:30 +1 16:38:31 +1 to the proposal 16:39:34 sure, +1 16:39:45 I'm +1 to either schedule, honestly. If rel-eng thinks we could make nirik's schedule work, I'd prefer that (since it gets us out a little faster). If they don't, let's stick with mine. 16:39:48 sgallagh: no concrete concerns. it just gives us plenty of time to deal with any issues 16:39:49 +1 to proposal 16:40:07 +1, although like I said I'd as well prefer nirik's schedule if releng thinks it can work 16:40:10 sgallagh: I am working with QA on a plan to drop Alpha releases entirely 16:40:31 dgilmore: ok, but this is unlikely to materialize for F26, right? 16:40:33 but I want things in place to have rawhide always be alpha quality first 16:40:34 dgilmore: Yeah, I'm looking forward to that 16:40:38 #accepted Fedora 26 schedule proposal https://fedorahosted.org/fesco/ticket/1609#comment:16 (+:9 -:0 0:0) 16:40:42 fwiw mattdm is asking for _consistent_ schedules :) 16:40:45 kalev: at this point unknown 16:41:09 mattdm: Right now, I think we're probably looking at long even-numbered releases and shorter odd-numbered ones 16:41:14 #topic #1614 FHS exception for /snap 16:41:14 can we do an #info about next year's schedule and put that in the ticket, so that gcc/glibc folks would be aware? 16:41:15 but dropping alpha would free up some room and let us hit the targets dates mattdm wants I think 16:41:16 mattdm: we've been tilting at that windmill for 24 releases. 16:41:20 .fesco 1614 16:41:21 Rathann: #1614 (FHS exception for /snap) – FESCo - https://fedorahosted.org/fesco/ticket/1614 16:41:37 As noted in the ticket, I'm -1 on this one if it comes up for a vote today 16:41:42 mattdm: did magic happen? if not, we need to revisit why we are only consistent in being inconsistent 16:41:43 Unfortunately, I can't stick around longer today 16:41:47 maxamillion: Did you get any responses back? 16:41:49 kalev: I'll make a note in the ticket 16:41:50 I still haven't gotten any other responses 16:41:53 Rathann: thanks 16:42:05 I re-ping'd people on the topic and it's just been radio silence 16:42:24 as for /snap, I am also -1 for the exception for now 16:42:27 I don't know the reason, maybe people are busy or on vacation or something 16:43:05 I'm in favor of just voting it, everyone seems to have similar opinions on the topic 16:43:28 I think it's fine if there's no resolution now, the snap maintainers can try to reach the consensus on their own, don't think it needs active fesco poking and reaching out to other distros 16:43:30 yeah, I'm also not in favour of another top level dir 16:43:54 I am pretty stronly in favour of it not being in / 16:44:01 jwb no magic. +1 to revisting. 16:45:15 do we want to vote or just drop this off the meetings until there's some cross-distro agreement? 16:45:17 I'll also note that we're pretty much doubling down on flatpak and it seems a bit weird if fesco is actively trying to reach out to other distros to make exceptions for a competitive solution 16:45:20 On a related note, the 'vdsm' package is trying to pull the same thing 16:45:26 it sounded like upstream snap was going to make them relocatable or something anwya 16:45:32 jwb: +1 16:45:41 yeah, I was looking for info on that, but not finding much 16:45:41 sgallagh: wha? 16:45:44 (They appear to have snuck in an incestuous package review to avoid the issue) 16:45:57 nirik: Not finding much about what? 16:46:15 upstream changing to make /snaps path configurable 16:47:14 https://github.com/snapcore/snapd/pull/1745 16:47:18 maxamillion: https://bugzilla.redhat.com/show_bug.cgi?id=1369102 16:48:03 sgallagh: ugh 16:48:35 anyhow, I am -1 to the exception and think we should just tell them to fix it/close ticket 16:48:38 -1 16:48:48 -1 16:48:50 -1 16:48:54 -1 16:49:00 same here, -1 16:49:12 -1 to the exception 16:49:13 -1 16:49:28 sgallagh: they are fixing it though, yes? 16:49:33 maxamillion: No, they are not 16:49:57 sgallagh: then should we remove it from the distro? 16:50:04 maxamillion: https://bugzilla.redhat.com/show_bug.cgi?id=1361659#c20 16:50:10 vdsm? 16:50:13 jsmith: would you like to add your vote? 16:50:13 dgilmore: Yes 16:50:16 they are working to fix it 16:50:29 and I told them they had to before it was added back when they asked me 16:50:55 dgilmore: They ignored you and it's been pushed stable 16:51:02 and that i doubted fesco would grant an exception if they asked 16:51:10 #rejected FHS exception for /snap (8:+ 0:- 0:0) 16:51:11 Rathann: Sorry, in a work meeting. I already voted above and in the ticket 16:51:16 And as of three days ago, that comment says they aren't going to change it because it would break compatibility. 16:51:16 #undo 16:51:16 Removing item from minutes: REJECTED by Rathann at 16:51:10 : FHS exception for /snap (8:+ 0:- 0:0) 16:51:20 (With what, I don't know) 16:51:21 #rejected FHS exception for /snap (9:+ 0:- 0:0) 16:51:24 sgallagh: then we remove it until it is fixed 16:51:35 dgilmore: I agree, that's where I'm going with this :) 16:51:36 * jsmith explained already that he couldn't stick around for the rest of the meeting 16:51:39 just... just get it fixed 16:51:48 jsmith: :) 16:51:53 you're going to create more work by removing it and then adding it back 16:52:05 do we have to remove stuff from the distro right now? they said they are fixing it ... 16:52:16 kalev: Where did they say taht? 16:52:21 one thing is not letting a new thing in, but this is an old package 16:52:27 sgallagh: in the bug you linked to... 16:52:29 Because the most recent comments I can find say that they aren't going to 16:52:35 sgallagh: in https://bugzilla.redhat.com/show_bug.cgi?id=1369102#c1 16:53:01 jwb: I am okay either way. it needs fixed 16:53:01 #topic #1617 Council update on Third Party Software policy 16:53:09 .fesco 1617 16:53:12 Rathann: #1617 (Council update on Third Party Software policy) – FESCo - https://fedorahosted.org/fesco/ticket/1617 16:53:13 kalev: And a week later, they said https://bugzilla.redhat.com/show_bug.cgi?id=1361659#c20 16:53:13 jwb: by removing I mean just untag it 16:53:22 and let them do a build when its fixed 16:53:58 dgilmore: And blocked from composes, yes? 16:54:16 sgallagh: so it looks like it will get fixed in the next upstream release ... which seems like they are working on it 16:54:20 * kalev thinks this is counter productive. a productive thing would be to have fesco say that this needs to be fixed by the time of next release, e.g. F26 16:54:47 anyhoo .... current topic is Council update on Third Party Software policy ... let's revisit vdsm in Open Floor 16:54:51 can this wait for open floor? 16:54:55 +1 16:54:58 kalev: They stated that it's a compatibility issue, so they pushed it into a bunch of stable releases 16:55:16 So F26 comes along and they say "Sorry, don't want to break existing deployments!"... 16:55:21 sure, and we can say that we want it fixed by the time of F26 and in the mean time can leave it as is for compatibility 16:55:31 Rathann: yeah 16:55:41 lets talk about https://fedorahosted.org/fesco/ticket/1617 16:56:10 so, we have a bit of an implementation for this now 16:56:28 kalev: in dnf? 16:56:40 we have a gnome-initial-setup page that can turn on non-free 3rd party repositories 16:56:53 and after that it would be accessible through dnf as well as through gnome-software 16:57:16 * kalev takes a screenshot 16:57:45 I think paragan had a question about the case where you don't use gnome-software 16:58:01 right 16:58:14 and I have the same question 16:58:50 paragan: shall we open an RFE against dnf for this? 16:59:09 okay, here's how this is looking in the current incarnation: https://kalev.fedorapeople.org/gnome-initial-setup-software-page.png 16:59:24 enabling the switch turns on the 3rd party repos and makes them work through dnf 16:59:44 this is a gnome-initial-setup screenshot, something that users are going to click through for new installations 17:00:07 kalev: and what happens when you flip that switch? 17:00:31 Rathann: it changes enabled=0 to enabled=1 for the nonfree repos that we ship by default 17:01:21 okay so that switch changes the repo file 17:01:26 yup 17:01:44 looks good to me 17:02:03 kalev: where does the 'learn more' point? 17:02:09 sorry, 'find out more' 17:02:14 nirik: hold on, taking a screenshot 17:02:49 should we point that to a wiki page or something online? or is it hard coded in the initial setup app? 17:02:53 nirik: https://kalev.fedorapeople.org/gnome-initial-setup-software-page2.png 17:03:19 looks good, +1 17:04:05 * Rathann is not sure every user understands that they're not "owners" of the software 17:04:19 kalev: This is probably a rathole, but does it store that answer somewhere? Basically so that if you added additional sources in updates, it would adjust them appropriately? 17:04:30 sgallagh: yes, it's also stored in a gsettings key 17:04:46 um 17:04:56 also, how do the non-free repos find their way into Fedora? 17:04:56 why are we discussing implementation details here? 17:05:03 Rathann makes a valid point. Maybe that should be s/software owner/software vendor/ 17:05:06 jwb: indeed 17:05:10 Rathann: that's up to the council and WGs 17:05:15 right 17:05:30 I could nitpick wording, but lets not go there... 17:05:33 the ticket is about the working on the FESCo page. not implementation, etc 17:05:35 ok, sure 17:05:38 sorry, I got carried away since I helped implement this, jwb is right, this is an implementation detail 17:05:52 nirik: please nitpick and file a bug against gnome-initial-setup in gnome bugzilla, it's much appreciated 17:05:55 anyhow, I proposed wording a long while back... 17:05:56 jwb I interpreted it as a query whether this met FESCo's definition of what would be acceptable 17:06:09 sgallagh: i don't follow 17:06:27 kalev: can ponder on it. It's not easy to say in a small dialog. 17:06:28 jwb: Whether it accomplished https://fedorahosted.org/fesco/ticket/1617#comment:1 17:07:26 ok, so let's vote on nirik's rewording, then, unless someone has a better proposal? 17:07:37 https://fedorahosted.org/fesco/ticket/1617#comment:1 17:08:04 I am a bit concerned that it may become a bit too loose to add new repos with this wording, maybe it should go through fesco for each added 3rd party repo for sanity checking? 17:08:13 or one of the top level WG's 17:08:28 sgallagh: that entire comment is about _repositories_ not implementation of tooling. 17:08:35 kalev: Well, new repos have to go through the fedora-repos maintainer anyway 17:08:42 +1 to nirik's rewording 17:08:46 So I think if there was a question, it would show up there 17:09:14 sgallagh: I mean, a spin maintainer could put a .repo file in a different package and just ship it with this wording 17:09:37 kalev: forcing addition to go through fesco directly cripples the WG's ability to curate their own repositories 17:09:51 which was part of the goal of the whole proposal sent to the Council 17:09:51 sure, I don't disagree that it should be the WG deciding it :) 17:10:03 I just don't want random spins to go do their own thing 17:10:03 we either trust our WGs or we don't 17:10:21 jwb: OK, but the real question is: who is allowed to create a file in /etc/yum.repos.d? 17:10:39 sgallagh: the WG 17:10:41 Do we demand that only the fedora-repos package can do that, and therefore the maintainers of that package act as gatekeeper? 17:10:55 Or do we allow various Editions to create a fedora-$edition-repos package? 17:10:57 I also think the 3rd party repos should not conflict with/replace any Fedora package 17:11:09 s/should/must/ 17:11:23 Well, actually. Maybe that's too strong. 17:11:44 I could see an argument for allowing a third-party repo to provide a more feature-complete version of a package in the base. 17:11:54 (In cases of open-core software, for example) 17:13:23 sgallagh: that would only encourage such behaviour more 17:13:51 Rathann: I think I'm okay with letting the WGs have authority on that for their repos 17:13:55 hang on 17:14:05 did all of you actually read https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal in its entirety? 17:14:22 because it says, for example: RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories. 17:15:11 ok, fine 17:15:23 (I read it, but months ago) 17:16:21 look, i'm not meaning to be authoritative here, but you are all trying to revisit discussion we already had at the Council level 17:16:43 the ticket as it stands is to make sure the FESCo page doesn't conflict with the Council decision. nirik's wording accomplishes that. 17:16:45 which is fair, no sense rehashing things already hashed out 17:16:51 ok, great 17:17:17 does nirik's wording make it possible to start adding packages to fedora that point to random 3rd party repos? 17:17:37 I am not sure how to read this, that's a honest question 17:18:02 I think we should try and have a policy that forces the decision through the WG's and disallows adding .repos to packages otherwise 17:18:11 * nirik looks 17:18:28 it just says the process must be community based and transparent 17:18:38 kalev: it might allow that, but as long as they comply with the "Users must explicitly opt in to such repositories after the information is presented to them" ... does it matter? 17:18:39 * dgilmore thinks taht any repos should get added to fedora-repos 17:18:56 maxamillion: I don't know, but I think that's a question that needs answering 17:19:03 fair 17:19:05 yes repos should get added to fedora-repos 17:19:38 I thought we had a guideline you couldn't ship repo files. 17:19:43 alright, so should the policy state that any new third-party repos must be added to the fedora-repos package and ship disabled "out of the box"? 17:19:49 in fact I recall a package doing that and we made them stop 17:19:58 I can't seem to find it. 17:20:05 ah 17:20:10 So, proposal: I'll look, revise and we vote next week? 17:20:35 sounds good. this should make it possible to get something in beta too, plenty of time still 17:20:36 nirik: https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Package_Managers 17:20:49 thanks nirik 17:21:03 ok, right, that may need adjusting too. 17:21:33 nirik: we have a guideline that packages can not ship repo files 17:21:47 dgilmore: yes, the one I pointed to above 17:21:56 :) 17:22:16 yeah, thats fine. I'll align this all... lets move on 17:22:18 nirik: +1 17:22:21 nirik: +1 17:22:33 * kalev nods. 17:22:34 nirik, +1 17:22:37 or is that what you were looking for? 17:22:51 nirik: +1 17:22:56 #action nirik to review and revise wording 17:23:51 #topic #1620 Decide what to do when package is retired and nothing replaces 17:23:58 .fesco 1620 17:24:00 Rathann: #1620 (Decide what to do when package is retired and nothing replaces it directly) – FESCo - https://fedorahosted.org/fesco/ticket/1620 17:24:07 * jwb is 0 for the previous ticket fwiw 17:24:31 I just commented on this ticket, this was discussed in last meeting. 17:24:38 right 17:25:03 Yeah, this is already accounted for 17:25:05 so I should just close this, right? 17:25:22 Rathann: yes 17:25:25 #topic Open Floor 17:25:29 I think we should discuss on https://fedorahosted.org/fesco/ticket/1624 17:25:42 yes, thank you 17:26:33 Rathann: we need a chair for next meeting before Open Floor, yes? 17:26:33 .fesco 1624 17:26:35 paragan: #1624 (Add FreeIPA 4.4.1 to Fedora 25) – FESCo - https://fedorahosted.org/fesco/ticket/1624 17:26:44 #topic #1624 Add FreeIPA 4.4.1 to Fedora 25 17:27:21 maxamillion: right 17:27:30 let's discuss it after the current one 17:27:37 #link https://fedoraproject.org/wiki/Changes/FreeIPA4.4 17:27:42 Rathann: +1 17:28:12 +1 17:28:21 +1 17:28:22 +1 to this change 17:28:25 +1 to FreeIPA 4.4.1 17:28:50 ok, so it looks like it was done already and the Change is just for marketing purposes 17:28:51 +1 17:30:04 Rathann: Well, it's in updates-testing, but if we decided it was too risky, we could ask that it not go stable. 17:30:11 Or downgrade it via epoch, etc. 17:30:14 But Let's not do that. 17:30:15 it is not in updates testing yet 17:30:17 +1 to this change 17:30:19 +1 to freeipa 17:30:30 +1 17:30:35 sorry, I need to step away from the meeting, but I am happy to be next weeks chair if there's nobody else 17:30:50 I submitted the update but bodhi is not yet in a pushing state 17:31:59 #accepted #1624 Add FreeIPA 4.4.1 to Fedora 25 (8:+ 0:- 0:0) 17:32:26 #topic Next week's chair 17:32:43 any volunteers except kalev? 17:33:49 ok, then 17:33:50 #action kalev to run next week's meeting 17:34:04 #topic Open floor 17:34:20 I see one new item 17:34:26 .fesco 1625 17:34:27 Rathann: #1625 (DNF-2 release into rawhide) – FESCo - https://fedorahosted.org/fesco/ticket/1625 17:34:31 Also: vdsm 17:34:53 I've asked them to submit a Change proposal before doing this. Can we just make that FESCo's official reply? 17:34:56 and vdsm, so let's finish discussing vdsm first 17:34:58 Rathann, let them submit the Change proposal and then on that we can discuss 17:35:23 paragan: +1 17:35:44 ok, so what to do about vdsm 17:36:10 IMHO it shouldn't have passed review, but I admit I don't have the full background story on that package 17:36:30 +1 17:37:58 Yeah, I'm really not happy about the review done here. 17:38:10 there was proposal to untag it 17:38:39 and another to request compliance before F26 17:39:32 I'd prefer both, honestly. 17:40:33 * paragan too prefer both 17:41:52 well, lots of rpmlint errors were ignored in the review, too 17:42:12 so +1 to untagging and having it re-reviewed 17:42:20 alright, someone want to make a proposal and we can vote? 17:43:36 Proposal: FESCo requests that vdsm be untagged from all branches and a re-review performed. The FHS violation must be corrected before it will be permitted back into Fedora. 17:44:00 +1 17:44:01 +1 17:44:15 +1 17:45:13 +1 I guess. 17:46:00 +1 to myself, for the record 17:47:38 dgilmore: jwb: ? 17:47:48 #topic Bug 1369102 - vdsm violates FHS with /rhev 17:48:35 kalev: ? 17:49:16 I count 5 in favour, so this is accepted anyway, but if you want to add your vote... 17:49:16 Rathann: kalev said he had to step afk 17:49:19 ah ok 17:50:25 in that case 17:50:28 #accepted FESCo requests that vdsm be untagged from all branches and a re-review performed. The FHS violation must be corrected before it will be permitted back into Fedora. (5:+ 0:- 0:0) 17:50:41 #topic Open floor 17:51:19 does anyone want to discuss https://fedorahosted.org/fesco/ticket/1625 (DNF-2 release into rawhide)? 17:51:37 or do we table it until a Change proposal is made? 17:51:50 Rathann: Like I said: let's just make our official response "File a Change Proposal, don't push it in before that" and go home 17:51:55 ok 17:52:04 I guess that's a Proposal 17:52:07 :) 17:52:19 I guess we don't need to vote on that 17:52:20 * nirik doesn't think the changes are really that big a deal, but perhaps it's just me 17:52:32 nirik: it's not just you 17:52:49 ok, I'll write up our response 17:53:01 nirik: Assuming they captured everything on that page, you're probably right 17:53:17 That said, they were concerned about it enough to raise the alarm, so probably worth going through the motions at least 17:53:58 I'd rather table it, I've not had time to really dig into the DNF-2 stuff and even though I suspect it's inevitable, I'd like to be for informed before we go down that road 17:54:14 maxamillion: Right, hence "ask for a Change Proposal" 17:54:52 sgallagh: oh right, derp 17:54:58 I misunderstood the comment 17:55:18 We're pushing two hours. I don't blame you. 17:55:22 :) 17:55:22 ok, if there's nothing else, I'll close the meeting in 1 minute 17:55:30 /me departs. 17:55:33 * maxamillion hasn't eaten anything in a while ... we're well into food time ;) 17:55:36 Thanks for chairing, Rathann 17:55:37 Rathann: +1 17:55:40 Rathann: thanks for hosting 17:56:01 Rathann, thanks for chairing 17:56:08 * Rathann blushes 17:56:17 thanks for bearing with me 17:56:44 #endmeeting