15:03:13 #startmeeting FESCO (2019-02-25) 15:03:13 Meeting started Mon Feb 25 15:03:13 2019 UTC. 15:03:13 This meeting is logged and archived in a public location. 15:03:13 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:13 The meeting name has been set to 'fesco_(2019-02-25)' 15:03:14 #meetingname fesco 15:03:14 The meeting name has been set to 'fesco' 15:03:14 #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor 15:03:14 Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek 15:03:16 #topic init process 15:03:19 My bad. 15:03:20 hi 15:03:22 morning all 15:03:26 .hello2 15:03:27 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:03:31 .hello2 15:03:32 bcotton: bcotton 'Ben Cotton' 15:03:46 .hello2 15:03:47 otaylor: otaylor 'Owen Taylor' 15:03:51 .hello2 15:03:51 I'm semi-here. Just getting back from PTO and dealing with the accompanying avalanche of stuff I missed 15:03:52 sgallagh: sgallagh 'Stephen Gallagher' 15:03:56 .hello2 15:03:57 bowlofeggs: bowlofeggs 'Randy Barlow' 15:04:35 So we have 5.5, that's quorum. 15:04:56 * bowlofeggs tosses a clif bar to sgallagh to help him survive while crews search for him in the avalanche 15:05:08 #2090 Needs more understanding on retiring packages with security issues 15:05:11 .fesco 2090 15:05:12 zbyszek: Issue #2090: Needs more understanding on retiring packages with security issues - fesco - Pagure.io - https://pagure.io/fesco/issue/2090 15:05:14 https://pagure.io/fesco/issue/2090 15:06:01 i'm +1 in ticket to mboddu's proposal 15:06:26 * nirik re-reads it 15:06:26 * mboddu is here 15:06:27 Hmm, we discussed this last week, and there was some conclusion, but it wasn't pasted in the bug. 15:07:26 zbyszek: We discussed about the timeline and I proposed that I will comment on the ticket with my proposal and now we want the +1's on my proposal or any changes needed to it 15:07:42 * nirik was +1 in the ticket and still is 15:07:43 +1 mboddu proposal 15:08:00 So we're at +4 in the ticket 15:08:10 +1 mboddu proposal 15:08:18 +6 now, anyone else? 15:08:24 +1 15:08:52 +1 in the ticket 15:10:02 Let me type this up... 15:10:44 #agreed mboddu's proposal https://pagure.io/fesco/issue/2090#comment-554540 is approved (+7, 0, 0) 15:10:51 #2088 Late F30 Change – “dnf --best” as default behavior 15:10:51 .fesco 2088 15:10:51 https://pagure.io/fesco/issue/2088 15:10:53 zbyszek: Issue #2088: Late F30 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088 15:11:34 Dunno, any new ideas? 15:12:16 we were supposed to discuss this in ticket but we did not 15:12:26 at this point i am not convinced that --best is best 15:12:28 it's gaetting later and later 15:12:39 I still think we are Ok to do thsi if we ahve a clear contingency 15:12:55 plan + deadline 15:13:20 the security argument has a counter-argument that is also security related - what if the packages it would have installed without --best could patch a severe security issue 15:13:21 mhroncok: well, contigency only makes sense if we think the change is right :-) 15:13:22 Yeah, agreed. It's one of those things we can debate forever, but testing should bring some clarity. 15:13:27 I've asked for that 11 days ago 15:13:31 but because some unimportant package is broken you can't get the security fix 15:13:42 zbyszek: not for the current topic, but want to make sure I don't miss the open floor.. can we please have a look at 2027 today as well? 15:14:14 asamalik: I'll add it to the agenda before open floor 15:14:31 I would like to help jmracek and his team, but if they porpose a change proposal late, they should be bale to respond promptly :( 15:14:35 FWIW, I think bowlofeggs' point is key here. 15:14:37 i'm -1 for F30 for sure, and i think i might even advise against it in generaaal 15:14:52 well, there's also the 'behave like rhel' angle... 15:15:09 which should IMHO never be the primary agrument 15:15:11 From the workstation perspective, I don't think it makes sense to make upgrades more fragile, and I don't think it makes sense to have dnf and PackageKit behave differently 15:15:12 The set of things --best ends up skipping is likely to be smaller than the set of things is enables 15:15:20 rhel has a much tighter QA on the central repository 15:15:48 zbyszek: thanks! 15:15:50 nirik: RHEL is far less likely to ship broken repos though 15:15:56 I didn't say it was a primary argument, just another datapoint 15:16:33 * nirik wonders if our stable repos have broken deps... 15:16:33 ack 15:16:41 they do 15:16:57 it has been known to happen 15:17:03 the "behave like rhel" argument doesn't carry much weight with me. 1. i think it's reasonable for people to expect different behaviors in different OSes with different target audiences. and 2. i generally don't like features swimming against the stream :p 15:17:03 up until recetnyl there was a package requiring /usr/bin/python2.5 15:17:28 if the change were to say that it will install what it can and then use a non-0 exit code, i'd be in favor 15:17:39 but i don't see why it should refuse to do anything at all 15:17:53 bowlofeggs: I'd think that'd be ever more confusing. 15:17:56 i'm a fan of making the error more priminent 15:18:12 (non-zero return code if stuff was done...) 15:18:19 zbyszek: well there was a "partial success", which is a distinct situation 15:18:28 bowlofeggs: while that has some appeal (breaks dockerfile, but not interactive usage), I think it violates some principle of cli design :-) 15:18:52 perhaps 15:18:59 well just a thought 15:19:45 * bowlofeggs is not a UX designer ☺ 15:20:28 That's okay, we can have the qemu UX designers work on a suitable cli design for dnf 15:20:46 OK, so, any proposals? 15:20:51 Do we know if this is configurable in dnf.conf? 15:20:56 it is. 15:20:57 otaylor: yes 15:21:08 best=false 15:21:23 that seems to allow users (or editions) who want to favor works-like-rhel to configure things that way 15:21:50 proposal: move to 31 (does not mean accept) 15:22:12 My proposal is: fesco considers that this doesn't make sense as a general default for Fedora, individual editions can change the default via dnf.conf if appropriate 15:22:31 I guess I'd be in favor of more time... as it's all kinda muddled... and people wanted more answers... 15:22:40 (though obviously different fedora editions doing different things is also confusing!, so that might be a poor diea) 15:22:49 and my concern i that more tiem measn we cannot make it for f30 15:22:57 otaylor: -1 15:23:08 I'd be -0 or -1 to otaylor's proposal, exactly because of the potential for confusion 15:23:11 This is not something that should differ between editions, IMHO 15:23:14 jforbes: i was thinking the openssl people might be good to consult too … 15:23:44 I'll -1 my own proposal too, on second thought ;-) 15:23:48 nirik: +1, I'd prefer to wait one more week, maybe we can get more answers 15:24:06 i think i'm -0 to the idea in general, and -1 to F30 15:24:19 i might even be -1 to the idea in general 15:24:53 mhroncok: +1 to move to F31 rather than trying to wait for more time for F30, but I'm not clear what we're waiting for - what we think would change for F31 that would make this a better idea. 15:25:09 Yeah, I'm coming down on -1 for running with --best by default. 15:25:31 I mean, DNF cues the user to try it if they encounter issues 15:25:40 yeah 15:25:47 and users who want this can configure it themselves too 15:25:49 but they may not... 15:25:59 nirik: May not what? 15:26:11 otaylor: for one, moving to f31 gives it more time to be tested before we cut a beta release 15:26:36 right now you do 'dnf update' and if there's foo-1 and foo-2 in the repos, but foo-2 has broken deps, you just get foo-1 and nothing else right? 15:26:36 beta freeze is a week from tomorrow 15:26:52 no message or anything. 15:26:58 nirik: i think you see an error 15:27:10 my rawhide box is showing broken dep errors right now and i see them 15:27:19 there's definitely a message, but it's not red or anythign 15:27:22 it does install what it can but also shows that it couldn't install some things 15:27:25 bcotton: I understand that, yes. I don' tthink switching at this point for F30 would be a good idea. 15:27:49 yeah i would support highlighting the error more 15:27:49 Maybe we could ask dnf folks to make that part of output more visible, and add a message at the very end, like "some updates were not installed because of dependency issues". 15:27:54 we are clearly inclined to -1 this, but jmracek is nto part of the conversation 15:28:18 hence, i again propose to just formally move this to f31 and later we can discuss this with him 15:28:20 it might be nice to have dnf folks clearly spell out the cases they think will be helped by this? as we are not sure what they are? 15:28:35 bowlofeggs: yeah, you might be right. I tend to distro-sync anymore here. 15:28:55 i'll get some text to show if it's still doing it today 15:29:53 proposal: let's ask the dnf folks for specific cases that this helps with in the ticket, revisit next week 15:30:01 https://paste.fedoraproject.org/paste/W8WBUJsA0Fj3epjfKkSzbA 15:30:10 it only shows the problem before you type y 15:30:13 so that's not great 15:30:23 like the output at the end does make it seem like everything is cool 15:30:32 zbyszek: +1 15:30:33 zbyszek: -1 - I think it's too late at this point to switch for F30 15:30:42 the detailed errors are all at the beginning 15:30:54 and just before you are prompted y/n, you are shown that it can't install some of them 15:30:58 if we wait next week, we are past beta freeze 15:31:00 but after that it all looks like success messages 15:31:10 bowlofeggs: I agree. I'd be happier if it at least added "Conflicts resulted in some packages not being updated. Please review the errors above." 15:31:15 i'm -1 on F30 for sure 15:31:16 Mind filing an RFE? 15:31:20 bowlofeggs: if you run with -y, it's easy to miss. 15:31:34 -1 for F30 and -1 for F31, absent strong counter arguments 15:31:52 sgallagh: sure i can file an RFE 15:31:58 Cool, thanks 15:32:04 #action bowlofeggs will file an RFE for better error messages from dnf 15:32:38 yeah i'm -1 on both too, but am willing to hear further arguments about it 15:32:48 #rejected Waiting for one more week (+2, 0, -3) 15:33:15 OK, so I think we should vote on mhroncok proposal, to make some closure 15:33:31 i do think it would be irresponsible to allow this for F30, especialyl since we aren't getting comms about it 15:33:48 proposal: move to 31 (does not mean accept) 15:33:55 > mhroncok> proposal: move to 31 (does not mean accept) 15:34:03 +1 ftr 15:34:07 +1 I guess...I agree it's very late for f30 15:34:17 +1 (repeating from above) 15:34:22 +1 15:35:02 mhroncok: +1, though at this point i will want to see compelling counter arguments to accept it 15:35:26 bowlofeggs: sure, to accept it or not, we can argue later 15:35:31 #agreed Feature is postponed to F31, without accepting or rejecting. We need more information from the Change owners about specific cases that this solves (+6, 0, 0) 15:35:37 OK? 15:35:41 sure 15:35:45 works for me 15:35:51 #2084 "Fedora packaging service" & packit ask 15:35:51 .fesco 2084 15:35:51 https://pagure.io/fesco/issue/2084 15:35:53 zbyszek: Issue #2084: "Fedora packaging service" & packit ask - fesco - Pagure.io - https://pagure.io/fesco/issue/2084 15:36:10 so they want 2 things from fesco 15:36:13 a name suggestion :D 15:36:16 and a FAS identity 15:36:35 I guess I'm the only one who voted on the identity 15:36:56 and I don't thing FESCo ticket is a place for name suggestions 15:37:01 *think 15:37:20 I'll quote mhroncok's vote: 15:37:25 > +1 to a FAS identity that has permissions needed to upload stuff to the lookaside cache, fork repos and send PRs. (this includes kerberos and all technical things to make it work) 15:37:31 > -1 to a FAS identity that can push to actual packages 15:37:32 yeah i don't think we need to approve either of these right? wouldn't a fas id be an infra question? 15:37:40 I'm +1,-1 (the same) 15:37:49 any fas account shoud be able to do those things. ;) 15:38:06 i'm in agreement with mhroncok as well 15:38:18 I can work with them on detals... or rather infra can... 15:38:29 I guess it's infra that might give the account, but I think it's still useful for use to ack it. 15:38:30 nirik: Any FAS account that signed the FPCA, yes? 15:38:44 yeah 15:38:52 I'm in agreement. I don't think this is quite the right direction, but blocking a FAS identity would be blocking experimentation to find better automation, which is something we shouldn't do. 15:39:01 (as an upstream that is almost exlusively written for Fedora, i don't see a use case for keeping my spec file upstream - that would make it have if statements in it, which is a headache) 15:39:17 (keeping it downstream is superior because i have release branches that allow me to keep it readable) 15:39:32 (and also, separation of concerns is a good thing) 15:39:51 bowlofeggs: From my understanding, that's an optional feature, not a mandatory one 15:40:00 yeah 15:40:01 but something that bridges upstream/down I think is very good (aside the spec issue) 15:40:04 I'm against automation that assumes upstream==downstream, because that's only a tiny fraction of the 20,000 packages in Fedora 15:40:25 yeah i'm ok and even want a thing that sends me spec file pull requests 15:40:38 otaylor: What do you mean? Could you clarify? 15:41:13 I'm also against the general idea of this, but if it solves their own problem, I guess thay can spend time on it and should not be blocke on FAS identity 15:41:27 OK, nirik, sgallagh, otaylor, OK to accept mhroncok's proposal? 15:41:27 Hmm, I misread the specfile thing. I'm hesitating now 15:41:33 i'm not even sure we need to approve anything here 15:41:45 i think they can just ask infra for a bot account, right? 15:41:45 But yes, +1 to mhroncok's proposal 15:41:46 sgallagh: What I'm saying, is that the description of packit is centered around packages where you have a spec file upstream, that the Fedora maintainers control as their property. And I'd like to have standard automation in Fedora that everybody uses, that doesn't just work in that case. 15:41:57 bowlofeggs: right. 15:42:05 I guess +1 to mhroncok 15:42:28 o, but it might be helpful to state our concerns so they don't spend a lot of time working on something that is going in the wrong direction 15:42:32 sgallagh: But I'm still +1 to allowing a FAS identity. 15:42:38 jforbes: +1 15:42:56 jforbes: +1 15:43:16 let's finish this vote and later we can have a proposal about what jforbes said 15:43:32 otaylor: Yeah, your points are valid. I hadn't read far enough to see what you meant when I said that. I agree with you. 15:43:46 Upstream specs are pretty exceptional. 15:43:50 So, to allow the identity, I'm counting +5 15:43:51 zbyszek: +1 to mhroncok 15:44:05 Oh, +1 to allowing the identity 15:44:09 jforbes? 15:44:29 Though I don't think we could deny it either 15:45:10 does lookaside upload needs packager group? if so, they probably need some body to ack an exception 15:45:59 #agreed Creating a FAS identity that has permissions to upload stuff to the lookaside cache, fork repos and send PRs (including kerberos and all technical things to make it work), but not build packages, is approved (+7, 0, 0) 15:46:13 mhroncok: this seems to be included in what you wrote 15:46:23 Now, returning to jforbes 15:46:44 I think that various concerns were stated pretty clearly 15:47:07 zbyszek: "not to push to the package repos or build packages" to be precise 15:47:17 #undo 15:47:17 Removing item from minutes: AGREED by zbyszek at 15:45:59 : Creating a FAS identity that has permissions to upload stuff to the lookaside cache, fork repos and send PRs (including kerberos and all technical things to make it work), but not build packages, is approved (+7, 0, 0) 15:47:25 but so far they have been individual's concerns, not fesco's 15:47:32 #agreed Creating a FAS identity that has permissions to upload stuff to the lookaside cache, fork repos and send PRs (including kerberos and all technical things to make it work), but not to push to repos or build packages, is approved (+7, 0, 0) 15:48:00 OK, but we'd need somebody to phrase a text and then we'd need to sign off on it. 15:48:10 Volunteers? 15:48:21 on it 15:48:41 thanks mhroncok 15:48:45 mhroncok: should we wait now? 15:49:18 zbyszek: yes please 15:50:44 FESCo is concerned that the presented idea of how this automation should work is only applicable to a very limited set of packages and would rather see a focus on automating stuff for greater audience. 15:50:48 * nirik thinks these things will come up on the devel list thread no? 15:50:59 nobody reponds on the devel thread 15:51:26 I read it as "nobody is interested in what they are proposing", but it also might read "nobody noticed this yet" 15:51:30 mhroncok: well aren't we also concerned that it will break provenpackager workflows? 15:51:34 well, it was the weekend... likely more posts now? 15:51:55 i shre the stated concerns, but have more than just those ☺ 15:52:39 FESCo is also concerned that moving spec to upstream breaks provenpackagers experience. 15:53:01 Also co-maintainers who are not upstream members ;) 15:53:23 FESCo is also concerned that moving spec to upstream breaks experiance for multiple interested parties. 15:53:44 +1 to both concerns stated by mhroncok 15:53:54 +1 to both 15:54:21 sure, I agree on those... 15:54:26 +1 to both 15:55:03 #info FESCo is concerned that the presented idea of how this automation should work is only applicable to a very limited set of packages and would rather see a focus on automating stuff for greater audience. 15:55:07 #info FESCo is also concerned that moving spec to upstream breaks experiance for multiple interested parties. 15:55:10 OK, let's move on. 15:55:13 #2027 15:55:13 .fesco 2027 15:55:13 https://pagure.io/fesco/issue/2027 15:55:16 zbyszek: An error has occurred and has been logged. Please contact this bot's administrator for more information. 15:55:28 haha 15:55:33 zbyszek: you broke him 15:55:34 pagure seems down. ;( 15:55:39 pagure is down 15:55:40 ERR_CONNECTION_REFUSED 15:55:44 Oops. 15:55:46 E_NOCOFFEE 15:55:50 runs 15:55:54 I didn't even paste the title of the issue 15:55:59 does anyone know what it is? 15:56:02 hahah 15:56:05 asamalik: please help 15:56:06 #2027 RFC: Module lifecycles 15:56:14 pagure is up again 15:56:22 .fesco 2027 15:56:23 and back 15:56:24 bowlofeggs: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027 15:57:27 * nirik is fine with the latest proposal. +1 15:58:00 For me, specifying the EOL as opt-out seems a bad idea, but otherwise the proposal is OK. 15:58:23 EOL 0 to represent "do not build". 15:58:29 I still don't like this 15:58:30 As soon as we get epel9, all modules will be "on" for it, with forever EOL 15:58:33 zbyszek: my argument for it is that I want to make it as easy for packagers as possible to create a new package / module 15:58:43 you create it, you build it 15:58:44 +1 to the general idea (in the "Proposal" paragraph) 15:58:45 what happens if a module depends on another module that EOLs sooner? 15:58:53 but i'm +1 to teh idea 15:59:14 asamalik: what kind of toppings can i get on my pizza module? 15:59:16 and when you decide to drop it, you do that 15:59:18 Could someone paste the direct link to the proposal? Pagure is still unreachable to me 15:59:28 sgallagh: it's on pagure as well 15:59:29 Yeah, but saying "build for F30 and F31" is not particularly hard, certainly easier then figuring out which epel version to disown. 15:59:31 https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/lifecycles-general.md 15:59:43 lovely 15:59:46 hahah 15:59:46 :) 16:00:04 Ah, after frantically clicking reload, I got it now 16:00:11 sgallagh: I's past it somewhere but it has images and stuff 16:00:18 good 16:00:20 bowlofeggs: anything you package and keep fresh :P 16:00:53 asamalik: what happens if a module's dependency goes EOL before the module does? an error to the packager? 16:00:54 Anyway, I'm +1 too to the general idea. 16:01:00 Let's try not to get hung upon on the pseudocode example. 16:01:12 +1 too to the general idea 16:01:18 We absolutely need to find a good way to represent the values, but the idea itself is sound. 16:01:20 +1 16:01:24 I'm OK with the general idea, I'm concerned that being in [F]PDC means "hard to view for packagers" and "more releng tickets" 16:01:54 otaylor: I think probably a tool needs to make that more accessible. 16:01:56 Oh, wait, fpdc, then I'm -1. 16:02:05 :D 16:02:20 bowlofeggs: good question, not covered there, I'd say we'd need to take dependencies into account as well 16:02:22 bowlofeggs: Maybe we could extend Bodhi to interface with this ? 16:02:29 I'm +1 to the idea 16:02:33 I'm sorry, but accepting storage of crucial information in a service that is planned, is not something I can vote for. 16:02:36 Wait, aren't we the ones who said fpdc was likely the best place for it? 16:02:42 but I's -1 FPDC as well 16:02:48 zbyszek: PDC now and later FPDC 16:03:00 sgallagh: were you referring to my question about dependencies? by bodhi do you mean the tests that are shown in bodhi? 16:03:17 bowlofeggs: No, sorry. I was talking about providing a better interface for viewing and setting the EOls 16:03:18 jforbes: certainly not me 16:03:18 asamalik: yeah i think something should check the deps - maybe just a test in the CI 16:03:54 sgallagh: i guess that could be considered "update" information maybe 16:04:06 But as for the deps, yes we need to have a CI of some sort that ensures that deps don't have a shorter EOL than the module in question 16:04:10 I completely don't buy any of the "benefits of using a database as opposed to, for example, a file in a git repository". All this can be easily achieved with rpmlint or equivalent. 16:04:33 bowlofeggs: although we could, as a first step, just let packagers check and communicate with each other the same way they do with package retirement? 16:05:44 asamalik: what do you need? ack the proposal as is, or ack the general idea? 16:06:11 asamalik: perhaps. not having made a module yet i'm not sure whether the existing tooling makes that easy/possible 16:06:12 Ah right, it was nirik and sgallagh that proposed the fpdc 16:06:38 * nirik nods. 16:06:54 But yes, the suggestion to use fpdc did come from that FESCo meeting 16:07:16 fpdc is not just planned, it exists. 16:07:34 it's not being used yet, there's a PR pending to load it with the existing info. 16:07:43 https://fpdc.fedoraproject.org/api/v1/ 16:07:46 yeah i somewhat prefer the idea of a structured file in a git repo too, but i wouldn't really oppose fpdc 16:07:46 In absence of extra interfaces that don't yet exist, [f]pdc are releng tools, not packager tools ... and I think this does need to be self-service for the packager owner 16:07:50 Anyway, I am +1 to the proposal 16:07:52 but it definitely exists. :) 16:08:00 i like simple solutions over complex ones in general 16:08:01 (module owner, I mean) 16:08:16 bowlofeggs: but thinking about it, getting an EOL info for a module based on its dependencies as well won't require any more input, we'd just need MBS (or the build system in general) to be smarter when evaluating it 16:08:34 asamalik: yeah. or just a CI test 16:08:44 * asamalik has no hard opinion about the storage 16:08:51 if we can replace fpdc with something simpiler, thats great... but we should communicate that to fpdc developers... 16:09:45 mhroncok: sorry, what exactly is the difference there? 16:10:19 asamalik: I like the first paragraph of the porposal 16:10:26 asamalik: How exactly are packagers going to interface with fpdc? 16:10:30 I don't like the details - syntax, fpdc, etc. 16:10:58 mhroncok: ok, thank you 16:11:06 mhroncok: there is no proposal for syntax :) 16:11:25 not syntax, form 16:11:50 anyway that's why i asked what do you actually need 16:12:01 zbyszek: a ticket probably... it won't be happening that often :) 16:12:31 asamalik: no, that doesn't scale. We know it doesn't. 16:12:31 more tickets \o/ 16:12:58 asamalik: how would a packager even find out what the current eol of their module is? 16:12:59 Also, even if we ignore the releng side, _packagers_ really dislike it. 16:13:50 mhroncok: ok, I'd like to have an ack to the whole proposal, or a specific feedback about what should be changed 16:14:03 ok, -1 here for the whle proposal 16:14:10 1) eol 0 is confusing 16:14:24 2) packagers need to be able to update this information themselves 16:14:27 mhroncok: again, there is no syntax proposal 16:14:41 syntax an implementation detail 16:14:48 asamalik: the assumption for solution of 2) is that the syntax from 1) becomes user-visible 16:14:56 mhroncok: +1 16:15:09 well, anyone could query fpdc... but yeah, updating would be more manual. 16:15:25 would this group be happy if we moved that information to dist-git, along with the modulemd? 16:15:48 asamalik: from what I understand, I'd be happy 16:16:19 can we try to vote on the proposal as is (well, is there a chance for it to succeed?), and then for the proposal with the above amendement? 16:16:25 *amendment 16:16:51 -1 to the proposal as is 16:16:59 -1 to the proposal as is 16:17:27 * nirik is a bit leary of unstructured data for this in git... but I guess we can see how much trouble it causes. 16:17:43 -1 to the proposal as is 16:18:08 nirik: well it could be structured if it had a schema ☺ 16:18:12 but jcline is opposed to schemas… 16:18:26 nirik, bowlofeggs, jforbes? 16:18:41 nirik: yeah I'm a bit scared, too.. a typo could accidentally cause quite a lot of unwanted builds to happen for example :) 16:18:49 * nirik is +1 to the proposal, but we can scrap it if everyone doesn't like it. 16:18:51 asamalik: oh? 16:19:10 well, or things to appear/disappear, or tools to blow up and crash or ... 16:19:14 i'm on the fence abotu the proposal as is 16:19:32 i think i'm not opposed exactly, but i'd much prefer a self-service approach for packagers 16:19:40 eol: 🌭 16:19:41 yes... how often there would be a module stream going EOL? 16:19:42 i agree that we've placed too much of a burden on releng 16:20:00 well, there's a burden either way 16:20:06 asamalik: many per release that goes EOL i'd guess. right? 16:20:11 (at least of the two paths currently proposed) 16:20:23 I am still +1 to the proposal, implementation details can be dealt with 16:20:27 nirik: the self-service approach also places a burden? 16:20:55 nirik: or would you agree that one is a lesser burden than the other? or you think they are similar? 16:21:00 yes, because the data could be anything... the tools might get garbage or nothing or whatever... or people might change one eol and not dependent ones or ... 16:21:17 So I'm counting (+2, +2, -3) as *FOR* the proposal, i.e. it is rejected 16:21:42 nirik: and that would impact releng because build systems get jammed up wtih tasks? or because people ask for help due to bugs they caused? 16:21:45 nirik: Without extra tooling, that all can happen if releng is typing in manual fpdc updates because there's a ticket in their queue 16:22:02 zbyszek: ok, thanks for counting 16:22:12 #rejected Proposal in its current form is accepted (+2, 2, -3) 16:22:24 Do we have an amended form to vote on? 16:22:25 can we now try the proposal with the amendment that moves the EOL definition to dist-git alongside the modulemd? 16:22:31 Oh, thanks. 16:22:45 please make the proposal clear 16:23:04 asamalik: Hmm, I think we shouldn't vote it in the meeting. Please phrase it in the ticket, and we'll vote there. 16:23:05 a specific syntax being out of scope, but the semantics in the proposal is a part of it 16:24:00 zbyszek: so that would happen next week? 16:24:17 asamalik: we can try to make the vote quickly 16:24:21 i'm interested in hearing nirik's perspective a bit more before voting on the counter proposal 16:24:21 OK 16:24:30 bowlofeggs: yes, and also breaking composes... 16:24:39 otaylor: yep. thats the other side. 16:24:58 nirik: do you think CI could be the answer? 16:25:16 it's possible we could add a git hook to catch some of it? 16:25:17 zbyszek: done 16:25:19 nirik: i.e., a CI test that prevents builds from running if this metadata is found to be nonsense? 16:25:38 perhaps. 16:25:39 i guess it's not CI 16:25:44 it's pre-build tests 16:25:47 like, CI CI 16:25:49 ? 16:25:52 hahaha 16:25:52 pre-update git hook? 16:26:01 bowlofeggs: MBS could check for nonsense before starting a module build 16:26:07 otaylor: yeah exactly 16:26:07 so let's use CI and a file instead of a database with a schema? :) 16:26:10 * asamalik shrugs 16:26:25 That's what we do for packages. 16:26:48 * nirik imagines a spec file schema. :) 16:26:53 I remember asking what happens if I have an EOLed module installed adn I upgrade my Fedora 16:26:58 got no reasonable unswer 16:27:09 nirik: :D 16:27:18 let me say for the record that the details of how the data are stored aren't the important thing to me - what's important to me is that we do not increase the burden on packagers or releng, in general 16:27:22 * asamalik needs to go to a meeting... will be still here, but probably not very active 16:27:31 the ticket is updated with an amendment 16:27:36 I'd guess it just stays there. Like eol packages 16:27:36 * zbyszek needs to leave soon too 16:27:58 * otaylor needs to leave now too 16:27:59 Let's discuss & vote in the ticket. 16:28:07 zbyszek: +1 16:28:13 = Open floor = 16:28:25 Anything for open floor? 16:28:34 If not, I'll close in 2 minutes. 16:29:06 who's next weeks chair? 16:29:12 Oh, right. 16:29:18 #topic Next week's chair 16:29:33 I can do it again, unless somebody really wants to 16:29:40 sold! 16:29:51 #action zbyszek will chair next meeting 16:29:54 #topic Open Floor 16:29:59 Attempt #2. 16:30:42 ... crickets ... 16:31:19 See you next week. Please remember to vote in the tickets (in particular the "module lifecycles"). 16:31:23 #endmeeting