15:01:12 #startmeeting FESCO (2019-01-14) 15:01:12 Meeting started Mon Jan 14 15:01:12 2019 UTC. 15:01:12 This meeting is logged and archived in a public location. 15:01:12 The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:12 The meeting name has been set to 'fesco_(2019-01-14)' 15:01:12 #meetingname fesco 15:01:12 #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor 15:01:12 #topic init process 15:01:12 The meeting name has been set to 'fesco' 15:01:12 Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek 15:01:17 hi 15:01:17 .hello2 15:01:18 .hello2 15:01:18 sgallagh: sgallagh 'Stephen Gallagher' 15:01:21 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:22 morning 15:01:22 .hello2 15:01:24 jforbes: jforbes 'Justin M. Forbes' 15:01:27 .hello2 15:01:28 otaylor: otaylor 'Owen Taylor' 15:01:31 .hello2 15:01:31 afternoon ;) 15:01:32 asamalik: asamalik 'Adam Samalik' 15:01:53 * asamalik is here to discuss #2027 and #2028 15:02:18 good morning and good afternoon! 15:02:40 .hello2 15:02:41 bcotton: bcotton 'Ben Cotton' 15:02:48 .hello2 15:02:54 bowlofeggs: bowlofeggs 'Randy Barlow' 15:04:05 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 #topic #2003 Ursa Major (modules in buildroot) enablement 15:04:15 .fesco 2003 15:04:19 sgallagh: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003 15:05:06 I want to throw out a contentious proposal here 15:05:21 * bowlofeggs readies his pitch fork 15:05:29 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 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 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 i would prefer it if we still have some high level requirements 15:07:12 sgallagh: What does "in fedora/epel" mean in this context? Enabled only for those buildroots? 15:07:27 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 (for example) 15:07:46 otaylor: I was going higher-level than that and just asserting that we permit it in the infrastructure. 15:07:47 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 That proposal means that FESCo abdicates the responsibility, and I'm not happy about that. 15:07:58 bowlofeggs: I don't think that is necessarily a blocker to doing this 15:08:06 sgallagh: EPEL doesn't have separate infrastructure... 15:08:08 I think it's absolutely an endgame requirement 15:08:26 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 otaylor: That's why it was a slash and not an OR 15:08:33 (working on memory) 15:08:43 sgallagh: Oh, I misunderstood the proposal then :-) 15:09:09 we are going to also have to work out mbs for epel8...without exposing rhel binries.... 15:09:12 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 sgallagh: Or, wait, I'm not sure which you were proposing ... is the / namespacing or "OR" ? 15:09:41 or "AND" ? 15:09:52 i personally think the ability to locally build is crucial 15:09:54 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 it saves so much time when trying to debug 15:10:19 otaylor: I think we're getting lost in the semanticshere. 15:10:29 That is fair, and I hate to block progress, but the local build requirement is also pretty critical 15:10:36 sgallagh: I have no idea what you proposed, sorry 15:10:41 bowlofeggs: I do not disagree that it is *highly desirable*. I disagree that it is absolutely mandatory 15:11:13 otaylor: I'll rephrase, maybe it will help 15:11:14 it makes an enormous difference when there is a build problem 15:11:38 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 some maintainers are eager to drop their nonmodular packages and they will do it 15:12:24 and suddenly, other maintainers are left in a very bad situation 15:12:31 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 What mhroncok says 15:12:56 Sorry sgallagh 15:12:57 sgallagh: are you thinking that there's no solution for local build that can be arrived at? 15:13:04 exisitng contributors bet nonexsisting epel 15:13:08 *beat 15:13:24 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 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 let's experiment withe pel8 without breaking Fedora? why is that wrong? 15:14:01 *epel8 15:14:11 with my EPEL hat on.. the local build is critical also 15:14:13 Wait, local build does work, there is no solution for automagically installing build deps 15:14:24 jforbes: Correct 15:14:25 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 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 otaylor: Local builds *can* be done, you just have to install your deps manually first 15:14:52 unfortunate, but not impossible 15:14:52 There's no "mock" equivalent today 15:15:59 I think we cannot break what doesn't exist 15:16:09 if we do this in EPEL first, we can figure out the problems as we go 15:16:28 there will be problems and there will be workarounds 15:16:30 sgallagh: is the plan that modules in UM must be in the modular repodata? 15:16:36 (no "buildroot only" modules) 15:16:42 with the way that the build system is interdependant.. is it possible to do it for EPEL and not Fedora? 15:16:45 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 otaylor: I think so, yes. That seems a reasonable restriction. 15:17:50 i feel like we've already allowed too many "cuts" on the packager workflow through in the past 1.5 years 15:17:59 this seems like a pretty deep cut 15:18:14 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 smooge: I think you should be able to configure UM only to be active for the EPEL8 tag 15:18:25 (thinking of the pkgdb retirement and all the features that were lost that nobody is adding back) 15:18:49 Somebody needs to put in the work and figure out the details to satisfy the requirements that have been voiced. 15:19:00 Pushing it down the road is not going to help that happen. 15:19:14 zbyszek: agreed. if we approve this, there will be no pressure to fix it later 15:19:19 it will be like the pkgdb situation 15:19:31 there is no pressure for anyone to fix those problems, and nobody is 15:19:48 there is an objective to now. ;) 15:19:51 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 yeah i see that, and i hope it is successful 15:20:16 bowlofeggs: That may be true, but we'd also probably still be on Trac at this point 15:20:18 but let's not go thatroad again 15:20:21 but we've had a long time of poor experiences because nobody stood up for packagers when that proposal was made 15:20:32 if we approve this now, we migth have an objective in 3 years to enbale local builds 15:20:57 As noted, there are active proposals for how local builds should work. 15:21:02 This *is* a priority already. 15:21:18 it should be a hard requirement 15:21:37 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 Does someone want to make that a proposal then? 15:22:15 E.g. "Ursa Major is forbidden in the Fedora (and EPEL) infrastructure until automatic local build dependencies are available" ? 15:22:42 I'd still be fine if we enable this in EPEL8 as an experiment 15:22:48 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 I'd prefer to phrase it positively 15:23:41 zbyszek: Why start now? (Sorry, but it's been a whole lot of stonewalling so far) 15:23:44 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 otaylor: An agreement between whom? 15:24:13 approved by fesco 15:24:27 Just wanted that to be clear 15:24:51 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 sgallagh: do i assume correctly you would be happier if that "appropriate packager workflow for local builds" would be better defined? 15:25:11 (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 well, it's only beta currently 15:25:35 yeah, that seems wrong 15:25:40 Sure, but it's still kind of odd 15:25:55 looking at modularity in Fedora and modularity in RHEL8, i think it make sense if we experiment in EPEL8 15:26:05 does seem against the 'upstream first' mantra, but it is also mostly motivated by epel 15:26:06 Yeah, I don't actually disagree. 15:26:07 nirik: also, by the time peole make use of this, it won't be beta anymore 15:26:10 It just *feels* backwards 15:26:32 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 perhaps but we can also do final differently with lessons learned 15:27:15 otaylor: Yeah, as I said, I don't disagree with the plan. It's just kind of unintuitive 15:27:45 ok so we have a few different proposals out there 15:28:12 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 otaylor: "Only default streams" is actually insufficient. 15:28:25 Because default streams CAN be incompatible with one another 15:28:44 I think EPEL Steering Committee should actually decide if it is being done in epel or not 15:28:44 So, ... we have a history of temporary solutions and soon-to-fixed deficiencies persisting for years. 15:28:45 bowlofeggs: yes. 15:28:46 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 bowlofeggs: FESCo oversees Infra to some extent. Adding new build infrastructure may affect both products 15:28:53 but we may recommend it? 15:28:56 *projects 15:29:28 I think we at least have to say "It's permissible" 15:30:08 I think so too 15:30:24 but I amen EPEL should make the decision whether to use this 15:30:32 Yes 15:30:33 i really am heavily concerned about allowing something with a "we'll fix it later" because of the history, especially recent 15:30:47 bowlofeggs: even in EPEL only? 15:31:08 bowlofeggs: I'm heavily concerned about going the other direction and disallowing experimentation at all. 15:31:29 mhroncok: yes 15:31:45 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 But we still allow them to bootstrap things in the official build system 15:32:01 sgallagh: shouldn't we experiment in copr etc. rather than in Fedora proper? 15:32:17 mhroncok: How do you experiment with the build system in a COPR? 15:32:18 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 zbyszek++ 15:32:28 sgallagh: Karma for zbyszek changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:33:00 sgallagh: or some experimntal Koji. what I'm trying to say is don't break contributor experience for experiments 15:33:02 Copr is not the place to experiment in my opinoin 15:33:10 zbyszek: I think someone needs to requirement collect, then line up the solutions 15:33:46 so it is true that EPEL 8 can't be built without Ursa Major? 15:33:56 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 s/epel8 installation/rhel 8 beta installation/ 15:34:24 otaylor: and since there is no experince now, i'm OK to allow that 15:34:26 bowlofeggs: In RHEL 8 beta, a large percentage of packages that might be used for building are available only as modules 15:34:43 So it would be impossible to build the majority of packages we'd want in EPEL without it. 15:34:53 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 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 zbyszek: Yeah, it's becoming increasingly clear that this needs to be me or contyk. 15:36:09 how hard would it be to set up a seperate koji+bodhi+pungi+everything-else+ursa-major for just EPEL-8 15:36:12 And since contyk cleverly dodged this meeting, I guess that means me 15:36:19 ha 15:36:34 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 nirik: Was that directed at me or smooge? :) 15:36:59 my reason for allowing it in EPEL 8 is the arguments that there can't be an EPEL 8 without it 15:37:03 sgallagh: at you. 15:37:21 bowlofeggs: exactly 15:37:26 a duplicate koji/bodhi/everything would be... a lot of work 15:38:34 OK, let me string together a couple proposals and see where we stand. 15:39:29 sgallagh++ 15:39:29 zbyszek: Karma for sgallagh changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:39:57 1: FESCo will permit standing up an Ursa Major instance to be configured for use only in EPEL 8 this time. 15:39:57 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 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 +1, sure 15:41:25 +1 to both, for the record 15:41:36 +1 to both 15:41:58 +1 for 2, -1 for 1. 15:42:07 +1 to both 15:42:30 I'd rather s/packager experience for local builds/packager experience/ - but it's not strong opinion. +1 to both 15:43:16 mhroncok: Well, I think we already know the centralized packager experience at least. 15:43:36 But I'll see if I can address both in my doc 15:43:58 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 i'm +1 to both 15:44:43 though, should we have the EPEL SIG make the final call on that? 15:45:00 bowlofeggs: That's why I said we'd permit it. Not mandate it 15:45:07 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 sgallagh: ah ok, that wording works for me then 15:46:27 #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 #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 #action sgallagh to gather requirements 15:46:34 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 Shall we move on? 15:47:13 yep 15:47:18 OK 15:47:25 #topic #2027 RFC: Module lifecycles 15:47:25 .fesco 2027 15:47:26 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 asamalik: That was your cue 15:49:43 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 That was my strong preference 15:50:16 so we won't have a situation when a module EOLs in the middle of a release 15:50:23 Yeah, I don't think there's any other realistic way to accomplish it when dates are malleable 15:50:45 PROPOSAL: 1. Module EOL is defined in git along with the rest of the definition of the module. 15:50:46 asamalik: Yes - you mean "module stream EOLs" though right? 15:50:48 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 asamalik: Not in Fedora, and in EPEL I think we can only reasonably tie it to minor RHEL releases. 15:51:17 otaylor: right 15:51:34 otaylor: thanks :) 15:52:14 zbyszek: that concerns you proposal as well 15:52:16 yeah i also prefer EOL being a release 15:52:25 zbyszek: it's a stream that eols 15:52:40 mhroncok: yep! 15:52:42 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 asamalik: well that's the current case anyway 15:53:04 oh yeah that's true, EPEL changes it maybe 15:53:05 asamalik: Can I try to rephrase that? 15:53:07 asamalik: I think that's fine and make sense for most streams 15:53:11 sgallagh: please! 15:53:26 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 I wonder if for EPEL we should allow date-EOL after all. 15:53:57 RHEL release schedule is not known in advance (publically). 15:54:03 yeah 15:54:05 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 makes sense 15:54:27 sgallagh: that sounds good 15:54:28 Which also could work for EPEL 15:54:34 sgallagh: that makes sense to me too 15:54:35 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 Since we don't need to know the schedule in advance. 15:54:46 sgallagh: +1 15:54:48 That seems fair 15:54:58 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 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 asamalik: would it be viable to set the EOL to an EPEL point release? 15:55:20 e.g. 8.2? 15:55:32 I think EPEL needs to come up with its own rules, but there may not be experience to do that yet 15:56:33 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 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 I both want and don't want to treat Fedora and EPEL as two different things in this regard 15:57:20 (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 otaylor: That policy decision hasn't been made yet, so far as I know 15:58:20 I'd lean towards suggesting that it should be impermissible though 15:58:42 asamalik: Hmm, do we expect modules to stream expand across Fedora and EPEL? 15:58:52 otaylor: We absolutely want that 15:58:57 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... 15:59:06 otaylor: yes 15:59:22 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 asamalik: my concern with dates was that it's too magical 16:00:05 the date was the only one working for both the same way, but it has its own issues 16:00:09 asamalik: setting a Fedora EOL via EPEL release number (or vice versa) is even more magical 16:00:17 mhroncok: I certainly have spent considerable mental cycles with the fedpkg request-branch trying to figure out what date I needed.... 16:00:23 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 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 I could see it being confusing... 16:01:01 asamalik: would it be painful to support "all of the above?" (date, fedora release, EL point release)? 16:01:08 Maybe we could just do a "season"? 16:01:10 and let the packager pick? 16:01:14 bowlofeggs: that was the initial idea, yes 16:01:29 (Well, picking a non-northern-hemisphere-oriented term) 16:01:34 Proposal: just support one, but have a well known web page with a table.... 16:01:46 bowlofeggs: but then we need to come up with rules what happens if a Fedora release slips 16:01:53 i.e. supported until Q1 2020 and that translates to the appropriate release in that timeframe 16:01:53 yeah 16:01:55 can we do it by game of thrones releases? 16:01:58 hahaha 16:02:06 mhroncok: Books or TV? "_ 16:02:07 :) 16:02:27 * sgallagh suspects that the latter might mean supporting modules longer than RHEL 8's lifetime 16:02:29 sgallagh: both actually as we are trying now with fedora and epel 16:02:31 err former 16:02:32 sgallagh: has to be books, TV is done in a couple of months 16:02:33 ok, so the simplest proposal i see is to allow only fedora releases. would that be a problem for epel? 16:02:58 bowlofeggs: nirik said "I could see it being confusing..." above on that 16:03:02 yeah 16:03:14 yeah, but might be a ok first cut at it... 16:03:20 what if there were two fields for the EOL 16:03:20 I suppose specifciying a Fedora release and an RHEL release 16:03:23 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 Which is why I was thinking about just doing half-years or something 16:03:26 in case the module builds fro both 16:03:33 {'product': 'fedora', 'release': 31} 16:03:39 If the release happens in Q1/Q2 or Q2/Q3, it ends then 16:03:41 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 {'product': 'epel', 'release': 8.2} 16:03:56 then you can use both or just one? 16:03:59 bowlofeggs: +1 16:04:02 make EOL a list? 16:04:06 I really want to change that "after" to "before" but we'd need a time machine 16:04:09 bowlofeggs: Depends on where we're storing that info 16:04:24 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 asamalik: or just EOL everything now and call it day :D 16:04:52 (Though I never liked the idea of storing that in the modulemd) 16:04:53 mhroncok: yeah, who use these Linuxes anyway!!! 16:04:56 Hmm, EPEL lives on its own schedule. I don't understand tying lifetime of EPEL things to Fedora releases. 16:04:57 sgallagh: ah 16:05:07 sgallagh: so what does the existing module metadata format allow? 16:05:09 we do have FPDC we could use 16:05:25 bowlofeggs: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L40 16:05:25 zbyszek: Well, if we are sharing module streams, they have to be tied together. The question is how to do it. 16:05:41 sgallagh: isn't the format xml/json/whatever to be extensible exactly to allow adding new fields at any point? 16:06:04 sgallagh: I actually like that idea 16:06:06 sgallagh: so dates only? 16:06:09 zbyszek: Not exactly, no. Though there's an opportunity to cheat. 16:06:42 The YAML structure is strict except for the "XMD" section, which can contain arbitrary content that isn't validated. 16:07:03 MBS uses it for internal purposes, but we could extend it for our purposes. 16:07:19 It just wouldn't be directly accessible via libmodulemd API 16:07:41 (You'd just get the raw contents as python objects or GVariants in C and deal with them manually) 16:07:48 sgallagh: so if we were going to say "fedora version x" that wouldn't work with this file either? 16:08:08 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 That's sad, but it's still probably better then putting it in some external place 16:08:14 I think the FPDC idea is a better place for it 16:08:27 sgallagh: but why? 16:08:28 Because metadata once in the repo is static 16:08:42 sgallagh: so would dnf/packagekit query PDC to get it? or would it get into the repodata via some process? 16:08:50 But if the upstream decides to extend the lifecycle, for example, you can't change that in the frozen release repos 16:09:19 I don't think so. I update the metadata of my packages all the time. This would be just another case. 16:09:19 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 Is this data useful on the client side though? 16:09:50 we probably don't want users live querying PDC without infra doing some serious scaling work 16:09:58 I mean, isn't EOL really only meaningful to the build system and bodhi? 16:10:00 sgallagh: isn't this data *for* the client? 16:10:08 sgallagh: oh i thought it was for the end user to know 16:10:17 bowlofeggs: At present, none of this is presented to the user 16:10:31 sgallagh: so i could know "this django version i'm using will only be supported until XYZ" 16:10:49 sgallagh: i don't know of a way that bodhi directly uses this info either 16:10:53 maybe pungi does? 16:11:00 (and bodhi uses pungi) 16:11:04 bowlofeggs: Well, Bodhi I could see refusing to submit an update for an EOL stream 16:11:11 Not that it does today, but I could see that happening 16:11:16 ah i see 16:11:19 yeah 16:11:34 but wouldn't you want end users to get notice they are using EOL packages? 16:11:48 otherwise they dont' get updates and don't realize it 16:11:55 bowlofeggs: Want to? Sure. Have a meaningful way of reporting it? Nope. 16:12:15 i guess my surprise here is that i thought that was the main purpose of this field 16:12:22 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 the bodhi/koji side of it seems secondary to me 16:12:31 bowlofeggs: I think this field has changed purposes several times 16:12:45 But realistically, we can't represent this information to an Ansible user, for example. 16:12:52 true 16:12:54 (Short of denying the installation) 16:13:05 but dnf could print warnings for CLI users at least 16:13:10 and GUI users could get warnings too 16:13:16 Perhaps 16:13:24 to me, that's far more important than stopping builds from happening 16:13:32 in fact, i dont' see a real purpose in stopping builds from happening 16:13:34 Oh, I don't disagree. 16:13:38 We just don't have a good answer for it. 16:13:53 so i dont' see the point of this field outside of informing the end user 16:14:10 we remove packages between Fedora releases 16:14:23 how is this different? 16:14:36 mhroncok: It's really not 16:14:51 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 I guess that really goes back to my question ont he ticket 16:15:11 Yes, maybe we can make it a little nicer/more visible, but I don't think it's fully solvable 16:15:12 unless it's got broken deps or somehing 16:15:12 do we remove the packages or keep them? both is bad 16:15:17 Right 16:15:41 and I think we only need to figure out how to do this consitently with nonmodular Fedora 16:15:52 I'll have to leave 20 past the hour. Apologies. 16:17:28 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 I think we should try to move on, but can I summarize the discussion and move it to the ticket? 16:17:59 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 so they'd have the info and they could do what they think is best 16:18:25 sgallagh: sure 16:18:27 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 Reasonable summary? 16:18:40 combined with a policy preventing EOLs mid-release I think that would work nicely 16:19:10 Seems a good summary 16:19:17 sgallagh++ 16:19:19 mhroncok: Karma for sgallagh changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:19:30 sgallagh: +1 16:19:50 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 #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 Ack. 16:20:17 sgallagh++ 16:20:26