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