15:01:12 <sgallagh> #startmeeting FESCO (2019-01-14)
15:01:12 <zodbot> Meeting started Mon Jan 14 15:01:12 2019 UTC.
15:01:12 <zodbot> This meeting is logged and archived in a public location.
15:01:12 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:12 <zodbot> The meeting name has been set to 'fesco_(2019-01-14)'
15:01:12 <sgallagh> #meetingname fesco
15:01:12 <sgallagh> #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor
15:01:12 <sgallagh> #topic init process
15:01:12 <zodbot> The meeting name has been set to 'fesco'
15:01:12 <zodbot> Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek
15:01:17 <mhroncok> hi
15:01:17 <sgallagh> .hello2
15:01:18 <zbyszek> .hello2
15:01:18 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:21 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:22 <nirik> morning
15:01:22 <jforbes> .hello2
15:01:24 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:01:27 <otaylor> .hello2
15:01:28 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:01:31 <asamalik> .hello2
15:01:31 <zbyszek> afternoon ;)
15:01:32 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:01:53 * asamalik is here to discuss #2027 and #2028
15:02:18 <asamalik> good morning and good afternoon!
15:02:40 <bcotton> .hello2
15:02:41 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:02:48 <bowlofeggs> .hello2
15:02:54 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:04:05 <sgallagh> contyk told me he couldn't make it, so I think we have everyone but tyll, so we're probably good to start
15:04:15 <sgallagh> #topic #2003 Ursa Major (modules in buildroot) enablement
15:04:15 <sgallagh> .fesco 2003
15:04:19 <zodbot> sgallagh: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003
15:05:06 <sgallagh> I want to throw out a contentious proposal here
15:05:21 * bowlofeggs readies his pitch fork
15:05:29 <zbyszek> https://pagure.io/pungi/issue/1095 has no answer :(
15:05:30 * nirik gets a torch
15:05:42 * zbyszek grabs a flamethrower
15:06:10 * mhroncok grabs popcorn
15:06:13 <sgallagh> Currently, the lack of Ursa Major is providing a blocker to EPEL efforts. I'd like to propose that FESCo approves the addition of Ursa Major in Fedora/EPEL and leaves the implementation details to be worked out by those doing the work.
15:06:15 * asamalik grabs a single match because he's just a guest here
15:07:01 <sgallagh> Trusting in the fact that at least three FESCo members are actively working on the problem and will report back if specific questions need answering.
15:07:10 <bowlofeggs> i would prefer it if we still have some high level requirements
15:07:12 <otaylor> sgallagh: What does "in fedora/epel" mean in this context? Enabled only for those buildroots?
15:07:27 <bowlofeggs> i don't feel the need to specify how they are achieved, but i think we need a way for packagers to make local builds still
15:07:33 <bowlofeggs> (for example)
15:07:46 <sgallagh> otaylor: I was going higher-level than that and just asserting that we permit it in the infrastructure.
15:07:47 <mhroncok> sgallagh: if the primary motivation is epel8, can we only do it in epel8 and see how it works, before we possibly destroy fedora?
15:07:49 <zbyszek> That proposal means that FESCo abdicates the responsibility, and I'm not happy about that.
15:07:58 <sgallagh> bowlofeggs: I don't think that is necessarily a blocker to doing this
15:08:06 <otaylor> sgallagh: EPEL doesn't have separate infrastructure...
15:08:08 <sgallagh> I think it's absolutely an endgame requirement
15:08:26 <bowlofeggs> sgallagh: wouldn't it mean that packagers can't build packages locally? i thought that was the primary concern in the ticket from before
15:08:27 <sgallagh> otaylor: That's why it was a slash and not an OR
15:08:33 <bowlofeggs> (working on memory)
15:08:43 <otaylor> sgallagh: Oh, I misunderstood the proposal then :-)
15:09:09 <nirik> we are going to also have to work out mbs for epel8...without exposing rhel binries....
15:09:12 <sgallagh> It would, and it probably is, but I'm suggesting that blocking on local builds is hurting our ability to deliver other pieces in the meantime
15:09:30 <otaylor> sgallagh: Or, wait, I'm not sure which you were proposing ... is the / namespacing or "OR" ?
15:09:41 <zbyszek> or "AND" ?
15:09:52 <bowlofeggs> i personally think the ability to locally build is crucial
15:09:54 <sgallagh> But I suppose if the rest of FESCo disagrees, I'd be willing to walk it back to "Allow Ursa Major for EPEL without a local build requirement to unblock their efforts"
15:10:02 <bowlofeggs> it saves so much time when trying to debug
15:10:19 <sgallagh> otaylor: I think we're getting lost in the semanticshere.
15:10:29 <jforbes> That is fair, and I hate to block progress, but the local build requirement is also pretty critical
15:10:36 <otaylor> sgallagh: I have no idea what you proposed, sorry
15:10:41 <sgallagh> bowlofeggs: I do not disagree that it is *highly desirable*. I disagree that it is absolutely mandatory
15:11:13 <sgallagh> otaylor: I'll rephrase, maybe it will help
15:11:14 <bowlofeggs> it makes an enormous difference when there is a build problem
15:11:38 <mhroncok> as long as we approve this without such things as local builds or 3rd party rebuilds working, we have a dangerous situation
15:12:04 <mhroncok> some maintainers are eager to drop their nonmodular packages and they will do it
15:12:24 <mhroncok> and suddenly, other maintainers are left in a very bad situation
15:12:31 <sgallagh> As long as we don't approve this, we cannot move forward with EPEL 8 at all. Which is more important to us?
15:12:45 <zbyszek> What mhroncok says
15:12:56 <zbyszek> Sorry sgallagh
15:12:57 <otaylor> sgallagh: are you thinking that there's no solution for local build that can be arrived at?
15:13:04 <mhroncok> exisitng contributors bet nonexsisting epel
15:13:08 <mhroncok> *beat
15:13:24 <sgallagh> otaylor: I'm saying that every time a suggestion has been proposed, it's shouted down and spends a month trying to find a way to satisfy people.
15:13:45 <sgallagh> I think it's more likely that a solution will be found when it becomes critical to do so than if we keep kicking the can down the road.
15:13:50 <mhroncok> let's experiment withe pel8 without breaking Fedora? why is that wrong?
15:14:01 <mhroncok> *epel8
15:14:11 <smooge> with my EPEL hat on.. the local build is critical also
15:14:13 <jforbes> Wait, local build does work, there is no solution for automagically installing build deps
15:14:24 <sgallagh> jforbes: Correct
15:14:25 <otaylor> I'd be happy to support enabling UM for EPEL 8 work immediately, if there's a *plan* to get to the point where local builds can be done, and work is being done on that
15:14:33 <smooge> because most of the packagers I have talked with don't want to put stuff in EPEL-8 until they can build it locally
15:14:45 <sgallagh> otaylor: Local builds *can* be done, you just have to install your deps manually first
15:14:52 <jforbes> unfortunate, but not impossible
15:14:52 <sgallagh> There's no "mock" equivalent today
15:15:59 <mhroncok> I think we cannot break what doesn't exist
15:16:09 <mhroncok> if we do this in EPEL first, we can figure out the problems as we go
15:16:28 <mhroncok> there will be problems and there will be workarounds
15:16:30 <otaylor> sgallagh: is the plan that modules in UM must be in the modular repodata?
15:16:36 <otaylor> (no "buildroot only" modules)
15:16:42 <smooge> with the way that the build system is interdependant.. is it possible to do it for EPEL and not Fedora?
15:16:45 <jforbes> I am going to say, I think we should let EPEL 8 go forward, and insist that the local build issue be a priority for further development
15:17:35 <sgallagh> otaylor: I think so, yes. That seems a reasonable restriction.
15:17:50 <bowlofeggs> i feel like we've already allowed too many "cuts" on the packager workflow through in the past 1.5 years
15:17:59 <bowlofeggs> this seems like a pretty deep cut
15:18:14 <zbyszek> I don't think that sgallagh's characterisation that "time a suggestion has been proposed, it's shouted down and spends a month trying to find a way to satifsfy people" is correct. Instead, there have been some concrete proposals, e.g. pungi#1095, with no real answer.
15:18:20 <otaylor> smooge: I think you should be able to configure UM only to be active for the EPEL8 tag
15:18:25 <bowlofeggs> (thinking of the pkgdb retirement and all the features that were lost that nobody is adding back)
15:18:49 <zbyszek> Somebody needs to put in the work and figure out the details to satisfy the requirements that have been voiced.
15:19:00 <zbyszek> Pushing it down the road is not going to help that happen.
15:19:14 <bowlofeggs> zbyszek: agreed. if we approve this, there will be no pressure to fix it later
15:19:19 <bowlofeggs> it will be like the pkgdb situation
15:19:31 <bowlofeggs> there is no pressure for anyone to fix those problems, and nobody is
15:19:48 <nirik> there is an objective to now. ;)
15:19:51 <bowlofeggs> if there had been a requirement to have feature parity before pkgdb was retired, we wouldn't be in this situation now
15:20:03 <bowlofeggs> yeah i see that, and i hope it is successful
15:20:16 <sgallagh> bowlofeggs: That may be true, but we'd also probably still be on Trac at this point
15:20:18 <mhroncok> but let's not go thatroad again
15:20:21 <bowlofeggs> but we've had a long time of poor experiences because nobody stood up for packagers when that proposal was made
15:20:32 <mhroncok> if we approve this now, we migth have an objective in 3 years to enbale local builds
15:20:57 <sgallagh> As noted, there are active proposals for how local builds should work.
15:21:02 <sgallagh> This *is* a priority already.
15:21:18 <mhroncok> it should be a hard requirement
15:21:37 <bowlofeggs> to me it's more important for people to actualyl solve those problems than to just have proposals for how they could be solved
15:21:37 <sgallagh> Does someone want to make that a proposal then?
15:22:15 <sgallagh> E.g. "Ursa Major is forbidden in the Fedora (and EPEL) infrastructure until automatic local build dependencies are available" ?
15:22:42 <mhroncok> I'd still be fine if we enable this in EPEL8 as an experiment
15:22:48 <sgallagh> Because if nothing else, I would like to get *some* hard target settled today so we at least know that the requirements won't keep changing on us
15:23:11 <zbyszek> I'd prefer to phrase it positively
15:23:41 <sgallagh> zbyszek: Why start now? (Sorry, but it's been a whole lot of stonewalling so far)
15:23:44 <otaylor> Proposal: Ursa Major can be enabled *only* for EPEL8 for now, to allow work to proceed, but before enabling it for other tags, there needs to be an agreement on an appropriate packager workflow for local builds
15:24:04 <sgallagh> otaylor: An agreement between whom?
15:24:13 <otaylor> approved by fesco
15:24:27 <sgallagh> Just wanted that to be clear
15:24:51 <zbyszek> proposal: the ability to do automatic local installation of build dependencies is a pre-requirement for enabling UM, e.g. along the lines of pungi #1095
15:25:00 <mhroncok> sgallagh: do i assume correctly you would be happier if that "appropriate packager workflow for local builds" would be better defined?
15:25:11 <otaylor> (appropriate workflow could just be "only default streams can be enabled in UM" - not necessarily new technology.)
15:25:16 * sgallagh finds the idea that EPEL is going to be the experimental testing ground somewhat backwards, but
15:25:28 <nirik> well, it's only beta currently
15:25:35 <zbyszek> yeah, that seems wrong
15:25:40 <sgallagh> Sure, but it's still kind of odd
15:25:55 <mhroncok> looking at modularity in Fedora and modularity in RHEL8, i think it make sense if we experiment in EPEL8
15:26:05 <bowlofeggs> does seem against the 'upstream first' mantra, but it is also mostly motivated by epel
15:26:06 <sgallagh> Yeah, I don't actually disagree.
15:26:07 <zbyszek> nirik: also, by the time peole make use of this, it won't be beta anymore
15:26:10 <sgallagh> It just *feels* backwards
15:26:32 <otaylor> sgallagh: my impression is that you are saying this is urgent because EPEL8 is blocked on it? So blocking the work in EPEL8 and allowing it to proceed elsewhere wouldn't make sense.
15:26:38 <nirik> perhaps but we can also do final differently with lessons learned
15:27:15 <sgallagh> otaylor: Yeah, as I said, I don't disagree with the plan. It's just kind of unintuitive
15:27:45 <bowlofeggs> ok so we have a few different proposals out there
15:28:12 <bowlofeggs> first of all, we haven't made many epel decisions while i've been on fesco. so fesco overseees the epel sig?
15:28:17 <sgallagh> otaylor: "Only default streams" is actually insufficient.
15:28:25 <sgallagh> Because default streams CAN be incompatible with one another
15:28:44 <mhroncok> I think EPEL Steering Committee should actually decide if it is being done in epel or not
15:28:44 <zbyszek> So, ... we have a history of temporary solutions and soon-to-fixed deficiencies persisting for years.
15:28:45 <nirik> bowlofeggs: yes.
15:28:46 <bowlofeggs> because i wouldn't mind allowing the epel sig to make the decision about whether they are ok with local builds working or not, for epel
15:28:51 <sgallagh> bowlofeggs: FESCo oversees Infra to some extent. Adding new build infrastructure may affect both products
15:28:53 <mhroncok> but we may recommend it?
15:28:56 <sgallagh> *projects
15:29:28 <sgallagh> I think we at least have to say "It's permissible"
15:30:08 <mhroncok> I think so too
15:30:24 <mhroncok> but I amen EPEL should make the decision whether to use this
15:30:32 <sgallagh> Yes
15:30:33 <bowlofeggs> i really am heavily concerned about allowing something with a "we'll fix it later" because of the history, especially recent
15:30:47 <mhroncok> bowlofeggs: even in EPEL only?
15:31:08 <sgallagh> bowlofeggs: I'm heavily concerned about going the other direction and disallowing experimentation at all.
15:31:29 <zbyszek> mhroncok: yes
15:31:45 <sgallagh> bowlofeggs: I mean, perhaps we ask the EPEL SIG to say that EPEL isn't officially released/available until local builds are possible
15:31:57 <sgallagh> But we still allow them to bootstrap things in the official build system
15:32:01 <mhroncok> sgallagh: shouldn't we experiment in copr etc. rather than in Fedora proper?
15:32:17 <sgallagh> mhroncok: How do you experiment with the build system in a COPR?
15:32:18 <zbyszek> sgallagh: I think experimentation is good, so let's provide a devel version of pungi that provides some first iteration of the solution, and build on that.
15:32:28 <sgallagh> zbyszek++
15:32:28 <zodbot> sgallagh: Karma for zbyszek changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:33:00 <mhroncok> sgallagh: or some experimntal Koji. what I'm trying to say is don't break contributor experience for experiments
15:33:02 <jforbes> Copr is not the place to experiment in my opinoin
15:33:10 <otaylor> zbyszek: I think someone needs to requirement collect, then line up the solutions
15:33:46 <bowlofeggs> so it is true that EPEL 8 can't be built without Ursa Major?
15:33:56 <otaylor> mhroncok: but there's no contributor experience for epel8 now - if you have an epel8 installation and want to work on epel8 packages by doing local builds, you can't
15:34:12 <otaylor> s/epel8 installation/rhel 8 beta installation/
15:34:24 <mhroncok> otaylor: and since there is no experince now, i'm OK to allow that
15:34:26 <sgallagh> bowlofeggs: In RHEL 8 beta, a large percentage of packages that might be used for building are available only as modules
15:34:43 <sgallagh> So it would be impossible to build the majority of packages we'd want in EPEL without it.
15:34:53 <sgallagh> The ones we *could* build would be the exceptions, not the rule
15:35:02 * nirik thinks the beta is fine for trying to get solutions with, then when final comes out we can look at it again?
15:35:07 <zbyszek> otaylor: I agree, with the caveat that this is going to be have to be somebody who is deeply involved in the modularity initiative.
15:36:03 <sgallagh> zbyszek: Yeah, it's becoming increasingly clear that this needs to be me or contyk.
15:36:09 <smooge> how hard would it be to set up a seperate koji+bodhi+pungi+everything-else+ursa-major for just EPEL-8
15:36:12 <sgallagh> And since contyk cleverly dodged this meeting, I guess that means me
15:36:19 <nirik> ha
15:36:34 <bowlofeggs> i think i'm ok with letting the EPEL SIG make this decision for EPEL 8, but i don't want Fedora to use this until we have an equivalent packager experience to what we have today
15:36:39 <sgallagh> nirik: Was that directed at me or smooge? :)
15:36:59 <bowlofeggs> my reason for allowing it in EPEL 8 is the arguments that there can't be an EPEL 8 without it
15:37:03 <nirik> sgallagh: at you.
15:37:21 <mhroncok> bowlofeggs: exactly
15:37:26 <nirik> a duplicate koji/bodhi/everything would be... a lot of work
15:38:34 <sgallagh> OK, let me string together a couple proposals and see where we stand.
15:39:29 <zbyszek> sgallagh++
15:39:29 <zodbot> zbyszek: Karma for sgallagh changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:39:57 <sgallagh> 1: FESCo will permit standing up an Ursa Major instance to be configured for use only in EPEL 8  this time.
15:39:57 <sgallagh> 2: FESCo would like a set of detailed requirements gathered regarding packager experience for local builds. Once approved, these will need to be met before enabling Ursa Major in Fedora.
15:40:47 <sgallagh> Assuming we agree with (2), I'll take an action item to try to put this together by Friday so you can all read it over the weekend. (Or, more likely,  five minutes before the meeting 😁 )
15:41:06 <nirik> +1, sure
15:41:25 <sgallagh> +1 to both, for the record
15:41:36 <jforbes> +1 to both
15:41:58 <zbyszek> +1 for 2, -1 for 1.
15:42:07 <otaylor> +1 to both
15:42:30 <mhroncok> I'd rather s/packager experience for local builds/packager experience/ - but it's not strong opinion. +1 to both
15:43:16 <sgallagh> mhroncok: Well, I think we already know the centralized packager experience at least.
15:43:36 <sgallagh> But I'll see if I can address both in my doc
15:43:58 <jforbes> Just something to consider, EPEL is a part of the Fedora community, and we can't leave them completely broken. I think with the combination of proposals here, it is the best way forward
15:44:15 <bowlofeggs> i'm +1 to both
15:44:43 <bowlofeggs> though, should we have the EPEL SIG make the final call on that?
15:45:00 <sgallagh> bowlofeggs: That's why I said we'd permit it. Not mandate it
15:45:07 <bowlofeggs> i imagine they just have to accept it since they can't have EPEL without it, but it still seems like a good idea to involve them
15:45:20 <bowlofeggs> sgallagh: ah ok, that wording works for me then
15:46:27 <sgallagh> #agreed FESCo will permit standing up an Ursa Major instance to be configured for use only in EPEL 8  this time. (+5, 0, -1)
15:46:27 <sgallagh> #agreed FESCo would like a set of detailed requirements gathered regarding packager experience for local builds. Once approved, these will need to be met before enabling Ursa Major in Fedora. (+6, 0, -0)
15:46:27 <sgallagh> #action sgallagh to gather requirements
15:46:34 <smooge> At the moment the EPEL SIG is going to be split. We need it for an EPEL beta, but many of the packagers I deal with are EPEL-6 bound and are like 'how do I build this on my laptop like I do all the other packages?'
15:47:11 <sgallagh> Shall we move on?
15:47:13 <smooge> yep
15:47:18 <sgallagh> OK
15:47:25 <sgallagh> #topic #2027 RFC: Module lifecycles
15:47:25 <sgallagh> .fesco 2027
15:47:26 <zodbot> sgallagh: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027
15:47:45 * asamalik wakes up
15:48:03 * sgallagh hands asamalik the conch shell
15:49:07 <sgallagh> asamalik: That was your cue
15:49:43 <asamalik> so from the comments in the ticket I feel that people prefer setting modules' EOL as a specific fedora release, not a date
15:50:07 <jforbes> That was my strong preference
15:50:16 <asamalik> so we won't have a situation when a module EOLs in the middle of a release
15:50:23 <sgallagh> Yeah, I don't think there's any other realistic way to accomplish it when dates are malleable
15:50:45 <zbyszek> PROPOSAL: 1. Module EOL is defined in git along with the rest of the definition of the module.
15:50:46 <otaylor> asamalik: Yes - you mean "module stream EOLs" though right?
15:50:48 <zbyszek> 2. The EOL is defined as Fedora release number, and the module is supported until that Fedora release goes EOL, even if that slips.
15:50:54 <sgallagh> asamalik: Not in Fedora, and in EPEL I think we can only reasonably tie it to minor RHEL releases.
15:51:17 <asamalik> otaylor: right
15:51:34 <asamalik> otaylor: thanks :)
15:52:14 <mhroncok> zbyszek: that concerns you proposal as well
15:52:16 <bowlofeggs> yeah i also prefer EOL being a release
15:52:25 <mhroncok> zbyszek: it's a stream that eols
15:52:40 <zbyszek> mhroncok: yep!
15:52:42 <asamalik> what people think about the possibility of not setting an EOL in order to build the module until manually EOL'd by setting a release?
15:53:01 <mhroncok> asamalik: well that's the current case anyway
15:53:04 <bowlofeggs> oh yeah that's true, EPEL changes it maybe
15:53:05 <sgallagh> asamalik: Can I try to rephrase that?
15:53:07 <otaylor> asamalik: I think that's fine and make sense for most streams
15:53:11 <asamalik> sgallagh: please!
15:53:26 <bowlofeggs> because having a fedora release be the EOL seems nice to me, but what do we do wtih EPEL? point release EOL?
15:53:38 <zbyszek> I wonder if for EPEL we should allow date-EOL after all.
15:53:57 <zbyszek> RHEL release schedule is not known in advance (publically).
15:54:03 <bowlofeggs> yeah
15:54:05 <sgallagh> I think what asamalik is asking is: "Instead of picking an EOL up front, can we treat the lack of an EOL as an assumption that it's supported for this release? Then, once we know for sure we're going to not support it after a certain release, set the value then"
15:54:26 <nirik> makes sense
15:54:27 <zbyszek> sgallagh: that sounds good
15:54:28 <sgallagh> Which also could work for EPEL
15:54:34 <bowlofeggs> sgallagh: that makes sense to me too
15:54:35 <asamalik> zbyszek: so that was the initial thought behind the date.. and the build system would compute a corresponding Fedora release out of that, somehow
15:54:40 <sgallagh> Since we don't need to know the schedule in advance.
15:54:46 <asamalik> sgallagh: +1
15:54:48 <jforbes> That seems fair
15:54:58 <sgallagh> Once the beta is announced, people could then decide if they want to support it after that point by setting the value
15:55:10 <zbyszek> asamalik: yeah, I know, but for Fedora the approximate schedule is known, and then it makes more sense to use the release
15:55:15 <bowlofeggs> asamalik: would it be viable to set the EOL to an EPEL point release?
15:55:20 <bowlofeggs> e.g. 8.2?
15:55:32 <otaylor> I think EPEL needs to come up with its own rules, but there may not be experience to do that yet
15:56:33 <sgallagh> True; nothing stops EPEL from declaring for example that it has six month cycles that happen to be tied to Fedora releases...
15:56:41 <asamalik> bowlofeggs: to not answer your question, do we want to set this separately for Fedora and EPEL? That would mean for example setting f30 and 8.2 at once? and for example only setting f30 would mean "build for epel forever"?
15:57:04 <asamalik> I both want and don't want to treat Fedora and EPEL as two different things in this regard
15:57:20 <otaylor> (Can the module default stream change during an EPEL release? That's not really compatible with traditional EPEL rules, but modularity changes everything)
15:57:56 <sgallagh> otaylor: That policy decision hasn't been made yet, so far as I know
15:58:20 <sgallagh> I'd lean towards suggesting that it should be impermissible though
15:58:42 <otaylor> asamalik: Hmm, do we expect modules to stream expand across Fedora and EPEL?
15:58:52 <sgallagh> otaylor: We absolutely want that
15:58:57 <asamalik> another a bit crazy idea would be setting just one, either Fedora or an EPEL -release based EOL and let the buildsystem automagically figure out an EOL for the other one... </half-serious>
15:59:06 <asamalik> otaylor: yes
15:59:22 <bowlofeggs> asamalik: that's a good question. i guess i was assuming we would want to set them separately, but i can now see why you might not want to
15:59:47 <mhroncok> asamalik: my concern with dates was that it's too magical
16:00:05 <asamalik> the date was the only one working for both the same way, but it has its own issues
16:00:09 <mhroncok> asamalik: setting a Fedora EOL via EPEL release number (or vice versa) is even more magical
16:00:17 <otaylor> mhroncok: I certainly have spent considerable mental cycles with the fedpkg request-branch trying to figure out what date I needed....
16:00:23 <sgallagh> smooge, nirik: Do you think EPEL SIG would be okay with matching to the Fedora schedule? Or would that be too much trouble?
16:00:30 <bowlofeggs> this issue is less contentious than the last one, but imo harder to come to a solution on ☺
16:00:46 * asamalik sends a magical spell towards mhroncok, laughing
16:00:54 <nirik> I could see it being confusing...
16:01:01 <bowlofeggs> asamalik: would it be painful to support "all of the above?" (date, fedora release, EL point release)?
16:01:08 <sgallagh> Maybe we could just do a "season"?
16:01:10 <bowlofeggs> and let the packager pick?
16:01:14 <asamalik> bowlofeggs: that was the initial idea, yes
16:01:29 <sgallagh> (Well, picking a non-northern-hemisphere-oriented term)
16:01:34 <otaylor> Proposal: just support one, but have a well known web page with a table....
16:01:46 <zbyszek> bowlofeggs: but then we need to come up with rules what happens if a Fedora release slips
16:01:53 <sgallagh> i.e. supported until Q1 2020 and that translates to the appropriate release in that timeframe
16:01:53 <bowlofeggs> yeah
16:01:55 <mhroncok> can we do it by game of thrones releases?
16:01:58 <bowlofeggs> hahaha
16:02:06 <sgallagh> mhroncok: Books or TV? "_
16:02:07 <sgallagh> :)
16:02:27 * sgallagh suspects that the latter might mean supporting modules longer than RHEL 8's lifetime
16:02:29 <mhroncok> sgallagh: both actually as we are trying now with fedora and epel
16:02:31 <sgallagh> err former
16:02:32 <jforbes> sgallagh: has to be books, TV is done in a couple of months
16:02:33 <bowlofeggs> ok, so the simplest proposal i see is to allow only fedora releases. would that be a problem for epel?
16:02:58 <sgallagh> bowlofeggs: nirik said "I could see it being confusing..." above on that
16:03:02 <bowlofeggs> yeah
16:03:14 <nirik> yeah, but might be a ok first cut at it...
16:03:20 <bowlofeggs> what if there were two fields for the EOL
16:03:20 <mhroncok> I suppose specifciying a Fedora release and an RHEL release
16:03:23 <otaylor> bowlofeggs: We'd have to make sure that it was displayed to epel users in time form ... we can't assume an epel user (or a fedora user) knows when f31 is
16:03:25 <sgallagh> Which is why I was thinking about just doing half-years or something
16:03:26 <mhroncok> in case the module builds fro both
16:03:33 <bowlofeggs> {'product': 'fedora', 'release': 31}
16:03:39 <sgallagh> If the release happens in Q1/Q2 or Q2/Q3, it ends then
16:03:41 <asamalik> for the date, would a following rule be crazy? "Modules EOL with the first release having its EOL *after* the module EOL date, potentially slipping with the release."
16:03:43 <bowlofeggs> {'product': 'epel', 'release': 8.2}
16:03:56 <bowlofeggs> then you can use both or just one?
16:03:59 <mhroncok> bowlofeggs: +1
16:04:02 <bowlofeggs> make EOL a list?
16:04:06 <asamalik> I really want to change that "after" to "before" but we'd need a time machine
16:04:09 <sgallagh> bowlofeggs: Depends on where we're storing that info
16:04:24 <sgallagh> If it's in the module metadata, that's now a backwards-incompatible change that we won't get into RHEL 8 at this point.
16:04:33 <mhroncok> asamalik: or just EOL everything now and call it day :D
16:04:52 <sgallagh> (Though I never liked the idea of storing that in the modulemd)
16:04:53 <asamalik> mhroncok: yeah, who use these Linuxes anyway!!!
16:04:56 <zbyszek> Hmm, EPEL lives on its own schedule. I don't understand tying lifetime of EPEL things to Fedora releases.
16:04:57 <bowlofeggs> sgallagh: ah
16:05:07 <bowlofeggs> sgallagh: so what does the existing module metadata format allow?
16:05:09 <nirik> we do have FPDC we could use
16:05:25 <sgallagh> bowlofeggs: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L40
16:05:25 <otaylor> zbyszek: Well, if we are sharing module streams, they have to be tied together. The question is how to do it.
16:05:41 <zbyszek> sgallagh: isn't the format xml/json/whatever to be extensible exactly to allow adding new fields at any point?
16:06:04 <asamalik> sgallagh: I actually like that idea
16:06:06 <bowlofeggs> sgallagh: so dates only?
16:06:09 <sgallagh> zbyszek: Not exactly, no. Though there's an opportunity to cheat.
16:06:42 <sgallagh> The YAML structure is strict except for the "XMD" section, which can contain arbitrary content that isn't validated.
16:07:03 <sgallagh> MBS uses it for internal purposes, but we could extend it for our purposes.
16:07:19 <sgallagh> It just wouldn't be directly accessible via libmodulemd API
16:07:41 <sgallagh> (You'd just get the raw contents as python objects or GVariants in C and deal with them manually)
16:07:48 <bowlofeggs> sgallagh: so if we were going to say "fedora version x" that wouldn't work with this file either?
16:08:08 <sgallagh> bowlofeggs: Well, as I said, I don't really like the idea of storing that info in the metadata to begin with
16:08:09 <zbyszek> That's sad, but it's still probably better then putting it in some external place
16:08:14 <sgallagh> I think the FPDC idea is a better place for it
16:08:27 <zbyszek> sgallagh: but why?
16:08:28 <sgallagh> Because metadata once in the repo is static
16:08:42 <bowlofeggs> sgallagh: so would dnf/packagekit query PDC to get it? or would it get into the repodata via some process?
16:08:50 <sgallagh> But if the upstream decides to extend the lifecycle, for example, you can't change that in the frozen release repos
16:09:19 <zbyszek> I don't think so. I update the metadata of my packages all the time. This would be just another case.
16:09:19 <sgallagh> I guess as long as the metadata values were always updated on any compose of the updates[-testing] repos, it could work though
16:09:45 <sgallagh> Is this data useful on the client side though?
16:09:50 <bowlofeggs> we probably don't want users live querying PDC without infra doing some serious scaling work
16:09:58 <sgallagh> I mean, isn't EOL really only meaningful to the build system and bodhi?
16:10:00 <bowlofeggs> sgallagh: isn't this data *for* the client?
16:10:08 <bowlofeggs> sgallagh: oh i thought it was for the end user to know
16:10:17 <sgallagh> bowlofeggs: At present, none of this is presented to the user
16:10:31 <bowlofeggs> sgallagh: so i could know "this django version i'm using will only be supported until XYZ"
16:10:49 <bowlofeggs> sgallagh: i don't know of a way that bodhi directly uses this info either
16:10:53 <bowlofeggs> maybe pungi does?
16:11:00 <bowlofeggs> (and bodhi uses pungi)
16:11:04 <sgallagh> bowlofeggs: Well, Bodhi I could see refusing to submit an update for an EOL stream
16:11:11 <sgallagh> Not that it does today, but I could see that happening
16:11:16 <bowlofeggs> ah i see
16:11:19 <bowlofeggs> yeah
16:11:34 <bowlofeggs> but wouldn't you want end users to get notice they are using EOL packages?
16:11:48 <bowlofeggs> otherwise they dont' get updates and don't realize it
16:11:55 <sgallagh> bowlofeggs: Want to? Sure. Have a meaningful way of reporting it? Nope.
16:12:15 <bowlofeggs> i guess my surprise here is that i thought that was the main purpose of this field
16:12:22 <jforbes> Yes, that is the critical piece. We don't want end users thinking something is supported when it isn't and end up exposed to a big security hole
16:12:26 <bowlofeggs> the bodhi/koji side of it seems secondary to me
16:12:31 <sgallagh> bowlofeggs: I think this field has changed purposes several times
16:12:45 <sgallagh> But realistically, we can't represent this information to an Ansible user, for example.
16:12:52 <bowlofeggs> true
16:12:54 <sgallagh> (Short of denying the installation)
16:13:05 <bowlofeggs> but dnf could print warnings for CLI users at least
16:13:10 <bowlofeggs> and GUI users could get warnings too
16:13:16 <sgallagh> Perhaps
16:13:24 <bowlofeggs> to me, that's far more important than stopping builds from happening
16:13:32 <bowlofeggs> in fact, i dont' see a real purpose in stopping builds from happening
16:13:34 <sgallagh> Oh, I don't disagree.
16:13:38 <sgallagh> We just don't have a good answer for it.
16:13:53 <bowlofeggs> so i dont' see the point of this field outside of informing the end user
16:14:10 <mhroncok> we remove packages between Fedora releases
16:14:23 <mhroncok> how is this different?
16:14:36 <sgallagh> mhroncok: It's really not
16:14:51 <sgallagh> If you upgrade to F30 and a package you were using goes away, you still have the old package there, warts and all
16:14:57 <mhroncok> I guess that really goes back to my question ont he ticket
16:15:11 <sgallagh> Yes, maybe we can make it a little nicer/more visible, but I don't think it's fully solvable
16:15:12 <nirik> unless it's got broken deps or somehing
16:15:12 <mhroncok> do we remove the packages or keep them? both is bad
16:15:17 <sgallagh> Right
16:15:41 <mhroncok> and I think we only need to figure out how to do this consitently with nonmodular Fedora
16:15:52 <zbyszek> I'll have to leave 20 past the hour. Apologies.
16:17:28 <bowlofeggs> well that removal happens between fedora releases, not in the middle of a release. so yeah, i guess as long as we use fedora releases as the EOL date that becomes similar to what we do now
16:17:37 <sgallagh> I think we should try to move on, but can I summarize the discussion and move it to the ticket?
16:17:59 <asamalik> could we just have some sort of an audit command that would check the EOLs and report it back to the user? without making any physical restriction?
16:18:12 <asamalik> so they'd have the info and they could do what they think is best
16:18:25 <bowlofeggs> sgallagh: sure
16:18:27 <sgallagh> I think we generally agree that we would like to tie EOL to Fedora releases and RHEL minor releases while also retaining module stream expansion for both together. How we do this and how we report and store these EOLs needs more discussion.
16:18:31 <sgallagh> Reasonable summary?
16:18:40 <asamalik> combined with a policy preventing EOLs mid-release I think that would work nicely
16:19:10 <jforbes> Seems a good summary
16:19:17 <mhroncok> sgallagh++
16:19:19 <zodbot> mhroncok: Karma for sgallagh changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:19:30 <asamalik> sgallagh: +1
16:19:50 <sgallagh> asamalik: The audit tool would be a good idea as well. Let's take that back to the ticket and discuss it further
16:19:58 <sgallagh> #info We generally agree that we would like to tie EOL to Fedora releases and RHEL minor releases while also retaining module stream expansion for both together. How we do this and how we report and store these EOLs needs more discussion.
16:20:11 <zbyszek> Ack.
16:20:17 <asamalik> sgallagh++
16:20:26 <otaylor> sounds good +1
16:20:43 <sgallagh> #topic #2028 RFC: Stream branch ownership for packages & modules
16:20:43 <sgallagh> .fesco 2028
16:20:45 <zodbot> sgallagh: Issue #2028: RFC: Stream branch ownership for packages & modules - fesco - Pagure.io - https://pagure.io/fesco/issue/2028
16:20:58 <sgallagh> I'm sure this one will go *much* quicker :V
16:21:04 <mhroncok> :D
16:21:32 <asamalik> so I wanted to entertain the possibility of only defining module stream branch ownership, and having the package stream branch ownership be implicit
16:21:40 <sgallagh> Personally, I think the short version here is "We need pkgdb-like functionality back"
16:21:55 <mhroncok> pretty much
16:22:00 <asamalik> but what I feel from the ticket is that people would prefer explicit package stream branch ownership for various reasons
16:22:09 * sgallagh nods
16:22:34 <asamalik> sgallagh: we do!
16:22:35 <otaylor> asamalik: my take is that this too confusing, and depending on something shouldn't be acls/ownership
16:23:05 <sgallagh> Yeah, I think this is better solved with branch ownership.
16:23:51 <mhroncok> BTW I've put branch ownership to the contributor experience objective wiki page
16:23:58 <asamalik> otaylor: sorry, I couldn't parse that
16:24:35 <sgallagh> asamalik: I think he means that having ownership derive from dependencies is confusing an unintuitive
16:24:44 <mhroncok> asamalik: too magical :D
16:24:55 <asamalik> sgallagh: ah, sure, I'm not against that
16:25:02 <otaylor> asamalik: Sorry, just meant to say "ownership should be explicit"
16:25:21 <asamalik> I was just trying to find a solution with minimal "paperwork" if you will
16:25:31 <asamalik> but sure, agree it's kind of confusing
16:26:26 <sgallagh> So, are we more or less in agreement that mhroncok's going to add back ACLs to Fedora? :-D
16:26:31 <asamalik> so I hear we need 1) mechanics to define branch ownership and 2) explicit module branch ownership as well as explicit package branch ownership
16:26:34 <otaylor> asamalik: What was your main concern here - the module with a lot of packages all owned/streamed together with the module?
16:26:42 <asamalik> sgallagh: that's how I understand it, yes :D
16:28:08 <otaylor> I'm not sure we should rush into definining this as branch ownership. It's one case (somone wants to pick up nodejs:8 after the maintainer loses interest), but not the only case.
16:28:15 <asamalik> otaylor: my primarily motivation wasn't a concern, just the assumption that that if you own a module that contains a package, you also maintain it. And also the fact that there is no reason for a package stream branch to exist if it's not in a module. So adding explicit ownership seemed unnecessary to me.
16:28:22 <mhroncok> sgallagh: as long as you prepa a spearate koji stack for the previous ticket  :D
16:28:50 <asamalik> otaylor: ah, you were talking about branch ownership, sorry.
16:28:50 * sgallagh tweaks DNS to make it look like there's a new infrastructure domain.
16:30:09 <sgallagh> Do we have anything to vote on here or shall we take this back to the ticket for more discussion?
16:30:30 <asamalik> otaylor: I can easily see different people maintaining different streams. Having shared permissions/ownership would somehow force them to collaborate/agree on things. There might be cases that's not desired and there could be a conflict. But maybe I'm just too negative here.
16:30:38 <sgallagh> I'd like to get to the new business before midnight in the EU :)
16:31:08 <mhroncok> sgallagh: so, plenty of time for this one :)
16:31:19 <otaylor> sgallagh: Sounds like back to the ticket - I don't think there's support for the exact proposal in the ticket.
16:31:34 <mhroncok> +1 for no voting. oh...
16:31:57 <sgallagh> Motion to defer
16:32:01 <asamalik> I think I'll take the action to update the proposal with 1) mechanics to define branch ownership and 2) explicit module branch ownership as well as explicit package branch ownership
16:32:14 <asamalik> EOF
16:32:21 <nirik> sounds good
16:32:30 <jforbes> +1 to defer
16:32:33 <mhroncok> asamalik++
16:32:33 <zodbot> mhroncok: Karma for asamalik changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:32:41 <sgallagh> #action asamalik will update the proposal with 1) mechanics to define branch ownership and 2) explicit module branch ownership as well as explicit package branch ownership
16:32:43 <asamalik> cookies for everyone!!!
16:32:55 <sgallagh> #info deferring further discussion to the next meeting
16:33:02 <sgallagh> #topic #2044 F30 Change: krb5 crypto modernization
16:33:02 <sgallagh> .fesco 2044
16:33:02 <sgallagh> #agree DECISION (+X, Y, -Z)
16:33:05 <zodbot> sgallagh: Issue #2044: F30 Change: krb5 crypto modernization - fesco - Pagure.io - https://pagure.io/fesco/issue/2044
16:33:33 <nirik> there were some more questions on the list...
16:33:44 <asamalik> thanks all!
16:33:44 <nirik> dunno if they got answered yet
16:33:45 * asamalik leaves
16:33:47 <sgallagh> So, I'll admit that my eyes crossed a bit reading through the devel list thread, but I gather that rharwood wants to remove algorithms more aggressively than upstream?
16:34:11 <sgallagh> I worry a bit about what that might mean for interoperability.
16:35:24 <sgallagh> And yes, I see zbyszek asked some new questions shortly before this meeting.
16:36:07 <sgallagh> Should we punt until we get answers?
16:36:17 <nirik> +1
16:36:24 <jforbes> +1
16:36:38 <bowlofeggs> +1 to punt
16:36:55 <sgallagh> If Robbie is in Brno next week, I'll try to sit down with him in person and hash this out.
16:37:14 <sgallagh> #info punting to await answers to questions on the mailing list
16:37:32 <sgallagh> #topic #2051 Backport Fish 3.0 to F29
16:37:32 <sgallagh> .fesco 2051
16:37:34 <zodbot> sgallagh: Issue #2051: Backport Fish 3.0 to F29 - fesco - Pagure.io - https://pagure.io/fesco/issue/2051
16:37:43 <bowlofeggs> i just searched to see if "punt" really means the way we use it in english, and it has a surprising number of definitions: https://www.merriam-webster.com/dictionary/punt
16:38:00 <sgallagh> I always assumed it was related to sportsball
16:38:11 <bowlofeggs> yeah me too
16:38:14 <bowlofeggs> it probably is
16:38:24 <bowlofeggs> but it can mean things about boats and wine bottles?
16:38:33 <sgallagh> aaanyway
16:39:14 <sgallagh> As I was observing to Matthew Miller the other day, sometimes working in open source can be really weird. Like receiving a message with the subject line "Backporting fish"
16:39:19 <bowlofeggs> on fish, i'm still of the opinion that it can be in a module or copr, otherwise can wait for f30
16:39:30 <bowlofeggs> haha
16:39:45 <sgallagh> I'm inclined to agree. The backwards-incompatible change list looks concerning to me.
16:39:52 <bowlofeggs> if i were a fedora user relying on the old behavior, i would be upset at this
16:39:59 <otaylor> As long as fish is just a sysadmin tool and nothing is depending on it in the distro, I think it's up to the maintainer.
16:40:01 <bowlofeggs> (i'm not a fish user, just thinking theoretically)
16:40:16 <sgallagh> otaylor: We have specific rules about stable updates for all packages
16:40:18 <bowlofeggs> otaylor: i don't agree with that, since users may have fish scripts
16:40:25 <bowlofeggs> and we can't know what their scripts are doing
16:40:25 <sgallagh> And it's a scripting language that has changed semantics
16:40:33 <sgallagh> I think it would annoy users of it greatly
16:40:40 <otaylor> I don't feel I have enough context about how people use fish to know whether people write scripts or not.
16:40:51 <bowlofeggs> we wouldn't do something liek this for python
16:40:53 <otaylor> The changes did sound concerning to me - like scripts breaking in unexpected ways
16:41:08 <sgallagh> We have modules and COPRs as alternatives these days.
16:41:12 <bowlofeggs> yeah, it's a shell/scripting language
16:41:13 <otaylor> bowlofeggs: it would clearly be a *nope* for python or bash
16:41:16 <jforbes> Yeah, I am inclined to -1 this one
16:41:31 <bowlofeggs> -1
16:41:49 <sgallagh> Proposal: FESCo does not grant an exception to the stable updates policy for 'fish' and recommends the use of a module stream or COPR repository instead.
16:41:56 <bowlofeggs> sgallagh: +1
16:42:00 <sgallagh> +1
16:42:04 <jforbes> +1
16:42:07 <bowlofeggs> (i do approve it for F30, fwiw ☺)
16:42:14 <nirik> +1
16:42:24 <mhroncok> +1
16:42:29 <sgallagh> bowlofeggs: We don't need to rule on that. That's maintainer's prerogative
16:42:50 <bowlofeggs> (also, fish is pretty cool. i did use it for a while. i like it a lot more than bash/zsh, though i switched back because it's easier to find things that integrate with bash)
16:42:52 <sgallagh> #agreed FESCo does not grant an exception to the stable updates policy for 'fish' and recommends the use of a module stream or COPR repository instead. (+5, 0, -0)
16:42:53 <otaylor> +1
16:42:53 <mhroncok> Also, we should thank ignatenkobrain for even asking. I can imagine others would juts push it and be done with it :D
16:42:58 <sgallagh> #undo
16:42:58 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:42:52 : FESCo does not grant an exception to the stable updates policy for 'fish' and recommends the use of a module stream or COPR repository instead. (+5, 0, -0)
16:43:02 <sgallagh> #agreed FESCo does not grant an exception to the stable updates policy for 'fish' and recommends the use of a module stream or COPR repository instead. (+6, 0, -0)
16:43:06 <bcotton> ignatenkobrain++
16:43:06 <zodbot> bcotton: Karma for ignatenkobrain changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:43:11 <sgallagh> mhroncok: Agreed.
16:43:17 <bowlofeggs> mhroncok: indeed
16:43:19 <sgallagh> ignatenkobrain: Thanks for checking in on this :)
16:43:20 <bowlofeggs> ignatenkobrain++
16:43:24 <sgallagh> ignatenkobrain++
16:43:24 <zodbot> sgallagh: Karma for ignatenkobrain changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:43:36 <sgallagh> #topic Next week's chair
16:43:55 <mhroncok> would anybody be willing to guide me trough that?
16:44:04 <sgallagh> I may or may not make it next week; I'll be just arriving at my hotel in Brno around the time this starts.
16:44:08 <bowlofeggs> i'm not sure if i can be here next week
16:44:11 * nirik too
16:44:13 <sgallagh> mhroncok: https://fedoraproject.org/wiki/FESCo_meeting_process
16:44:20 <bowlofeggs> we have a team meeting during this time slot
16:44:30 <bowlofeggs> and i will be gone the following week for sure
16:44:33 <mhroncok> BTW I don't think I can tag issues
16:45:00 <sgallagh> mhroncok: Probably we haven't made you an admin on the repo yet
16:45:05 <bowlofeggs> mhroncok: maybe someone needs to add you to a pagure and/or fas group?
16:45:07 * nirik meant to add folks, can do that
16:45:16 <mhroncok> nirik: thanks
16:45:42 <mhroncok> should we deliberately cancel next week?
16:46:10 * sgallagh also notes he *definitely* will not be available the week after, as he'll be in-flight
16:48:22 <nirik> do we have any chance of quorum?
16:48:23 <bowlofeggs> will anyone be here next 2 weeks?
16:48:39 * mhroncok will be
16:48:43 * otaylor will be travelling both next monday and the week after
16:49:09 <mhroncok> I guess contyk mostl likely wonẗ be travling to/from devconf either
16:49:12 <jforbes> I will be here
16:49:27 <sgallagh> I will try to be available for next week, but I can't be absolutely certain
16:49:30 <otaylor> (*might* be able to make it next monday, like sgallagh, it's about the time I'm arriving at my hotel)
16:50:54 <bowlofeggs> sounds like maybe 3 people so maybe we should just say we meet next in 3 weeks?
16:50:56 <sgallagh> Looks like there's at least a chance of quorum, so let's try for it and see what happens?
16:51:01 <bowlofeggs> or that
16:51:07 <bowlofeggs> you could just host the meeting and see who comes
16:51:18 <bowlofeggs> it's a possibility i can do it, but i have a team meeting so seems unlikely
16:51:41 <bowlofeggs> sounds like the following week is less likely
16:51:57 <sgallagh> bowlofeggs: You can just .hello2 and then hand your proxy to me. I'm trustworthy ;-)
16:52:33 <mhroncok> the question is, how can we trust that you are trustworthy?
16:52:43 <sgallagh> I have this certificate I made!
16:52:53 <mhroncok> and you self signed it
16:52:57 <jforbes> seems legit
16:52:59 <mhroncok> anyway, I can do the next week meeting
16:53:07 <bowlofeggs> sgallagh: haha
16:53:11 <mhroncok> and just see if it will happen
16:53:25 <sgallagh> mhroncok: I literally wrote the book on how to improve self-signing :-D
16:53:27 <bowlofeggs> self signed certificates are easy to fix: you just mark them trusted in yuor browser!
16:53:31 <mhroncok> I'll read the docs and cry for help if I need it
16:54:32 <sgallagh> #action mhroncok to chair 2019-01-21 meeting
16:54:37 <sgallagh> #topic Open Floor
16:54:41 <sgallagh> Anything for Open Floor?
16:54:45 <sgallagh> (please say no)
16:54:52 <besser82> Well…
16:54:56 <bowlofeggs> i've been thinking that we need to come up with ways to make our meetings longs
16:54:58 <bowlofeggs> *longer
16:55:08 <sgallagh> Actually cverna had something I think
16:55:24 <cverna> it can wait for next meeting since you all had a long one today
16:55:29 <sgallagh> mhroncok: BTW in case you thought I was lying: https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-why-they-are-terrible-and-a-better-alternative/
16:55:30 <mhroncok> bowlofeggs: just vote -1 on random tickets that seem to be getting close to getting approved
16:55:58 <mhroncok> sgallagh: you've just wrote that now to impress me.
16:56:01 <sgallagh> cverna: It's possible that will be in three weeks, so best you ask now
16:56:10 <sgallagh> mhroncok: I'm good, but not *that* good
16:56:16 <besser82> Since the next two weks meetings seem to be not certain, yet…  I'd like to ask about https://pagure.io/fesco/issue/2052
16:56:32 <besser82> Current state is +5 in the ticket.
16:56:49 <bowlofeggs> mhroncok: haha
16:56:53 <besser82> Needs another +2 to be approved…
16:57:07 <sgallagh> besser82: Actually, it needs either another +2 or just five days to pass
16:57:10 <mhroncok> besser82: and couple of days as well
16:57:17 <mhroncok> or
16:57:34 <cverna> Ok my open floor question/ticket is about https://pagure.io/fesco/issue/2049
16:57:39 <sgallagh> besser82: Are you here to ask us to pass it quicker or to argue against it?
16:57:40 <cverna> container update policy
16:57:48 <mhroncok> besser82: btw python34 and 35 now build, so you can retest them in that copr
16:57:52 <besser82> sgallagh, pass it quicker
16:57:54 <sgallagh> ok
16:58:12 <besser82> mhroncok, then they will build with that change as well
16:58:28 <sgallagh> otaylor, bowlofeggs : If you two agree, please +1 the ticket so they can move ahead
16:59:40 <besser82> and bcotton needs to give me a tracking bug, so Ican reference the rhbz# when bumping / rebuilding ~154 Packages
16:59:47 <bowlofeggs> sgallagh: I +1'd (hadn't seen it before now, sorry ☺)
17:00:06 * otaylor adds his +1 (not entirely sure about the idea of using compat libraries to enforce security policies, but won't make things worse than the status quo)
17:00:31 <besser82> otaylor, the compat lib is kept for POSIX-requirements
17:00:36 <sgallagh> Thanks
17:00:43 <sgallagh> besser82: OK, it's approved
17:01:05 <besser82> sgallagh++
17:01:05 <zodbot> besser82: Karma for sgallagh changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:11 <sgallagh> #topic Container update policy update
17:01:11 <sgallagh> .fesco 2049
17:01:12 <zodbot> sgallagh: Issue #2049: Container update policy update - fesco - Pagure.io - https://pagure.io/fesco/issue/2049
17:01:14 <bcotton> besser82: i'll process it this afternoon and you'll get your tracking bug then
17:01:20 <besser82> mhroncok++
17:01:20 <zodbot> besser82: Karma for churchyard changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:27 <besser82> otaylor++
17:01:27 <zodbot> besser82: Karma for otaylor changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:35 <besser82> bowlofeggs++
17:01:35 <zodbot> besser82: Karma for bowlofeggs changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:37 <besser82> bcotton++
17:01:38 <zodbot> besser82: Karma for bcotton changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:52 <sgallagh> cverna: You have the floor
17:01:59 <mhroncok> cverna: let's dance
17:02:09 <bowlofeggs> ok so on the container topic, i must admit that i don't have a lot of bandwidth to add the buildroot overrides to containers right now, though i do know what needs to happen to make it work
17:02:23 <bowlofeggs> so i could advise someone who did have time to work on it, review pull request, etc.
17:02:32 <bowlofeggs> just can't do it myself for now
17:02:47 * cverna puts shiny shoes to hit the dance floor
17:02:53 <bowlofeggs> i do feel like that would be better than not having testing time on containers
17:03:23 <cverna> I think this is more than just buildroot overrides
17:03:24 <bowlofeggs> though i also find cverna's counter argument that users can more easily run older containers than older RPMs to be a moving argument
17:03:47 <cverna> some containers will not need buildroot override and it does not make sense to have to wait 7 days to release
17:03:53 <mhroncok> why do we have that 1 day in bodhi? it clearly makes pretty much the same sense as bypassing bodhi entirely
17:04:07 <nirik> if CI is good enough... yeah...
17:04:17 <cverna> mhroncok: long term plan for me is to bypass bodhi once we have ci
17:04:29 <cverna> be the CI is not in place yet
17:04:35 <cverna> so this is a middle ground
17:04:38 <mhroncok> but as long as CI is in it's current state
17:04:46 <mhroncok> what good does the 1 day bodhi thing brings?
17:04:49 <bowlofeggs> why would CI make the difference on whether bodhi is used or not?
17:04:50 <mhroncok> other than 1 day delay
17:04:50 <otaylor> The other thing that is different about containers, is that a container update may have *nothing* to do with the containers actual functionality, it may be picking up a security fix from the base package set.
17:05:00 <otaylor> So asking people to test and karma is a lot of overhead
17:05:10 <cverna> mhroncok: I can because we can't do 0 days
17:05:27 <sgallagh> Regarding CI: couldn’t you just create a FAS user for CI to give it Bodhi karma?
17:05:35 <sgallagh> Then set the auto push to 1?
17:05:36 <mhroncok> :D
17:05:53 <mhroncok> or just set karma to push to 1 and ask sgallagh to give the karma
17:05:56 <bowlofeggs> sgallagh: i actually had considered doing something like that for rawhide gating
17:06:05 <bowlofeggs> rawhide will be very similar to what cverna wants
17:06:09 <sgallagh> bowlofeggs: I’m in favor
17:06:29 <cverna> I wish we could also have automated updates for containers
17:06:36 <bowlofeggs> for rawhide,i decided to just make it possible t have a policy that doesn't require karma and autopushes when ci passes
17:06:43 <otaylor> cverna: I don't want this policy change for Flatpaks, but I assume this is configured at the bodhi release level?
17:06:45 <bowlofeggs> so i think cverna could use that same implementation
17:06:57 <bowlofeggs> otaylor: yes, per release
17:07:00 <mhroncok> why is bodhi used here at all?
17:07:00 <cverna> otaylor: yes it would be
17:07:35 <bowlofeggs> for example, this ticket seems relevant: https://github.com/fedora-infra/bodhi/issues/2321
17:07:55 <bowlofeggs> mhroncok: well bodhi is the update gating mechanism for fedora, and this is about gating updates
17:08:18 <mhroncok> the requests seems to be about opening that gate
17:08:24 <mhroncok> *request
17:08:49 <mhroncok> I just don't see the point of having it in bodhi for one day. is this a temporary workaround before CI works better?
17:09:19 <nirik> well, without bodhi there's not a place to display the CI?
17:09:23 <bowlofeggs> i think we could make it faster than 1 day once bodhi's CI gating stuff is better
17:09:26 <cverna> I would be glad to have 0 days, I am just not sure if that is possible
17:09:40 <otaylor> mhroncok: it would still be in bodhi even if it was in there for 0 days, I think - bodhi is the place that handles moving things around and recording what is in where and why
17:09:46 <bowlofeggs> we will want faster than a day for rawhide too probably
17:10:34 <mhroncok> so basically what we want is "no time gating for containers", possibly use "1 day" as a wrokaround until that possible?
17:10:50 <bowlofeggs> the only reason we compose once a day right now is because it's hard on the mirrors if we compose too frequently. but i can see a use case for making compose frequency by a per-release setting
17:11:10 <otaylor> bowlofeggs: we discussed that we can compose containers/flatpaks without that issue
17:11:13 <cverna> mhroncok: yes
17:11:28 <mhroncok> cverna: thanks for clarifying
17:11:28 <bowlofeggs> mhroncok: in the ideal case, sure. but as it is, do we really have CI on all our stuff to make this actually ok?
17:11:43 <bowlofeggs> otaylor: yeah exactly
17:12:11 <mhroncok> I guess I'm OK with that
17:12:34 <bowlofeggs> i'm concerned about the mismatch between reality and the idea of having CI
17:12:58 <bowlofeggs> the reality being that the test coverage isn't great right now
17:13:07 <bowlofeggs> so voting on this seems a bit premature to me
17:13:26 <cverna> bowlofeggs: We currently have ~30 containers so CI all of them will not be so hard
17:13:37 <cverna> at least basic test does the container start
17:13:44 <mhroncok> "will not be so hard"
17:13:50 <mhroncok> again, can we make it a requirement?
17:13:57 <bowlofeggs> CI'ing my one bodhi container has been quite difficult
17:14:06 <cverna> what is currently missing from the CI pipeline is the reporting back to greenwaves etcc
17:14:12 <bowlofeggs> though i'm testing far more than whether it starts
17:15:17 <bowlofeggs> i did consider making a bodhi feature where the required time in testing depends on whether there are CI tests or not
17:15:31 <bowlofeggs> it could be cool, though some people might game it and just run /bin/true
17:15:33 <cverna> yes it is up to the maintainers but I think have at least one test that check that the container starts with the command documented in the USAGE label is the minimun
17:16:26 <sgallagh> bowlofeggs: There are many ways people could game the system today. They generally don't
17:16:32 <bowlofeggs> true
17:16:33 <sgallagh> I'd not optimize for bad actors
17:16:35 <cverna> and once again I think that a container that does not work is not a big deal, it will not crash your system
17:16:40 <otaylor> I don't think that relying on some fictional group of Feodra container testers to test containers makes sense
17:16:56 <bowlofeggs> sgallagh: well i'm not optimizing, it was just a counter point in my head. the other counter point is that it makes the policy more complicated ☺
17:17:28 <cverna> otaylor: true, I am not even sure we have container users except from the base image tbh
17:17:30 <sgallagh> bowlofeggs: Depends how it's implemented. You could just give approved CI sources the right to add +10 to karma...
17:17:31 <bowlofeggs> and having just one test doesnt' mean it's a useful test, is the other counter point
17:17:52 <bowlofeggs> even if well intentioned, one test could still be poor quality
17:18:20 <sgallagh> bowlofeggs: That's still probably better than most of the karma things get today.
17:18:33 <sgallagh> A lot of them are just "it didn't obviously break, so +1!)
17:18:39 <bowlofeggs> sgallagh: except for -1's. those are often useful (except the kernel, haha)
17:18:57 <bowlofeggs> and a poor quality CI would be no better than "works for me!"
17:19:09 <sgallagh> bowlofeggs: But no *worse* either
17:19:10 <bowlofeggs> and i would actually argue is worse
17:19:18 * sgallagh shrugs
17:19:19 <bowlofeggs> because at least a "works for me" is a person really useing it to realyl do soemthing
17:19:46 <mhroncok> bowlofeggs: I sometimes doubt that they actually did something at all
17:19:48 <bowlofeggs> a CI that just checks "does this process start" is doing much less than most "works for me" testers
17:20:12 <bowlofeggs> mhroncok: i think that's true in some cases, but i also personally test packages and i usually check for more than whether it starts
17:20:21 <bowlofeggs> and my message often ends up being "works for me"
17:20:45 <mhroncok> bowlofeggs: protip: write at least a bit what have you tested ;)
17:20:47 <mhroncok> anyway
17:20:52 <bowlofeggs> mhroncok: ☺
17:20:56 <mhroncok> the discussion is going nowhere
17:21:06 <sgallagh> bowlofeggs: On at least three occasions, I've had packages get +3 karma between me submitting them and noticing that it didn't work *at all* (usually less than a half-hour)
17:21:14 <bowlofeggs> i don't think we're at a state of CI where i feel comfortable with the proposal
17:21:24 <mhroncok> it's far from midnight in the EU, so sgallagh has time
17:21:35 <sgallagh> sgallagh would love lunch though
17:21:48 <bowlofeggs> sgallagh: yeah i don't disagree that a lot of people don't do a good job. i'm just argueing that "does the process start" is worse than average
17:22:34 <bowlofeggs> i would like to think through a policy that allows packages with "good CI" to get a faster turnaround, but defining "good CI" is hard
17:23:02 <sgallagh> bowlofeggs: I default to assuming that the maintainer can be trusted.
17:23:10 <bowlofeggs> and configuring bodhi to detect teh difference between good CI and not-good CI is also a hard problem
17:23:22 <mhroncok> the maintainer can be trusted only if they have the certificate
17:23:24 <sgallagh> If they click a button that says "I trust my CI", I think we should believe them unless proven otherwise
17:23:30 * sgallagh slaps mhroncok
17:23:45 <bowlofeggs> maintainers regularly break the backwards incompatibility update policy
17:23:46 <cverna> I think we are going a bit off topic, I don't intend to define what good CI is or should be
17:23:58 <bowlofeggs> i'm not sure i would agree that they don't need guard rails
17:24:13 <mhroncok> the discussion is still going nowhere
17:24:15 <cverna> and again I might be a bit to careless, but a broken container as a user does not bother me too much
17:24:28 <cverna> I can use the previous working tag and open a bugzilla
17:24:45 <cverna> it will not break my system compared to packages
17:25:02 <bowlofeggs> yeah it does seem less severe than for RPMs
17:25:14 <bowlofeggs> though new users of the package won't know to do that
17:25:21 <bowlofeggs> (edge case)
17:25:33 <sgallagh> cverna: Any way we can automatically include a "last-week" alias on a container?
17:25:53 <sgallagh> So each time you push a new one, the previous one gets a standard tag?
17:26:03 <sgallagh> So it makes rollback easier for beginners?
17:26:14 <cverna> sgallagh: the tags are versions except for latest
17:26:23 <bowlofeggs> sgallagh: well then you have to know how often people update
17:26:25 <sgallagh> oh ok
17:26:33 <sgallagh> I was thinking they were just hashes
17:26:43 <sgallagh> If they have human-readable names already, I'm good with that
17:26:55 <cverna> for example https://registry.fedoraproject.org/repo/f29/origin-base/tags/
17:26:56 <sgallagh> I was just aiming for maximum simplicity
17:28:17 * nirik has to go...
17:28:33 <cverna> Overall my point is that currently we have container updates that are not tested and just wait 7 days for nothing
17:28:35 <sgallagh> So, this conversation does not appear to be circling in on a decision, so shall we send it back to the ticket?
17:29:03 <sgallagh> cverna: And getting them testing isn't an option?
17:29:14 <sgallagh> You can't just have members of your team give karma?
17:29:22 <sgallagh> (After testing, of course)
17:30:03 <mhroncok> I don't think that "nobody tests this" is good enough reason
17:30:19 <cverna> We are 3-4 active member in the container SIG so giving +3 Karma would mean that we all have to spend some time testing them
17:30:22 <mhroncok> however "testing is not needed, because <reasons>" works for me
17:30:34 <mhroncok> cverna: it doesn't have to be 3
17:30:50 <cverna> so I gave my reason why I think testing for container is not that important
17:30:54 <cverna> reasons*
17:31:37 <mhroncok> you did
17:31:46 <sgallagh> cverna: My suggestion would be to lower the karma threshold to 1 and just have at least one of you do some testing
17:31:58 <sgallagh> Then it will get autokarmaed in a day AND have actual testing
17:32:20 <cverna> I guess that could work, can we configure bodhi to default to a +1 karma ?
17:32:30 <mhroncok> cverna: you can set the carma
17:32:32 <mhroncok> karma
17:32:36 <sgallagh> Default, no. But it's an option when you create the update
17:32:37 <bowlofeggs> cverna: it doesn't have settings, but you can set it on updates
17:32:40 <cverna> that's overhead
17:32:44 <sgallagh> Either in the UI or via the API
17:32:45 <mhroncok> seriously?
17:33:14 <mhroncok> either you do it by hand and it's very little difference
17:33:15 <jforbes> That is one extra drop down box to set when filing the update, I wouldn't consider it "overhead"
17:33:17 <cverna> mhroncok: we have already very little people interested in maintaining containers I would like it to be as painless as possible
17:33:22 <mhroncok> or you have it scripted and it's very little difference
17:34:00 <mhroncok> bowlofeggs: generally having karma limits presets would be nice feature
17:34:03 <sgallagh> cverna: This *is* as painless as possible
17:34:25 <mhroncok> however I don't think this is a big deal
17:34:41 <cverna> bowlofeggs: can we edit the karma after the update was submitted ?
17:34:43 <sgallagh> cverna: Just write a doc showing how to use the bodhi CLI with the --karma flag (or whatever it is) to create the update
17:34:48 <sgallagh> cverna: Yes
17:34:53 <bowlofeggs> mhroncok: yeah, though i can't commit to making that feature due to $time - i would accept a PR for it though ☺
17:35:01 <bowlofeggs> cverna: yeah it can be edited
17:35:07 <sgallagh> But it will ignore you if you retroactively set it down to lower than the current value, I've noticed
17:35:16 <mhroncok> bowlofeggs: well, the bloody pyramid, I'm not sure I want to understand that code :D
17:35:26 <sgallagh> Or rather, it will change the maximum but not immediately queue it.
17:35:26 <cverna> ok that should be ok then even tho karma per release would be better :)
17:35:28 <sgallagh> That may be a bug
17:35:40 <bowlofeggs> sgallagh: it ignores until someone else karmas it (i've noticed this too)
17:35:49 <bowlofeggs> probably it shouldn't do that, but oh well
17:35:51 <bowlofeggs> haha
17:36:02 <mhroncok> I tought that's a protection against cheating
17:36:13 <mhroncok> bowlofeggs: call it a feature
17:36:15 <bowlofeggs> mhroncok: yeah pyramid isn't awesome, though honestly this particular feature wouldn't require knowing pyramid at all
17:36:33 <bowlofeggs> mhroncok: haha
17:36:36 <sgallagh> cverna: Is that sufficient for you to get on with for now?
17:36:43 <sgallagh> And then work towards sufficient CI?
17:36:44 <mhroncok> bowlofeggs: I'll submit a PR once I create the ACLs once sgallagh creates the separate koji
17:36:47 <cverna> yes I think that's good :)
17:36:49 <bowlofeggs> it's jsut that bodhi doesn't check the karma when that vlaue is changed, only when comments with karma are added
17:36:56 <mhroncok> cverna: \o/
17:36:57 <sgallagh> Great!
17:37:01 <bowlofeggs> so when you change it, bodhi doesn't check the count, it just updates it
17:37:18 <bowlofeggs> mhroncok: haha, i look forward to all of those then
17:37:25 <sgallagh> We don't need to debug that here. I was just giving cverna a heads-up :)
17:37:42 <mhroncok> set us free?
17:37:53 <cverna> thanks all
17:38:08 <sgallagh> #info FESCo makes no policy change but recommends a workaround of setting minimal autokarma
17:38:16 <sgallagh> Yeah, I think we're done.
17:38:19 <sgallagh> Thanks all.
17:38:22 <sgallagh> #endmeeting