16:00:08 <nirik> #startmeeting FESCO (2017-09-22)
16:00:08 <zodbot> Meeting started Fri Sep 22 16:00:08 2017 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:08 <zodbot> The meeting name has been set to 'fesco_(2017-09-22)'
16:00:08 <nirik> #meetingname fesco
16:00:08 <zodbot> The meeting name has been set to 'fesco'
16:00:08 <nirik> #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs tyll
16:00:08 <zodbot> Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh tyll
16:00:08 <nirik> #topic init process
16:00:18 <jforbes> .hello jforbes
16:00:20 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:00:29 <kalev> .hello kalev
16:00:30 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:00:34 <tyll> .hello till
16:00:35 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
16:00:54 <maxamillion> .hello maxamillion
16:00:54 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:01:02 <bowlofeggs> .hello2
16:01:03 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
16:01:12 <jsmith> .hello2 jsmith
16:01:13 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:13 <sgallagh> .hello2
16:01:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:33 <nirik> only missing dgilmore. ;)
16:01:44 <stefw> .hello stefw
16:01:45 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
16:02:03 <langdon> .hello2
16:02:04 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
16:02:19 <bowlofeggs> zodbot should exclaim in all caps "WEVE GOT A QUORUM!" when 5 members hello
16:02:31 <nirik> ha
16:02:37 <dgilmore> hi
16:02:39 <nirik> anyhow, lets go ahead and get started.
16:02:47 <nirik> #topic #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy"
16:02:47 <nirik> .fesco 1761
16:02:47 <nirik> https://pagure.io/fesco/issue/1761
16:02:48 <zodbot> nirik: Issue #1761: Update of "Fedora Release Live Cycle" and "Changes / Policy" - fesco - Pagure - https://pagure.io/fesco/issue/1761
16:03:16 <nirik> This was reopened to talk about the string freeze.
16:03:50 <langdon> i have an email about this exact topiic i asked mattdm to review which he ignored :)
16:04:34 <langdon> should i bring it up? or just post to the lists in a week or two? its not critical.. but asks for a new phase before beta freeze
16:04:59 <nirik> I am not really sure we have ever payed much attention to the string freeze... at least in recent years.
16:05:03 <maxamillion> bring it up where? ... here or elsewhere?
16:05:10 <nirik> it's also not super clear whats affected.
16:05:11 <maxamillion> same, I'm relatively ignorant to string freeze ongoings
16:05:18 <langdon> here..
16:05:34 <kalev> me too, I was under the impression that the string freeze was an artifact of some old process that we no longer use
16:05:51 <nirik> the page on the wiki still links to transifex. (which we no longer run)
16:05:51 <jforbes> Right, that has been the discussion, but I am guessing from the fact that there was a thread on trans@ that there is still a need?
16:05:56 <bowlofeggs> it sounds like they just need time to do translations?
16:06:06 <bowlofeggs> and if the strings change that would be "unfun"
16:06:11 <langdon> in f26 i think it was marked as "translation"
16:06:16 <nirik> They mention documentation, but not sure how that works with the new docs site.
16:06:18 <jforbes> Well, that was the purpose
16:06:23 <kalev> what projects does that affect? anaconda and docs?
16:06:29 <nirik> https://fedoraproject.org/wiki/L10N_Freezes#string_freeze
16:07:05 <jsmith> Right -- I think it's to avoid churn with translations in anaconda and any packaged/included release notes
16:07:13 <dgilmore> we have kinda ignored string freeze for at least 5 years, probably more
16:07:17 <bowlofeggs> yeah makes sense to me
16:07:23 <jsmith> Obviously the docs on the docs website can churn independent of the release...
16:07:29 * langdon having read the whole ticket now, realizes his stuff is about the topic in general not specifically string freeze
16:07:47 <dgilmore> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7VZQFDYE2T5M5CFA5WRIGU342IC3UBKI/
16:08:10 <dgilmore> searching the devel list for string freeze on google, nets me that
16:08:23 <dgilmore> 2011 seems to have been the last announcement for it
16:08:28 <maxamillion> heh
16:08:31 <nirik> https://fedora.zanata.org/version-group/view/main/projects?dswid=9424
16:08:40 <nirik> thats the 'main' fedora related ones.
16:08:44 <bowlofeggs> it didn't sound to me after reading https://lists.fedoraproject.org/archives/list/trans@lists.fedoraproject.org/thread/XVX4YQCN4MVCHBSSNXMAWOFGMNSUAUTR/ that there was a lot of input on the dates for this proposal, but also nobody objected (after ~3 days)
16:09:26 <bowlofeggs> it's hard for me to know if this proposal is enough time, but since there were no objections on that thread, i'm inclined to go with a +1
16:10:02 <bowlofeggs> with an understanding that we can revisit if there is a problem later
16:10:43 <sgallagh> Are we committing to any sort of additional requirements on packagers to avoid string changes here?
16:10:51 <nirik> I'd be ok with those dates, but IMHO it would be nice if it was more clear... ie, a definite list of packages affected, maintainers knowing that they should push an update with translations and when... but perhaps that is known, just not to me.
16:11:29 <jforbes> sgallagh: Those requirements have always been there, it just isn't even announced anymore
16:12:02 <sgallagh> jforbes: Right, but given that we haven't been enforcing them, we should treat this as a new thing
16:12:17 <maxamillion> sgallagh: +1
16:12:33 <nirik> I don't recall seeing any updates around those times saying "updating for translation freeze" or anything.
16:12:54 <bowlofeggs> it's been on every schedule i've seen on fedora in the past 2-3 years, iirc
16:12:57 <dgilmore> nirik: it has been years
16:12:59 <bowlofeggs> but yeah, i guess not enforced?
16:13:24 <dgilmore> its always been on the schedule
16:13:24 <bowlofeggs> i agree it'd be nice if there was a clearly documented list of affected packages
16:13:30 <jforbes> Right, that's my point. This isn't new, this is simply a where do we put it now that there is no alpha
16:13:34 <kalev> is comps affected by the freeze?
16:13:43 <dgilmore> I think when we stoped running transifex it was focussed on less
16:13:45 <nirik> who knows? ;)
16:13:48 <dgilmore> from memory
16:13:53 <dgilmore> kalev: it is
16:14:16 <dgilmore> though I am not sure the last time we pulled in updated translations to comps
16:14:25 <bowlofeggs> since the f26 schedule had this, i'm +1 to the proposal even without clarification on all the things we wonder about (though i'd still like those things clarified)
16:14:41 * nirik has been doing that manually, and I haven't for a while. I had to hook it all up when we moved to pagure, it was all broken.
16:15:23 <tyll> I guess we need to ask the translation team to know which projects are affected - it is probably only everything on install media (at most).
16:15:38 <jsmith> tyll: That's my understanding
16:15:48 <dgilmore> historically the main things were gnome, anaconda and comps
16:16:01 <nirik> it's things we are "upstream" for
16:16:06 <dgilmore> user visible things in a default install that we have some about of control over
16:16:12 <kalev> gnome has its own translation team though
16:16:33 <kalev> and it's own translation freezes etc
16:16:46 <nirik> yep.
16:17:23 <nirik> really those things make more sense upstream....
16:17:33 <nirik> except for things like comps
16:19:04 <nirik> so what do we want to do here?
16:19:14 <kalev> there's a few gnome-aligned projects that are using the fedora translation project on transifex, I believe: packagekit and appstream-glib and such, but they don't follow fedora freezes at all
16:19:17 <nirik> punt and have a discussion on devel over the next week?
16:19:59 <jforbes> I don't really see the need, this is the same as every other schedule, only the dates have changed due to no alpha
16:20:59 <nirik> jforbes: but we havent done anything at all for it for the last N years.
16:21:05 <dgilmore> keep string freeze at the same point?
16:21:19 <dgilmore> do a better job telling the world what it actually means
16:21:28 <jforbes> nirik: And it sounds like we going to not do anything at all on a different date in the schedule now
16:21:29 * nirik isn't in favor of adding things to the schedule that are "this is this thing you ignore and don't do anything with"
16:21:40 <tyll> would a discussion on the translation list maybe make more sense? IMHO they would need to propose what they would like to have and then the (affected) developers could say if that would work for them
16:21:41 <jsmith> nirik: I agree...
16:21:52 <nirik> jforbes: sure, we could... but we could try and make it something we care about again
16:22:06 <jsmith> tyll: Probably that and/or the devel list
16:22:22 <nirik> tyll: perhaps, but I don't think many developers are on there... so not sure where is best
16:22:34 <jforbes> I would agree, but I think we need to perhaps bring up a discussion on the list to discuss what is actually necessary, and look at changing the policy
16:22:48 <jsmith> To me, either it's important and we need to get clarity about what needs to be done by that date, or it's not important, and needs to be dropped from the schedule
16:23:05 <kalev> I think jsmith phrased it well
16:23:18 <bowlofeggs> yeah i could go that way too
16:23:20 <tyll> yes, I agree with jsmith as well
16:23:49 <jsmith> Proposal: Get clarification on the devel and translation lists, and push any decision to next week's meeting.
16:23:50 <jforbes> Current policy in place, we need a date. This ticket doesn't cover changing the policy. I am all for opening a ticket to discuss that policy and do what makes the most sense for Fedora
16:24:16 <jsmith> jforbes: But it doesn't make sense to have a date for something we obviously don't fully understand
16:24:22 <maxamillion> jsmith: +1
16:24:27 <nirik> jsmith: +1
16:24:35 <kalev> jsmith: +1
16:24:36 <jsmith> jforbes: Otherwise, Octember 32nd is as good a date as anything...
16:24:44 <tyll> how about we just drop the string freeze for now from the schedule and revisit when we get an actual proposal to discuss? Not sure that there will be one in just a week
16:25:07 <jforbes> https://fedoraproject.org/wiki/L10N_Freezes#string_freeze is the understanding
16:25:49 <jforbes> I am not arguing that it shouldn't go away. I am arguing that we need to open an issue and discuss changing that policy
16:26:15 <nirik> well, that page links to a list of modules in transifex that we no longer have. ;)
16:26:52 <jforbes> We certainly don't have anyone here who can represent the translation group in a way that we can make an educated decision right now, and won't next week if the ticket discussing it is on schedule, and not on string freeze policy
16:26:52 <nirik> but sure we could do a new one on policy, but I would defer this one until after that one is done...
16:27:01 <jsmith> I don't feel comfortable just dropping the date without understanding the impact it might have on the policy (or if it's even relevant)
16:27:03 <jforbes> Yes, that makes sense to me
16:27:23 <dgilmore> +1
16:27:29 <bowlofeggs> jsmith: +1
16:28:44 <nirik> proposal: file new ticket on updating the translation policy, make that block the dates/schedule ticket, ask trans and devel for thoughts on new policy, revisit when policy is proposed?
16:28:57 <jforbes> nirik: +1
16:29:02 <tyll> +1
16:29:03 <kalev> +1
16:30:21 <nirik> other votes?
16:30:25 <bowlofeggs> nirik: +1
16:30:30 <jsmith> +1
16:30:33 * nirik is +1 to his own proposal
16:30:43 <jsmith> Sounds very reasonable :-)
16:31:25 <nirik> #agreed file new ticket on updating the translation policy, make that block the dates/schedule ticket, ask trans and devel for thoughts on new policy, revisit when policy is proposed (+6,0,0)
16:31:38 <nirik> I can file the ticket. Can someone start discussion on devel/trans?
16:31:46 <nirik> #action nirik to file new ticket
16:31:52 <maxamillion> bah, sorry
16:32:28 <nirik> anyone? buller? ;)
16:32:32 <bowlofeggs> nirik: i'll start the discussion
16:32:35 <dgilmore> +1
16:32:47 <nirik> bowlofeggs: thanks
16:33:01 <nirik> #action bowlofeggs to start discussion on lists
16:33:08 <nirik> #topic #1774 Treat Developer-only Stream for Fedora Atomic Host as
16:33:09 <nirik> non-Released Fedora artifacts
16:33:09 <nirik> .fesco 1774
16:33:09 <nirik> https://pagure.io/fesco/issue/1774
16:33:10 <zodbot> nirik: Issue #1774: Treat Developer-only Stream for Fedora Atomic Host as non-Released Fedora artifacts - fesco - Pagure - https://pagure.io/fesco/issue/1774
16:33:30 <nirik> we lost quorum last week here...
16:33:35 <maxamillion> oh right
16:33:42 <nirik> the last proposal was:
16:33:49 <nirik> proposal: ask for feedback from infra (re resources/load) and legal (re: keeping srpms that the ostrees were built from)
16:33:58 <maxamillion> nirik: +1
16:34:02 <tyll> +1
16:34:04 <jsmith> +1
16:34:05 <kalev> +1
16:34:06 <nirik> stefw: already heard back from legal...
16:34:34 <jsmith> And for the record, I was +1 in the ticket before, but I'm not sure my +1 got counted... anyhoo -- sounds like we probably have enough votes now
16:34:42 <dgilmore> It is not clear to me what problems it is avoinding
16:34:45 <dgilmore> avoiding
16:35:01 <dgilmore> why we can not do what they want with what we have
16:35:09 <jforbes> +1
16:35:24 <jforbes> dgilmore: I think they are trying to limit storage usage longer term
16:35:50 <nirik> stefw: I don't think I saw the infra one, can you resend or file a infra ticket on it?
16:35:58 <dgilmore> jforbes: sure, but I do not see how this will have impact
16:36:07 <dgilmore> we would still need to store the bits the same
16:36:16 <dgilmore> regardless of where it is built
16:36:30 <nirik> I think they want to move more rapidly to test things out?
16:36:42 <jforbes> dgilmore: From the way I read this, things will not be archived
16:36:57 <dgilmore> nirik: sure, but we can do that in Fedora
16:37:26 <jforbes> So, koji cleans out scratch builds after some time, but it archives everything we ever ship. I read this as they don't want to archive anything in this stream
16:37:27 <nirik> dgilmore: I don't disagree. ;)
16:37:50 <nirik> no archives, updating many times a day, not signed with 'official' keys...
16:37:51 <dgilmore> I want to know what problems that are being resolved
16:38:01 <tyll> AFAIU they want to build ostree images several times a day but only keep the source rpms for the trees and not archive the ostree images/snapshots
16:38:10 <dgilmore> all things we could do with what we have
16:38:36 <dgilmore> tyll: things we can do without reinventing the wheel
16:38:37 <nirik> stefw: you around? I guess you got called away...
16:39:27 <jforbes> There is an issue with all of this, in that they don't seem to be capable of building signed secureboot packages for those few packages that matter, though I am not sure it should be opened up to this either
16:39:46 <maxamillion> jforbes: fair observation
16:40:41 <nirik> so how about new proposal:
16:40:43 <tyll> dgilmore: afaiu the ticket is not about technical implementation details but more about whether to allow producing semi-released content
16:41:52 <dgilmore> tyll: doing all that within fedora would not need any kind of waiver
16:41:56 <dgilmore> we could just do it
16:41:59 <nirik> proposal: ask for feedback from releng (who may just be able to do all this as needed), infra and legal (already acked).
16:42:09 <dgilmore> tyll: so I have to assume they want to do it some other way
16:42:42 <dgilmore> tyll: and given the mention of content generators I have to assume they mean external to koji
16:42:56 <jsmith> nirik: +1
16:42:59 <dgilmore> which I do not want to give permission to build rpms in two different ways
16:43:15 <dgilmore> if we are going to change how we build rpms we should do it for all rpm builds
16:43:41 <dgilmore> nirik: sure
16:43:51 <maxamillion> nirik: +1
16:43:52 <bowlofeggs> nirik: +1
16:44:02 <jforbes> nirik: +1
16:44:09 <tyll> nirik: +1
16:45:14 <sgallagh> +1
16:45:33 <kalev> nirik: +1
16:45:34 <tyll> dgilmore: your objection sounds reasonable. Maybe they just do not know that they could do it in the existing infrastructure. Unfortunately the docs talk not about motiviation more about what is required/allowed afaics
16:45:52 <nirik> #agreed ask for feedback from releng (who may just be able to do all this as needed), infra and legal (already acked). (+8,0,0)
16:46:08 <nirik> #topic #1775 f27 modular server release planning
16:46:08 <nirik> .fesco 1775
16:46:08 <nirik> https://pagure.io/fesco/issue/1775
16:46:11 <zodbot> nirik: Issue #1775: f27 modular server release planning - fesco - Pagure - https://pagure.io/fesco/issue/1775
16:46:50 <dgilmore> so this is a new product and needs its own release schedule
16:46:56 <maxamillion> I guess I don't really understand what this needs from FESCo
16:46:57 <nirik> so, there's a proposed schedule from langdon
16:47:05 <maxamillion> just an ack on schedule?
16:47:13 <langdon> thats what i was looking for
16:47:17 <dgilmore> I have pulled in two RHEL releng people to ensure that the releng side can be handled
16:47:51 <nirik> dgilmore: normally that wouldn't work, but modularity should be able to pull in exactly the things it needs, so I think it's actually possible to do another schedule
16:47:53 <langdon> maxamillion: kinda like using fesco as the "coordinator" for all the teams involved.. which is mean, i know, but :)
16:48:14 <jsmith> langdon: Gee, thanks... I think.
16:48:17 <langdon> ha
16:48:41 <langdon> coordinator is too strong a word.. im trying to do that.. more like "placeholder" for everyone to pipe in
16:49:08 <bowlofeggs> so we just need to vote on https://fedoraproject.org/wiki/User:Langdon/Proposed_Modular_Server_Release ?
16:49:08 <nirik> the schedule seems fine to me, but with out fedora delays it might even align with the fedora milestones again. ;)
16:49:19 <langdon> nirik: :)
16:49:22 <jsmith> nirik: :-)
16:49:34 <sgallagh> I really hope that isn't the case
16:49:40 <langdon> bowlofeggs: and raise any other issues u all can think of
16:49:46 <jsmith> I guess I'm +1 for the proposal as it stands... but I'll admit I don't pretend to be following all the details.
16:50:00 <langdon> free-ipa being non-blocking makes release much more likely for the rest
16:50:24 <bowlofeggs> i am also +1 on the proposal but also don't know all the details (except that i know bodhi needs a patch finished and released and deployed)
16:50:29 <dgilmore> -1 to the schdule, it has Beta next Tuesday
16:50:34 <dgilmore> for the rain date
16:50:39 <langdon> jsmith: there will be plenty of opportunities to raise flags later.. im just looking for.. does this make sense to everyone, until the next fire hits?
16:51:08 <sgallagh> dgilmore: The schedule page has a mishmash of stuff from the regular schedule
16:51:17 <sgallagh> langdon: Could you cut the non-Modular stuff out of there to avoid confusion
16:51:18 <langdon> dgilmore: sorry.. i didn't update the sched with the change to the real sched
16:51:18 <sgallagh> ?
16:51:22 <langdon> uggh
16:51:25 <dgilmore> langdon: So I think I would rather see an entirely new clean schedule without Traditional milestones in it
16:51:34 <langdon> ack.. will fix now
16:51:58 <dgilmore> langdon: just a schedule for the F27 Modular release all by itself
16:52:25 <langdon> yeah.. doing that.. i just had them together to make it obvious if one impacted the other.. maybe it doesn't matter
16:52:30 <nirik> yeah, on the one hand it's nice to see the other dates, but it's also confusing.
16:52:37 <bowlofeggs> langdon: i will say that the current schedule for bodhi to have module mashing is oct 09, which is pretty close to the beta go/no-go. i don't think that's necessarily a problem, but it's cutting real close
16:52:50 <dgilmore> langdon: having a third schedule with both would be awesome
16:53:16 <dgilmore> but for the purposes of evaluating the modular release it should stand on its own
16:53:33 <langdon> dgilmore: i just didn't get a chance to update post the go/no-go yesterday.. jkurik even pinged me..
16:53:41 <langdon> hit f5 y'all
16:53:56 <maxamillion> ctrl+r you heathen
16:54:02 <maxamillion> >.>
16:54:07 <bowlofeggs> actually, does releasing the bodhi that can mash modules just 3 days before beta go/no-go enough time for beta go/no-go testers to give feedback about whether updates work?
16:54:09 <langdon> :)
16:54:40 <maxamillion> bowlofeggs: it's a narrow window, but if the people on the hook for the testing are fine with it, I'd be alright with it
16:55:03 <dgilmore> langdon: my only concern is Thanksgiving
16:55:05 <maxamillion> langdon: is there a commitment from people to test already or is the modularity team going to hope the QA team can come up with cycles?
16:55:15 <langdon> bowlofeggs: i don't know.. i wil have to ask QA. I think I can provide people to test it in the window, but QA should also have a comment
16:55:54 <sgallagh> maxamillion: Modularity teams will have to help
16:55:55 <langdon> maxamillion: some, we are still working through with them, what to test.. so, they are aware and have some idea of what to test and some agreement .. but i wouldn't call it done
16:55:57 <dgilmore> langdon: we would need to stage etc during thanksgiving
16:56:06 <maxamillion> because "QA will do it" without QA coming in and saying "yeah, we're good ... we'll do it" is going to make a hard pass from my end
16:56:18 <langdon> dgilmore: i thought we fixed that with nirik.. nirik?
16:56:24 <sgallagh> dgilmore: The schedule was designed around not having to do that... did we miss something?
16:56:38 <sgallagh> The idea was that we would stage ahead of time but not unlock it until the following Tuesday
16:56:39 <langdon> is kparal around?
16:56:43 <maxamillion> langdon: alright, do we have a drop-dead date for that stuff? like, if these things aren't in we're going to push the schedule out?
16:56:54 <nirik> yeah, I thought we were not needing any thanksgiving week aside from possibly a release on tuesday
16:57:20 <langdon> maxamillion: i would say beta go/no-go would be definitive.. like that is one of the decision points for that meeting
16:57:34 <dgilmore> sgallagh: working off the release date yes
16:57:42 <maxamillion> langdon: +1
16:57:49 <dgilmore> sgallagh: the release date and the go no go do not match up
16:58:21 <langdon> dgilmore: how so?
16:58:24 <nirik> dgilmore: thats due to thanksgiving.
16:58:36 <langdon> ohh.. right.. yeah.. what nirik said
16:58:37 <dgilmore> go no go on November 16 would give us a ship date of november 21 not november 28
16:58:50 <langdon> dgilmore: but we wanted to skip t-day week
16:59:00 <sgallagh> dgilmore: That's what I was just trying to explain. Just because the bits are ready doesn't mean we have to announce them.
16:59:10 <bowlofeggs> thanksgiving is nov 23
16:59:41 <langdon> https://www.timeanddate.com/calendar/ for anyone else cal challenged like me
16:59:41 <bowlofeggs> so the gap from 11/30 to 12/12 probably isn't needed
16:59:51 <dgilmore> I believe it will cause confusion if we sat on it
16:59:53 <nirik> bowlofeggs: it 100% is
16:59:58 <bowlofeggs> but the gap from 11/16 to 11/28 makes sense
17:00:03 <sgallagh> bowlofeggs: That was due to an infra situation
17:00:04 <langdon> bowlofeggs: that is due to hardware changeover
17:00:07 <dgilmore> it really does not
17:00:10 <bowlofeggs> nirik: ooooh. right.
17:00:12 <bowlofeggs> sorry
17:00:24 <nirik> infrastructure is moving all our machines in phx2 on week of dec 4th
17:00:29 <langdon> dgilmore: we don't want to announce during the week of t-day.. whether the stuff is there or not
17:00:34 <nirik> so there may well be outages that week.
17:00:37 <langdon> s/stuff/bits
17:00:38 <nirik> so we want to avoid that
17:01:21 <bowlofeggs> might be good to write that on the schedule, just to have the info handy
17:01:23 <dgilmore> langdon: it will cause a ton of confusion
17:01:27 * nirik personally would be ok with a release on the 21st, but others wanted to avoid it
17:01:40 <jforbes> I don't think that it would cause confusion
17:01:43 <dgilmore> as users are used to the go announcement and the release on the following tuesday
17:02:02 * dgilmore thinks we should release on the 21st
17:02:03 <langdon> bowlofeggs: i was just thinking of putting in both.. like a "modular key dates" and an "all of fedora key dates" ..
17:02:17 <nirik> langdon: that would be great
17:02:53 <dgilmore> I am fine with the Beta dates
17:02:54 <langdon> dgilmore: i say .. let's ask marketing.. then i can punt having to wrestle with you ;)
17:02:57 * maxamillion has to step afk for a moment
17:03:03 <dgilmore> I think the Final dates are wonky
17:03:14 <dgilmore> langdon: :D
17:03:43 * dgilmore will note one of the releng people on modular server is in Brno
17:03:59 <dgilmore> so there will be people working on thanksgiving on the releng side
17:04:14 * nirik should be around on the infra side...
17:04:31 <dgilmore> nirik: well puiterwijk and pingou will be anyway :D
17:04:42 <dgilmore> and probaly someone I forgot
17:04:43 <langdon> dgilmore: i suspect we may have more suppport than us americans are used to in software.. but.. fear
17:05:09 * dgilmore notes he just lives in the us and is not one :D
17:05:14 <dgilmore> langdon: but sure
17:05:18 <nirik> well, it's just release... the go was the week before and the staging the bits.
17:05:28 <langdon> what if we modified it to be "release date" =  21.. but we can hold the market release til the followiing week..
17:05:35 <nirik> it's all pretty much on infra to make sure the bits go out smoothly
17:05:58 <dgilmore> langdon: soft launch and hard launch
17:06:06 <langdon> right.. i think we have a "release available" on 21 either way.. but announce on 28.. which we don't normally put in the schedule
17:06:08 <langdon> exactly
17:06:16 <langdon> dgilmore: exactly
17:06:26 <dgilmore> that I am fine with
17:06:37 <nirik> sure, whatever works.
17:06:50 <kalev> sure
17:06:54 <langdon> if this isn't a "set in stone" format of a thing, ill just put it all in there.. i was just trying to follow jkuriks version
17:07:10 <nirik> anyhow, shall we vote on the schedule then? or more discussion?
17:07:21 <bowlofeggs> i'm good 2 vote
17:07:22 <dgilmore> nirik: how would any slips affect infra
17:07:41 <nirik> as long as we avoid that week of dec 4th we should be ok
17:08:03 <dgilmore> so any slips beyond the rain date could push things into 2018
17:08:04 <bowlofeggs> note that the end of december is also a week to avoid, so slips could end up there
17:08:25 <langdon> yes.. im nervous about that too
17:08:31 <nirik> yeah... 19th I guess would still be possible...
17:08:39 <dgilmore> given getting fixes done the week of the 4th may be hard,
17:08:43 <langdon> i think we would cut content rather than miss the date.. at least that is my opinion
17:08:46 <nirik> but after that, doomed until 2nd
17:08:54 <bowlofeggs> i do still feel concerned about the beta go/no-go 3 days after bodhi's ability to do modules - seems like no-go could be a realistic chance that week
17:08:54 <dgilmore> we then run into christmas
17:09:45 <langdon> bowlofeggs: i think you are really arguing for still doing a proper test in stg
17:10:06 <bowlofeggs> langdon: well that would certainly be nice :)
17:10:15 <nirik> well, we can always look more if it slips later...
17:10:21 <bowlofeggs> yeah
17:10:39 <bowlofeggs> i'm a +1 to the schedule though, my concern aside
17:10:53 * nirik is +1 to the schedule as we have discussed
17:11:03 * kalev is +1 as well
17:11:04 <jforbes> +1 here
17:11:19 <sgallagh> I'm +1
17:11:35 <langdon> and, thoughts on changing the format of the schedule to include like "marketing release" or is this a table everyone "knows how to read"?
17:11:38 <dgilmore> I am +1 with hard and soft launches added in
17:11:46 <jsmith> I'm +1
17:11:50 <langdon> and/or crashes into your first ticket of the meeting
17:12:03 <tyll> +1
17:12:30 <dgilmore> langdon: I have some things I want to follow up with you later on as well
17:12:32 <nirik> maxamillion: ^
17:12:36 <dgilmore> but its off toic for this
17:13:00 <bowlofeggs> maxamillion said he needed to AFK a bit ago
17:13:05 <nirik> ah, ok.
17:13:07 <nirik> #agreed modular server release schedule is approved (+8,0,0)
17:13:13 <nirik> anything else on this ticket?
17:13:24 <tyll> langdon: I am always for making everything explicit so newcomers can understand it as well
17:13:42 <nirik> tyll: +1
17:13:48 <bowlofeggs> nirik: that might just be a +7 on the last vote
17:13:57 <dgilmore> tyll++
17:13:58 <zodbot> dgilmore: Karma for till changed to 4 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:14:09 <langdon> tyll: yeah.. you just run in to "it confuses people because it doesn't look like it used too" .. thats what i was x-checking
17:14:27 <nirik> bowlofeggs: I think it's 8, just missing maxamillion ?
17:15:11 <bowlofeggs> nirik: oh right
17:15:18 <nirik> #topic #1776 F28 System Wide Change: Deprecate TCP wrappers
17:15:18 <nirik> .fesco 1776
17:15:18 <nirik> https://pagure.io/fesco/issue/1776
17:15:19 <zodbot> nirik: Issue #1776: F28 System Wide Change: Deprecate TCP wrappers - fesco - Pagure - https://pagure.io/fesco/issue/1776
17:15:19 <bowlofeggs> nirik: for some reason i thought there were 8 of us, not 9
17:15:21 <bowlofeggs> ugh
17:15:22 <bowlofeggs> hahaha
17:15:33 <langdon> just to close this out.. ill update my version and then ask jkurik to make it "real"?
17:15:39 <nirik> langdon: thanks!
17:15:48 <sgallagh> langdon: ack
17:15:52 <langdon> thanks all
17:16:14 <bowlofeggs> this tcp wrappers thing seems a bit contentious on devel@
17:16:44 <dgilmore> I thought they were deprecated years ago
17:16:46 <sgallagh> So tcp_wrappers. I agree that it's of limited use today, but unfortunately lots of software (both "in" and "on" Fedora) still uses it
17:17:22 <dgilmore> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7HN72XRG2NU7Y4PZS4O2W3AWPXETQDFQ/
17:17:24 <sgallagh> At minimum, I will -1 removing it from the distro
17:18:00 <dgilmore> I think at this point i am +1 to removing from Fedora
17:18:44 <nirik> is upstream dead/not fixing things?
17:20:30 <dgilmore> last stable release was 1997
17:20:33 <jforbes> I am -1 to removing from fedora. I am all for encouraging the removal of deps on it form services, but I don't think we can force that in the F28 timeframe
17:20:36 <dgilmore> https://en.wikipedia.org/wiki/TCP_Wrapper
17:21:03 <nirik> yeah, pretty old...
17:21:07 <dgilmore> If we remove deps for say vsftpd, users may think it will work when in reality it will not
17:21:17 <dgilmore> either we remove it or fully support it
17:21:35 <maxamillion> do we have a list of what packages would be affected by this change?
17:21:57 <maxamillion> ultimately I'd just like to make sure we handle the migration well ... I don't exactly care about time frame or tcpwrappers themselves
17:22:13 <bowlofeggs> it sounds like denyhosts and fail2ban might use it
17:22:16 <bowlofeggs> based on wikipedia...
17:22:29 <sgallagh> fail2ban-hostsdeny prelude-manager quota
17:22:35 <nirik> sshd
17:22:37 <jforbes> Right, that was my point, I don't think that we can handle the migration well within the F28 timeframe
17:22:39 <kalev> this might fall to the Server WG territory: do we have their opinion what to do?
17:22:41 <sgallagh> According to `dnf repoquery --whatrequires tcp_wrappers`
17:22:58 <maxamillion> nirik: sshd?
17:23:08 <dgilmore> https://paste.fedoraproject.org/
17:23:10 <dgilmore> quite a lot
17:23:17 <tyll> the change proposal is from the current admin of the tcp_wrappers pkg, so it would probably also require a new maintainer if it should be kept
17:23:18 <nirik> yes, it can use tcp_wrappers
17:23:30 <maxamillion> dgilmore: think you were going for something else with that url paste/
17:23:32 <maxamillion> ?*
17:23:45 <maxamillion> nirik: gotchya
17:23:48 <dgilmore> maxamillion: helps if i hit submit first
17:23:49 <sgallagh> https://paste.fedoraproject.org/paste/faLBNFJSJ1vVwonZhdXWgQ
17:23:52 <maxamillion> nirik: I mean, can't anything really?
17:23:57 <dgilmore> quite a lot https://paste.fedoraproject.org/paste/-DXlZxO6ZNNPhgVgqnNB0g
17:24:02 <sgallagh> That's the list of what requires tcp_wrappers-libs
17:24:09 <maxamillion> dgilmore: how'd you query that?
17:24:17 <maxamillion> ah, nvm
17:24:19 <maxamillion> sgallagh: thanks
17:24:20 <maxamillion> hrm
17:24:21 <maxamillion> alright
17:24:23 <dgilmore> maxamillion: dnf repoquery it is in the paste
17:24:38 <maxamillion> dgilmore: ah, it sure is
17:24:39 <maxamillion> *sigh*
17:24:43 <maxamillion> I can't grok today
17:24:52 <bowlofeggs> i agree that F28 is too soon
17:25:11 <maxamillion> yeah, I'm -1 until we can get a migration plan in place and execute it
17:25:15 <bowlofeggs> i also like kalev's suggestion to ask the server WG
17:25:55 <sgallagh> I'll propose that we accept this as an F29 Change and ask that people try to wean off of it as fast as possible in F28, with the expectation that we kill the tcp_wrappers package in F29
17:26:11 <jforbes> I would be okay with that
17:26:20 <nirik> ie, start the work in f28/now... deadline f29
17:26:25 <sgallagh> yes
17:26:25 <bowlofeggs> sgallagh: +1, but can we also solicit feedback from server WG?
17:26:36 <dgilmore> +1
17:26:42 <nirik> +1
17:26:54 <maxamillion> +1
17:26:55 <sgallagh> bowlofeggs: nirik and I are the two most active members of that WG, so I'm comfortable with this.
17:27:00 <bowlofeggs> cool
17:27:02 <tyll> is it that much work to remove it? I understood that is is an optional dependency for most packages that could just be removed
17:27:11 <sgallagh> tyll: Unknown
17:27:20 <nirik> tyll: there's likely some upstreams that need to reimplement stuff.
17:27:22 <sgallagh> That's why I'm recommending a longer lead-time
17:27:29 <nirik> some should be easy
17:27:29 <bowlofeggs> some tools probably won't work without it, like denyhosts
17:27:43 <sgallagh> Amendment to my proposal: let's kill the package right after F28 branches and Rawhide becomes F29.
17:27:57 <dgilmore> sgallagh: nak
17:28:04 <nirik> thats pretty soon...
17:28:08 <dgilmore> just because its required by core pieces
17:28:20 <dgilmore> we would likely go awhile without working composes
17:28:28 <sgallagh> Well, if we're going to kill it in F29, don't we *want* it to break to force it to be fixed?
17:28:34 <sgallagh> As soon as possible
17:28:45 <maxamillion> sgallagh: +1
17:28:49 <dgilmore> sgallagh: once anything in the default install, anaconda runtime removed the dep sure
17:28:58 <bowlofeggs> how about: let's revisit this after F28 branches and see where things stand. also, should we ask the submitter to document tickets against each dep that uses it, asking them to switch away or report why they can't?
17:29:26 <dgilmore> sgallagh: I do not want to put dynamite into everything
17:30:02 <maxamillion> light the fuse ;)
17:30:07 <nirik> It's waited this long, not sure we need to be in too much hurry
17:30:19 <sgallagh> If we're going to kill it, let's not make it suffer :)  We all know that legacy stuff will coast forever until something forces the issue
17:30:39 <maxamillion> sgallagh: I agree
17:30:58 <maxamillion> that's my fear, if we don't draw a line in the sand, it'll just continue coasting along
17:30:58 <sgallagh> So if we're agreed that we want to be rid of it by the end of next year, let's force the issue.
17:31:01 <nirik> it's not fully clear to me what can't just disable this... denyhosts, but are there others?
17:31:58 <tyll> just wondering, what should happen in Rawhide regarding it until f28 branches? Can maintainers already drop support for it? If they do, then it will be a worse communicated change in f27
17:31:59 <nirik> or is even denyhosts the case (I think it has a iptables backend)
17:32:36 <sgallagh> tyll: Sorry, can you rephrase that? I don't quite follow.
17:33:12 <kalev> I didn't follow either
17:33:19 <dgilmore> tyll: dropping in rawhide is fine, however the maintainers would need to take care to ensure they do not backport the change
17:33:47 <tyll> if they drop it in Rawhide now, then the change would be in F28 already
17:33:47 <nirik> proposal: approve change for f28, but ask change owner to report status before f28 branching so we can decide when to fully remove the package...
17:34:06 <dgilmore> either by not merging rawhide into f27, or adding %if 0%{?fedora} <= 027
17:34:07 <dgilmore> etc
17:34:14 <maxamillion> nirik: +1
17:34:17 <bowlofeggs> i think tyll might be suggesting that packages should drop support for this in the same release
17:34:18 <dgilmore> nirik: +1
17:34:30 <bowlofeggs> as opposed to some dropping in f28, and others in f20
17:34:31 <kalev> nirik: +1, that's a good plan to make sure it doesn't break our composes
17:34:32 <bowlofeggs> *f29
17:34:35 <sgallagh> I don't see any reason to disallow people from making this change now
17:34:48 <maxamillion> sgallagh: agreed
17:34:58 <sgallagh> It's a per-application feature, so it's not like saying "hey, this app suddenly isn't honoring the global setting"
17:35:06 <jforbes> People can make the change any time they want.
17:35:18 <nirik> just fyi, openssh is patching it back in, upstream dropped support a while back
17:35:20 <dgilmore> I see one reason to require it all in a single release
17:35:34 <sgallagh> dgilmore: What's that?
17:35:37 <stefw> dgilmore, i had to go to dinner
17:35:48 <stefw> Fedora already give permission to build packages outside of Fedora's infrastructure
17:35:56 <stefw> Fedora has the "Fedora Requirements for CI/CD"
17:36:04 <tyll> but then where is the advantage of making it a F29 feature instead of a F28 feature?
17:36:05 <dgilmore> say vsftpd drops it now. and others don't users may try to use it because they always have and find themselves not protected in a way they thought they were
17:36:05 <jforbes> stefw: but they don't all work :)
17:36:06 <stefw> which explicitly address that: https://fedoraproject.org/wiki/Fedora_requirements_for_CI_and_CD
17:36:28 <stefw> jforbes, you're right not all those packages and mechanisms work yet
17:36:36 <stefw> but the requirements grant that this can be made to work
17:36:38 <maxamillion> wait wait
17:36:41 <jforbes> stefw: they won't work
17:36:43 <tyll> s/feature/system wide change/
17:36:44 <maxamillion> this isn't on topic
17:36:45 <sgallagh> tyll: The F29 feature would be "no longer ship the tcp_wrappers package at all"
17:36:53 <maxamillion> are we done with the tcp_wrappers topic?
17:36:56 <stefw> oh sorry, i thought the meeting was over
17:37:05 <nirik> no, we are on another change.
17:37:06 <maxamillion> (I don't care, I just don't want to have multiple threads of conversation)
17:37:15 <jforbes> right, sorry
17:37:18 <maxamillion> stefw: oh no, this meeting never ends :P
17:37:24 <nirik> ha
17:37:40 * stefw sees if he makes it back after dinner and this is still going on ... will try and cycle back
17:37:49 <nirik> so, I got +3 to my proposal, does anyone have a better one?
17:37:59 <sgallagh> maxamillion: https://www.youtube.com/watch?v=0U2zJOryHKQ
17:38:18 <jforbes> So the proposal is dropping the deps for f28 and dropping the package for f29?
17:38:24 <tyll> sgallagh: afaics the proposal has two options: "After recent discussions I believe it is time to go for this package, if not completely, than at least as a dependency of modern daemons in system by default."
17:38:41 <maxamillion> sgallagh: ha!
17:38:46 <nirik> sgallagh: https://www.youtube.com/watch?v=eh7lp9umG2I
17:39:01 <kalev> does anyone know if the Fedora maintainer is the same as in RHEL? so that we aren't pulling the rug out from under RHEL here by dropping it too early (in F28)
17:39:07 <sgallagh> jforbes: Well, my proposal is "announce right now that we will be dropping the package at the F28/F29 split", so they can patch their packages ahead of time.
17:39:19 <bowlofeggs> i think i would like this change to document tickets against dependent packages telling them to switch away
17:39:33 <bowlofeggs> and that would also give us a list of packages that ship in a default install
17:39:46 <bowlofeggs> so we can know if a default install is ready to not ship it
17:39:48 <jforbes> sgallagh: Right, I agreed to that, I thought you ammended to change it to F28
17:40:25 <nirik> bowlofeggs: +1
17:40:48 <sgallagh> jforbes: No
17:41:07 <jforbes> then my agreement stands from before
17:41:33 <bowlofeggs> i think i'm +1 to nirik's proposal, with an amendment that the change proposer needs to file tickets on dependent packages and link those tickets in the change
17:41:34 <sgallagh> jforbes: My amendment was "Kill the package in F29 immediately after F28 branches off"
17:41:43 <sgallagh> I may not have phrased it well enough
17:41:47 <nirik> I think we have two camps here... one that is fine saying we drop it at f28 branching, one that wants more info on what else would get dropped before that.
17:41:55 <jforbes> Oh, it was nirik who moved it to f28
17:41:56 <jsmith> nirik: I guess I'm in that second camp
17:42:01 <dgilmore> it has the same RHEL owner
17:42:14 <kalev> then I say dropping it in F28 is fine
17:42:49 <kalev> with the caveat of course that it doesn't break composes etc
17:43:12 <bowlofeggs> yeah i think we'll just need to revisit it before F28 branch time to see how those tickets i proposed look
17:43:41 <sgallagh> kalev: *in* F28, or in F29 after F28 branches?
17:43:44 <bowlofeggs> and i guess some tickets will be more important to us than others (i.e., if they are part of a compose)
17:43:50 <nirik> proposal: approve change, ask that they file a tracking bug
17:43:59 <bowlofeggs> nirik: +1
17:44:06 <nirik> we have a number of milestones where we check on changes...
17:44:06 <jsmith> nirik: +1
17:44:07 <maxamillion> nirik: +1
17:44:11 <tyll> nirik: +1
17:44:14 <dgilmore> kalev: just kicking it out will break composes
17:44:20 * kalev nods.
17:44:20 <dgilmore> and installs
17:44:24 <nirik> if we don't like things we can bring it up there and revisit
17:44:35 <nirik> yeah, right now it would completely break composes.
17:44:47 <nirik> more votes?
17:44:50 <jforbes> I still like sgallagh's proposal
17:44:56 <kalev> sgallagh: I was thinking it should be ok to drop it *in* F28 if it's coordinated with the RHEL maintainer
17:45:17 <dgilmore> jforbes: remove it from rawhide after f28 branches?
17:45:34 <jforbes> Yes, so the change itself is actually deferred to F29
17:45:42 <kalev> nirik: +1
17:45:44 <dgilmore> jforbes: I have issues with that
17:45:55 <maxamillion> dgilmore: why so>
17:45:57 <maxamillion> ?*
17:46:10 <dgilmore> jforbes: only because the amount of effort needed to unbreak things so we get composes is unkown
17:46:17 <nirik> thats +6 for that proposal, but I'd like everyone to be happy. ;)
17:46:45 <jforbes> dgilmore: Sure, it's unknown at any point, but at least people have time to act
17:46:48 <sgallagh> dgilmore: That's why I was proposing that we do it in F29 but announce it now
17:46:55 <sgallagh> And possibly repeatedly before we drop it
17:47:23 <nirik> if it's not ready to drop in f28, we could punt it later to f29
17:47:29 <sgallagh> I'm 0 for the nirik's proposal. I'm fine if we want to attempt it, but I think that without killing it early, nothing will happen
17:47:48 <nirik> that seems backwards to me.
17:48:01 <sgallagh> Sure, doesn't mean it's not true :)
17:48:10 <nirik> we should remove all the uses of it, then removing it will be safe. We shouldn't remove it and fix things that break
17:48:17 <dgilmore> sgallagh: if the maintainer is motivated he will make it happen
17:48:41 <maxamillion> nirik: +1
17:48:59 <jforbes> I am -1, I think a deprecation should be communicated well in advance. We have a decently long dep list here, and I would like to see it go smoothly. I can understand if I am outvoted though
17:49:44 <dgilmore> https://www.youtube.com/watch?v=dQw4w9WgXcQ
17:49:57 <nirik> well, people have from now until feb 20th (branching f28) right?
17:50:13 <dgilmore> sure
17:50:20 <bowlofeggs> that's ~5 months
17:50:31 <nirik> granted with holidays it's less.
17:50:33 <jforbes> Somewhat, taking holidays and such into consideration.
17:50:34 <bowlofeggs> true
17:51:07 <jforbes> Anyway, no need to hold up for me, it has to votes to pass
17:51:16 <bowlofeggs> what if we did nirik's proposal, but s/28/29/ ?
17:51:19 <nirik> ok. :(
17:51:45 <bowlofeggs> gives people more time and also doesn't pull rugs out
17:51:46 <nirik> bowlofeggs: would that prohibit them from making the change now?
17:51:58 <jforbes> nirik: nothing
17:52:01 <kalev> I'd like to make sure this is properly coordinated with RHEL and base the 28 or 29 decision on that if possible
17:52:05 <bowlofeggs> nirik: yeah i guess that's another angle on it, to tyll's point
17:52:08 <sgallagh> nirik: Shouldn't prohibit the consumers of tcp_wrappers from changing
17:52:12 <jforbes> people can make the change tomorrow.
17:52:22 <maxamillion> kalev: is that really our concern as FESCo?
17:52:23 <dgilmore> nirik: for me, making the change now can mess up users
17:52:38 <kalev> maxamillion: sure, who else's concern is it if not ours?
17:52:40 <sgallagh> dgilmore: Which change?
17:52:51 <nirik> so, say they make the change to all the packages and retire tcp_wrappers before feb... we would still want this to be a f29 change?
17:52:56 <sgallagh> Dropping the package or changing the consumers?
17:52:57 <maxamillion> I'm worried about our users, but I think nirik's proposal handles it well and gives room to re-eval later if needed
17:53:01 <dgilmore> sgallagh: I have itterated my concerns twice already
17:53:49 <sgallagh> dgilmore: You have said that dropping the package outright would break composes. I get that and am not suggesting we do that *right now*
17:53:56 <jforbes> nirik: if everyone is off by then, by all means, kill it.  I think you are much more optimistic than I am
17:54:03 <dgilmore> sgallagh: I have said more than that
17:54:35 <tyll> to communicate it properly to users it should be a F28 change (at least) otherwise some packages will loose support for it in F28 without it being properly communicated to the users
17:54:35 <nirik> jforbes: :) could be... but if they also fail to move all packages off by f28, it will hit the contingency plan and move to f29...
17:54:48 <dgilmore> sgallagh: 17:21 < dgilmore> If we remove deps for say vsftpd, users may think it will work when in reality it will not                                                                              Astranox
17:54:51 <sgallagh> dgilmore: Ah, I missed the vsftpd example. Sorry wall of text
17:54:52 <dgilmore> 17:21 < dgilmore> either we remove it or fully support it
17:54:55 <sgallagh> Yeah, I see that now.
17:55:04 <nirik> or sshd or anything that uses it now.
17:55:10 <dgilmore> right
17:55:13 <jforbes> So the concern is that users don't know that they are no longer protected by tcp_wrappers. which could still happen at any time, we never forbade the dep removal, how many have changed already?
17:55:14 <bowlofeggs> yeah i agree that could be confusing for users
17:55:22 <dgilmore> leave it in or take it out
17:55:23 <bowlofeggs> and if users think it's working and it isn't, that seems bad
17:55:35 <nirik> jforbes: no idea.
17:55:49 <nirik> additionally, I think ssh dropped it and then readded it at one point.
17:56:02 <sgallagh> So do we advocate for consumers to change to a Recommends: based solution?
17:56:11 <jforbes> clearly sshd dropped it upstream, people noticed, and it got put back in, but I am guessing they are not the only package.
17:56:13 <sgallagh> If it's there on the system, use it, otherwise don't?
17:56:29 <nirik> in the ideal world, someone would write a tcp_wrappers replacement that just denys everything and sends back a 'DONT USE THIS' to the calling program. ;)
17:56:30 <jforbes> sgallagh: I don't see how that would work
17:56:35 <sgallagh> jforbes: A quick google search indicated that there's a LOT of cargo-cult documentation that describes using tcp_wrappers
17:56:40 <sgallagh> Some written as recently as last year
17:57:21 <sgallagh> jforbes: Yeah, it probably wouldn't. I was kind of doing an argument by absurdity there.
17:57:23 <smooge> some of it is tied into various security guides that people have to use until year N
17:57:47 <nirik> well, I guess we should just take that one approved proposal and move on? or does anyone want to change votes?
17:58:04 * sgallagh remains 0 here
17:58:09 * maxamillion is still +1
17:58:28 * kalev is still +1 to nirik's proposal above
17:58:40 <maxamillion> sgallagh: yeah, the iproute2 migration took like 14 years longer than it should have too
17:58:50 <sgallagh> maxamillion: And still going!
17:58:54 <maxamillion> sgallagh: yerp
17:59:05 <nirik> proposed: approve change for f28, ask that they file a tracking bug with packages using tcp_wrappers and progress dropping that dependency
17:59:25 <maxamillion> sgallagh: we're also about 10 years into the python3 migration .... there's a trend here
17:59:29 <nirik> ss > netstat! :)
17:59:33 <kalev> +1
17:59:40 <maxamillion> nirik: +1 to proposal and +1 to ss
17:59:45 <nirik> +1 my own proposal
17:59:49 <tyll> +1
17:59:53 <bowlofeggs> i'm still +1 to nirik's proposal, but would be happy to hear other proposals that people think could get more than +6 :)
17:59:55 <dgilmore> +1
18:00:15 <sgallagh> With the concerns about user-uncertainty, I can be a weak +1 here, I suppose
18:00:40 <sgallagh> But I'm concerned that this will still be a problem when we get to F28 Beta and half the world has moved and half has not
18:01:01 <dgilmore> we likely should put in a hosts.deny and hosts.allow file that explains its been removed
18:01:21 <nirik> jforbes: still -1? jsmith: vote?
18:01:23 <jforbes> It will. The  way a deprecation works is exactly that. Communication to users should happen with F28
18:01:25 <maxamillion> dgilmore: +1 I like that, just like we did for inittab
18:01:29 <jforbes> nirik: I am still -1
18:01:58 <tyll> we can still communicate that people shouldnot rely on it
18:02:12 <tyll> even if tools.might support it
18:02:18 <jforbes> tyll: I think it not existing is communication
18:02:30 <nirik> #agreed approve change for f28, ask that they file a tracking bug with packages using tcp_wrappers and progress dropping that dependency (+7,-1,0)
18:02:48 <nirik> dgilmore: yeah, might be a good suggestion to add to the change owner
18:02:49 <maxamillion> we can try to make some noise about it though, CommBlog and twitter and such
18:03:00 <jforbes> Please do
18:03:00 <nirik> last ticket:
18:03:05 <nirik> #topic #1714 Fedora 26 spins process was missed
18:03:05 <nirik> .fesco 1714
18:03:05 <nirik> https://pagure.io/fesco/issue/1714
18:03:07 <zodbot> nirik: Issue #1714: Fedora 26 spins process was missed - fesco - Pagure - https://pagure.io/fesco/issue/1714
18:03:52 <dgilmore> spins process has not fully been followed in years :(
18:03:54 <nirik> some history: Orig the spins-sig handled stuff about spins... then they became defunct
18:04:06 <nirik> so, it's devolved onto fesco
18:04:21 <dgilmore> it really needs a person commited to doing the work and following up to ensure testing etc happens
18:04:47 <kalev> for a long while cwickert was that person, but sadly he's no longer involved :(
18:04:53 <nirik> dgilmore: well, if it's under fesco now, it needs to be added to ths schedule jkurk keeps and we need to address things as the schedule dictates
18:05:10 <jforbes> nirik: agreed
18:05:19 <nirik> or some other process needs agreed on... but not sure what it would be
18:05:33 <kalev> hmm...
18:05:35 <dgilmore> nirik: +1
18:06:03 <nirik> the big things are: new spin approvals, keeping a list of valid spins and testing them/dropping untested ones
18:06:22 <bowlofeggs> would fesco be responsible for testing spins?
18:06:23 <dgilmore> yep
18:06:25 <bowlofeggs> or if not, who?
18:06:37 <dgilmore> nirik: and some bugging of maintainers when things break
18:06:38 <sgallagh> bowlofeggs: No, whoever is producing the spin must test it
18:06:50 * bowlofeggs doesn't have a spinny office chair, but a fixed wooden chair
18:06:50 <dgilmore> though possibly we could setup fmn for that
18:06:54 <nirik> bowlofeggs: I tried to impose a 'spin owners must test spin at each milestone and sign off on it'
18:06:54 <sgallagh> We would just have to be able to see that it happened
18:07:02 <nirik> but that also takes someone checking it
18:07:26 <bowlofeggs> ah, so we would just want to see each spin maintainer say "yep, it works" at milestones, and have that on the schedule?
18:07:26 <jforbes> I think that makes sense
18:07:40 <nirik> we basically never drop spins (or havent in a long time), even if they are unmaintined
18:07:52 <nirik> or broken
18:07:56 <jsmith> nirik: We did a few years ago...
18:08:01 <bowlofeggs> and if they don't say that, we send them a nastygram and send their spin to /dev/null?
18:08:04 <jsmith> nirik: And frankly, I'd be in favor of doing that again.
18:08:05 <kalev> and we don't have a process for finding out unmaintained spins
18:08:06 <nirik> lots of the time they don''t compose and no one cares.
18:08:30 <jforbes> So perhaps with this process, we make sure someone signed off on "it works" and if they don't it gets dropped
18:08:33 <nirik> at several of the last releases we didnt get composes of some and people came after the release and asked where they were and to do a new build and put it into the release
18:08:40 <dgilmore> everytime I have tried to kick spins out, people complain and make noise until they get added back
18:08:43 <jforbes> With an optional "it doesn't work, but we are trying to fix it"
18:09:52 <nirik> would someone be willing to write up a policy of things we need to do/track?
18:10:15 <dgilmore> nirik: I guess I am probably in the best position for that
18:10:28 <nirik> I guess I could, but I am pretty sick of the process... for about 3 years the spins sig was me and bruno (no one else ever showed up or did anything)
18:10:46 <dgilmore> nirik: I feel you
18:11:03 <nirik> cool. If we can get something more detailed written up that would be great
18:11:32 <nirik> oh, there's also making the spins-kickstarts rpm for releases and merging kickstart PR's... but that process seems to work ok these days.
18:11:54 <dgilmore> I have made releng people review kickstarts
18:12:00 <dgilmore> it seems to run okay
18:12:17 <nirik> re: the issue the ticket was filed on, perhaps we could clone the last release page and just use that for f27?
18:12:39 <dgilmore> sure
18:12:40 <jforbes> That works
18:12:47 <dgilmore> and add all the new f26 spins
18:12:49 <nirik> #action dgilmore to write up proposal with schedule items fesco and spins owners needs to do each release.
18:12:51 <dgilmore> and labs
18:13:04 <nirik> who would like to do the exciting wiki work? ;)
18:13:11 <maxamillion> thanks dgilmore!
18:13:34 <maxamillion> nirik: wait, what's needed in the wiki other than what dgilmore volunteered for?
18:13:49 <dgilmore> maxamillion: a f27 spins page
18:13:58 <nirik> maxamillion: making a https://fedoraproject.org/wiki/Releases/26/Spins and https://fedoraproject.org/wiki/Releases/27/Spins
18:14:07 <nirik> and perhaps a https://fedoraproject.org/wiki/Releases/28/Spins
18:14:08 <maxamillion> ahhh
18:14:15 <nirik> I guess I can do that.
18:14:28 <nirik> #action nirik to make f26/27 spins pages.
18:14:39 <nirik> #topic Next weeks chair
18:14:43 <nirik> who wants it next week?
18:14:46 <jforbes> I can take it
18:14:52 <nirik> thanks!
18:14:52 <bowlofeggs> sold!
18:14:58 <kalev> thanks jforbes
18:14:59 <nirik> #action jforbes to chair next week
18:15:04 <nirik> #topic Open Floor
18:15:05 <tyll> thank you
18:15:13 <nirik> any open floor items from anyone?
18:15:14 <stefw> do we have a conclusion on 1774 or does it come again next week?
18:15:24 <stefw> https://pagure.io/fesco/issue/1774
18:15:30 <nirik> was just going to ask if we had more for stefw. :)
18:15:33 <maxamillion> nirik:  I can take the spins pages if you'd rather not
18:15:43 <nirik> maxamillion: fine with me if you want to. ;)
18:15:44 <stefw> i see one of two possible conclusions:
18:15:52 <stefw> 1. Grant the Waiver
18:16:02 <maxamillion> nirik: yeah, I don't mind, you end up doing a lot of stuff that falls off the edge
18:16:03 <stefw> 2. Uphold the Fedora Requirements for CI/CD and thus deny the Waiver
18:16:06 <jforbes> stefw: there was just the point that you can't build certain packages correctly outside of koji
18:16:21 <stefw> jforbes, that's right ... the pipeline has the intent to build packages in koji
18:16:43 <stefw> until then we'd like to get packager and developer feedback and make the artifacts that are being used to run the tests available to fedora packagers
18:16:54 <nirik> stefw: dgilmore wondered why we need a waiver here at all, we should be able to do this in 'normal' fedora... working with releng/infra, etc
18:16:54 <stefw> we could use a non-Fedora URL to bridge that gap ... if we want ... something like fedora-tests.org
18:17:17 <jforbes> And is the pipeline to be granted secureboot permissions?
18:17:47 <stefw> that is indeed another topic for FESCO
18:17:57 <stefw> and one that i aim to bring up in the future
18:18:01 <stefw> not granting teh pipeline per se
18:18:10 <stefw> but using 21st century things like signed git commits
18:18:19 <stefw> to have provenance of who made a change ... rather than who submitted it
18:18:32 <stefw> nevertheless ... i digress ... that is a topic for another FESCO request
18:18:48 <jforbes> As long as it is being considered
18:18:49 <nirik> stefw: so it builds in jenkins now, but down the road it will build in koji and be more 'official' at that point?
18:19:06 <stefw> indeed ... as jforbes hinted at ... we don't seem to get away from building packages in koji
18:19:26 <stefw> there ar emany things to iron out ... not the least of which is chain of trust ... which we hinted at above
18:19:39 <jforbes> So back to dgilmore's point, why is a waiver needed at all? koji handles all of those things already, builds not pushed/signed get deleted after time, etc
18:20:13 <stefw> because we want to do this now ... rather than wait for all of teh necessary changes to fall into place
18:20:33 <stefw> if FESCO would like us to wait ... and uphold the Fedora Requirements for CI/CD strictly, even for non-Released artifacts hosted at Fedora
18:20:44 <stefw> https://fedoraproject.org/wiki/Fedora_requirements_for_CI_and_CD
18:20:47 <stefw> then so be it
18:20:52 <stefw> we will have to bridge this gap another way
18:21:02 <dgilmore> I do not know that we have to wait, but we do not fully know what changes would be needed
18:21:12 <maxamillion> what dgilmore said
18:21:20 <stefw> at a very minimum changes to the CI pipeline ...
18:21:39 <stefw> currently there is a proof of concept to do package builds in koji
18:21:44 <stefw> but it's not running yet
18:22:01 <stefw> in the meantime we have packagers getting feedback from testst ... and we would like to make the artifacts that were used in the test available to those packagers
18:22:04 <stefw> hence the waiver request
18:22:41 <nirik> right, so this is just to publish those artifacts (clearly marked as development only) for those people?
18:22:53 <stefw> indeed
18:23:09 <stefw> ind the intent is to do so at a "Fedora" URL ... so it doesn't look like we're trying to fork teh distro (which we're not)
18:23:36 <dgilmore> stefw: what is the work taht is happening? and what is the plan to move it to be supportable
18:23:39 <dgilmore> ?
18:23:54 <stefw> are you referring to the work to build in koji?
18:24:12 <stefw> should i try to find that proof of concept, and where it's at? or are you referring to other work?
18:24:32 <dgilmore> stefw: well its not clear what all is to be delivered
18:24:43 <stefw> the deliverables are linked from #1774
18:24:45 <nirik> stefw: ok. So, we did approve things, but asked you to work with releng/infra/etc to implement... let me find the vote/proposal...
18:24:47 <stefw> i will get the link
18:25:14 <nirik> http://artifacts.ci.centos.org/artifacts/fedora-atomic/f26/ ?
18:25:17 <stefw> here are the existing artifacts: http://artifacts.ci.centos.org/artifacts/fedora-atomic/f26/
18:25:18 <stefw> that's right
18:26:05 <stefw> this request is to sync those over to a fedoraproject.org URL ... over time those development artifacts will start to have packages built in koji ... and in turn have things like provenance and secure boot worked out
18:26:51 <dgilmore> stefw: so I really do not understand what in there we can not itterate quickly over and deliver in fedora. and why we have to have any of it done differently
18:27:13 <stefw> we compose atomic hosts tens to hundreds of times a day
18:27:38 <dgilmore> I do not understand why we went off and did it all on the side in some different way without finding out how to do it in Fedora from day 1
18:27:46 <stefw> including ostrees and qcow2s ... many of which are then thrown away ...
18:27:51 <dgilmore> but anyway, where are the logs on how its all built?
18:28:06 <dgilmore> stefw: absolutly
18:28:06 <stefw> they are in every fedmsg that comes
18:28:14 <stefw> should i get you a link?
18:28:17 <nirik> we agreed to: ask for feedback from releng (who may just be able to do all this as needed), infra and legal (already acked).
18:28:19 <dgilmore> stefw: thats not helpful
18:28:33 * stefw will get it for you then ... to be helpful
18:28:45 <nirik> which I thought was also acking the general waiver to get it done, but I don't know that we explictly said that
18:29:05 <dgilmore> stefw: having the logs with the artifacts in a consumable way is part of how things have to be done
18:29:06 <nirik> dgilmore: centos ci has a ton of builders/resources...
18:29:12 <dgilmore> nirik: sure
18:29:28 <stefw> dgilmore, okay understood ... and that's well represented in Section 5 clause 6 of the Fedora Requirements for CI/CD
18:29:32 <dgilmore> nirik: and extanding how we do things to use those resources would be awesome
18:29:34 <stefw> so hence my question to FESCO:
18:29:45 <maxamillion> yeah, CentOS CI has more hardware behind it than all of Fedora Infra combined iirc
18:30:05 <stefw> "Is it to be understood that  until we meet the 'Fedora Requirements to CI/CD' we are unable to host Developer non-Released artifacts on a fedoraproject.org URL?"
18:30:20 <dgilmore> did fesco sign off on https://fedoraproject.org/wiki/Fedora_requirements_for_CI_and_CD ?
18:30:20 <stefw> if so, then that is a clear answer from FESCO ... and it's clear the work to be done to make it so
18:30:25 * dgilmore does not remeber
18:30:33 <stefw> dgilmore, i don't know ... you were one of the authors though ...
18:30:48 <dgilmore> stefw: I had some input into it yes
18:30:49 <bowlofeggs> i interpreted out last vote as basically being "we want input from those three groups"
18:30:50 <maxamillion> I don't recall
18:30:52 <bowlofeggs> *our
18:31:06 <stefw> i figured Fedora folks would do the necessary to document those requirements
18:31:21 <stefw> Those requirements form the basis of the one of Fedora's objectives
18:31:28 <stefw> and also the basis for the work that has been done so far
18:31:33 <dgilmore> stefw: but pretty sure I was always clear that just meeting the criteria did not mean that it would be allowed or would be the only thing
18:31:37 <stefw> the requirements for delivery have not been met
18:32:16 <nirik> this is just a developer/stopgap until they are riight? things are still working torward that?
18:32:18 <stefw> those requirements are the foundation of the work that has been done toward the Objective on CI/CD so far
18:32:25 <maxamillion> alright, so what specifically is being asked of FESCo here?
18:32:40 <stefw> "Is it to be understood that  until we meet the 'Fedora Requirements to CI/CD' we are unable to host Developer non-Released artifacts on a fedoraproject.org URL?"
18:33:56 <nirik> I'm personally ok to allowing non mirrorred and clearly marked as developer only content in a fedoraproject.org url until CI/CD requirements are fully met
18:33:57 <jforbes> So here is where letting this move forward would be useful. People are actively developing tests right now, I have a pull request for kernel. Kernel won't work with the current stuff because of secure boot, but for other people the testing will work
18:34:26 <maxamillion> is that for FESCo to decide or is that for the Council?
18:34:28 <jforbes> But it is much more helpful if those developers have access to the tests artifacts
18:34:36 <bowlofeggs> i'm also personally ok with it, but i care a lot about releng's voice on it too
18:35:35 <jforbes> I would be happier with it if it were given some sort of lifespan so that people don't get lazy with "things are working now" and forget to move forward once this is in place
18:35:44 <nirik> I guess the current access at that centos-ci url is slow/small ?
18:35:53 * stefw notes that it is slow indeed
18:36:28 <stefw> but it's more about including a "centos" URL in all feedback to Fedora packagers, that seems, well awkward
18:36:35 <nirik> indeed.
18:36:39 <jforbes> stefw: any WAG on the timeframe to meet the requirements?
18:36:40 <nirik> jforbes: good idea.
18:36:54 * dgilmore is honestly okay using a centos url. they are part of the family
18:37:02 <stefw> jforbes, my gut feeling is early next year
18:37:07 <dgilmore> I would like to see the logs with the artifacts
18:37:08 <stefw> before tehy are all met
18:37:13 <stefw> dgilmore, can do
18:37:19 <jforbes> So 6-9 months?
18:37:19 <dgilmore> and I would like to see how and  where things are being done
18:37:20 <bowlofeggs> we could make a fedora URL that just redirects to the centos url
18:37:26 <bowlofeggs> wild idea
18:37:37 <dgilmore> bowlofeggs: that is simple
18:37:41 <jforbes> bowlofeggs: I think the slow is the problem
18:37:45 <nirik> bowlofeggs: wouldn't help it being slow tho.
18:37:57 <dgilmore> jforbes: not sure that any links we have are honestly any faster
18:38:01 <dgilmore> without using mirrors
18:38:02 <bowlofeggs> wouldn't it be slow from us too, since it won't be mirrored?
18:38:07 <stefw> jforbes, more like 6 months ... although i see us building in koji *way* before that
18:38:33 <nirik> our main datacenter has more BW than the one they have CI in.
18:38:44 <dgilmore> I suspect that the CDN we have donated would not like us putting this on them
18:39:05 <jforbes> So perhaps approve for 6 months. After that 6 months, if you wish to continue, it has to be brought back to FESCo?
18:39:22 <nirik> +1
18:39:24 <bowlofeggs> sounds reasonable to me
18:39:25 <bowlofeggs> +1
18:39:35 <stefw> that's fair ... and i also see the proviso from dgilmore that build logs must be made available
18:39:51 <jforbes> That too, seems quite useful for debugging output
18:39:56 * nirik nods.
18:40:11 <dgilmore> it makes debugging easier than having to go dig
18:40:39 <dgilmore> I would like to actually look at how it is all being done closer
18:40:53 <dgilmore> but thats more for personal interest
18:41:04 <stefw> certainly ... and i'd be happy to hunt down missing documentation
18:41:05 <nirik> so, can we vote on this again? or ?
18:41:16 <jforbes> Sure
18:41:20 <maxamillion> sounds good
18:41:22 * stefw notes that documentation is linked from here: https://fedoraproject.org/wiki/CI
18:41:30 * dgilmore is getting hungry
18:41:33 <nirik> proposal: wavier granted for 6 months, will revisit then. Logs should be added to artifacts.
18:41:38 <bowlofeggs> +1
18:41:40 <jforbes> +1
18:41:43 <dgilmore> meeting started at 11 and its 13:41
18:41:50 <dgilmore> +1
18:41:55 <nirik> yeah, it's a long one. :(
18:41:57 <nirik> +1
18:42:24 <tyll> +1
18:42:28 <nirik> lost kalev. ;)
18:42:56 <maxamillion> +1
18:43:06 <nirik> #agreed wavier granted for 6 months, will revisit then. Logs should be added to artifacts (+6,0,0)
18:43:46 <nirik> stefw: you (or whoever) can file a infra ticket and we can work out details on syncing content, etc.
18:44:01 <nirik> anything else on this or any other open floor item?
18:44:01 <stefw> thanks, will work with dustymabe to get this underway... will do
18:44:16 <jforbes> nothing else from me
18:44:22 <dgilmore> nada
18:45:05 <tyll> no
18:45:23 <nirik> ok, thanks for coming everyone. Have a good friday and weekend.
18:45:26 <nirik> #endmeeting