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