15:00:17 <zbyszek> #startmeeting FESCO (2018-10-01)
15:00:17 <zodbot> Meeting started Mon Oct  1 15:00:17 2018 UTC.
15:00:17 <zodbot> This meeting is logged and archived in a public location.
15:00:17 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:17 <zodbot> The meeting name has been set to 'fesco_(2018-10-01)'
15:00:18 <zbyszek> #meetingname fesco
15:00:18 <zodbot> The meeting name has been set to 'fesco'
15:00:18 <zbyszek> #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:18 <zodbot> Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek
15:00:20 <zbyszek> #topic init process
15:00:23 <zbyszek> .hello2
15:00:23 <contyk> o/
15:00:23 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:26 <jforbes> .hello2
15:00:26 <contyk> .hello psabata
15:00:26 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:26 <nirik> morning
15:00:29 <sgallagh> .hello2
15:00:29 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:32 <zbyszek> evening
15:00:32 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:48 <maxamillion> .hello2
15:00:49 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:00:49 <sgallagh> (I’m also at AnsibleFest, so I may not be fully here)
15:00:56 <maxamillion> +1
15:01:02 <maxamillion> I'm at AnsibleFest as well
15:01:45 <zbyszek> I'm counting 6, so we have quorum
15:01:46 <bowlofeggs> .hello2
15:01:47 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:01:58 <zbyszek> Let's start
15:02:07 <zbyszek> #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking
15:02:10 <zbyszek> .fesco 1974
15:02:12 <zodbot> zbyszek: Issue #1974: Problematic blocker for F29: dnf 'offline' module tracking - fesco - Pagure.io - https://pagure.io/fesco/issue/1974
15:02:13 <zbyszek> https://pagure.io/fesco/issue/1974
15:02:15 <contyk> yay
15:02:31 <contyk> so I was hoping to comment on this one before this meeting but didn't get to it
15:02:42 <zbyszek> me too ;)
15:02:57 * sgallagh threw together a straw man on the ticket a little while ago.
15:03:03 <zbyszek> But I'm with sgallagh on this one
15:03:34 <zbyszek> The "soft behaviour" approach I don't understand at all
15:03:36 * nirik just got up, so goes to read recent comments.
15:04:16 <sgallagh> zbyszek: I’ll try to explain, give me a moment
15:05:23 <sgallagh> In brief, the major issue here is that DNF historically only sees the "target" state of the system.
15:05:41 <sgallagh> It takes all of the repodata it has available at the current moment and makes its decisions based on that:
15:05:44 * contyk is in a call so a little distracted :|
15:05:52 <sgallagh> Asked to update? Is there a higher NVR in the set? Then update.
15:06:19 <sgallagh> But the problem is that because modules filter some things out of the solver, the *current* state is important, not just the destination state.
15:06:39 <zbyszek> Right. And modules are all about not always installing the latest version, so they cannot work with the always-install-latest beahviour.
15:06:41 <sgallagh> Because if some repodata is unavailable (the u-t example being the obvious one), then the filtering logic may get confused
15:07:25 <sgallagh> Moreover, since the set of subpackages offered by a particular module stream may change over time, if you only have the latest modulemd, it might lose track of those as well
15:08:09 <bowlofeggs> sgallagh: so if i enabled u-t and install a module, that module's metadata (md?) file stays on my system somewhere?
15:08:11 <sgallagh> (For example, I carry libuv in the nodejs module because it's not new enough in F28 non-modular. However, if it got updated there, I might drop it in a module update)
15:08:26 <bowlofeggs> which would mean dnf does have the info it would need to know that i got that nvr from a module?
15:08:28 <sgallagh> That *specific* case will end up being safe, but the decision will be made without the filtering logic
15:08:42 <sgallagh> bowlofeggs: It does not do this *today*
15:09:00 <bowlofeggs> ah, but your proposal is that it could/should keep that md file?
15:09:17 <sgallagh> That is the recommended way to resolve this issue: that DNF needs to maintain a lookup table matching installed RPMs to the modulemd associated with them
15:09:27 <sgallagh> s/the/my/
15:09:41 <sgallagh> Sorry s/the recommended/my recommended/
15:09:42 <contyk> bowlofeggs: yes
15:09:48 <bowlofeggs> and it could assume that if there is no modulemd then the rpm came from a "traditional" repo?
15:09:58 <contyk> I think we should keep modulemd files for every installed modular RPM and the latest seen modulemd file for every enabled stream
15:10:17 <sgallagh> contyk: I concur
15:10:20 <contyk> but there is a problem dmach raised -- you might get a defective "latest" modulemd from updates-testing
15:10:21 <bowlofeggs> that does sound pretty sensible to me, though i am far from an expert on modularity ☺
15:10:28 <nirik> sounds like dnf folks aren't too convinced?
15:10:29 <sgallagh> contyk: How do you mean?
15:10:58 <contyk> sgallagh: you dnf --enablerepo=updates-testing-modular module install foo
15:11:00 <sgallagh> nirik: Anyway, FESCo doesn't need to dictate the implementation
15:11:13 <sgallagh> We need to decide on what criteria we're willing to block F29 release.
15:11:22 <contyk> sgallagh: and dnf records the modulemd for that one; you then decide it's broken but dnf remembers the modulemd because it was the last one it saw (assuming foo is enabled)
15:11:46 <contyk> so you need to drop it somehow, reverting back to the latest from the now enabled repos (stable updates)
15:12:05 <contyk> I think a clean or somesuch command would help there, even though it'd be a workaround and not very intuitive
15:12:07 <sgallagh> contyk: one assumes `dnf module disable foo:stream` would suffice
15:12:17 <contyk> on the other hand it's a corner case and this will probably only happen when you deal with test updates
15:12:19 <nirik> so, if we say we require this for final... is there any way it would be implemented before next tuesday?
15:12:20 <zbyszek> contyk: I don't think this is much different from the case where you install a package from u-t and then disable u-t and upgrades don't happen for a while
15:12:33 <contyk> sgallagh: you don't always want to disable the module, especially if it's a low level one
15:12:45 <contyk> zbyszek: that's true
15:13:00 <sgallagh> zbyszek: He didn't say it clearly, but he meant "consider also the case where we accidentally shipped bad/invalid metadata in u-t"
15:13:12 <sgallagh> Saving bad data needs a way to recover from it
15:13:24 <sgallagh> I think that may be overkill for blocking F29 though
15:13:33 <sgallagh> I'd prefer to assume we won't ship bad data
15:13:49 <contyk> that's fair
15:14:03 <zbyszek> OK, so if that happens either a) release updated version with fixed metadata or b) require the user to disable the module ?
15:14:20 <bowlofeggs> sgallagh: heh, as the bodhi maintainer i'm sad to say shipping bad data has happened on my watch
15:14:35 <bowlofeggs> (i accidentally broke all dnf/yum repos by accidentally turning on tagger)
15:14:44 <sgallagh> bowlofeggs: I assume the best of you. Prove me right :)
15:14:45 <contyk> it happens :)
15:14:47 <bowlofeggs> haha
15:14:54 <bowlofeggs> i will say it's not frequent
15:15:18 <sgallagh> bowlofeggs: Well, it would be difficult in this case to ship invalid data without a bug in MBS
15:15:26 <sgallagh> Since we're basically just copying it into place
15:15:35 <bowlofeggs> how much should we assume that people using u-t know how to recover from weird situations?
15:15:53 <bowlofeggs> i would think we can expect a bit more from those users than the average user (not necessarily a lot more)
15:15:54 <sgallagh> bowlofeggs: "Smarter than the average bear", I'd say
15:15:57 <bowlofeggs> yeah
15:16:37 <jforbes> sgallagh: I don't know that I would go that far, people frequently copy paste commands to enable update testing to get a specific fix listed in a bug or similar
15:17:04 <jforbes> We don't want to make updates-testing harder to use for people who are willing to do so, but I don't think that is a huge risk here either
15:17:16 <zbyszek> sgallagh: can you describe (or repeat, if you already did), how we could handle the case of bad metadata in your recommended approach?
15:17:18 <sgallagh> jforbes: Like I said, I think the bad-data case is *our* problem, not so much the user's
15:17:29 <sgallagh> And shipping a new update with fixed modulemd would hopefully fix most cases.
15:17:46 <sgallagh> And the workaround of disabling the module and forcibly downgrading/removing the RPM is not terribly onerous
15:18:05 <nirik> we do have distro-sync...
15:18:42 <contyk> sgallagh: +1
15:18:49 <jforbes> do we have module-sync?
15:18:52 <bowlofeggs> sgallagh: does distro-sync work on modules?
15:18:58 <sgallagh> bowlofeggs: Yes
15:19:04 <contyk> jforbes: that's kinda what I meant with the "clean or somesuch" :) we don't
15:19:19 <contyk> ok, to avoid confusion :)
15:19:21 <sgallagh> bowlofeggs: Though, it's probably worth our making a statement that it must continue to do so]
15:19:25 <contyk> distro-sync works on modular packages
15:19:31 <sgallagh> as part of our blocking criteria
15:19:33 <bowlofeggs> cool
15:19:35 <contyk> it doesn't do anything the currently non-existent modular database
15:19:47 <bowlofeggs> ok so we need to make a decision on what our criteria are
15:19:48 <sgallagh> right, what contyk said
15:20:18 * nirik is worried how late this is. :(
15:20:30 <sgallagh> I think "distro-sync must put all module RPMs at the currently-known versions for any enabled streams" should be one
15:20:40 <bowlofeggs> contyk: i'm not sure i follow that non-existant mdb comment - do you specifically mean it doesn't work if u-t is enabled, a module is installed, and then a distro-sync is run?
15:20:57 <bowlofeggs> and that we would need something like sgallagh's proposal for that to work?
15:21:10 <bowlofeggs> sgallagh: yeah that sounds good to me
15:21:39 <zbyszek> wait a sec
15:22:40 <jforbes> While I do agree that we need these protections in place, I am also concerned about making large dnf changes this late in the game.  How invasive is the changeset for non modularity users? (I know, we don't know the answer yet, but it should be considered when we do)
15:22:57 <zbyszek> sgallagh: that doesn't sound good. If I do 'install module A with u-t enabled', then 'disable u-t', then install B, I don't expect rpm to downgrade A
15:23:00 <sgallagh> To make that slightly more clear: A distro-sync must set all the RPMs, modular and non-modular, at the latest version for all module streams in accessible repositories"
15:23:00 <nirik> well, I dont know that there is a changeset. ;)
15:23:20 <sgallagh> zbyszek: Where do you get "install B downgrades A" from?
15:23:28 <sgallagh> That wasn't anywhere in the conversation that I saw
15:23:43 <zbyszek> from what you said "must put all module RPMs at the currently-known versions"
15:23:57 <sgallagh> zbyszek: I said *distro-sync* must do this
15:24:00 <sgallagh> Not install or upgrade
15:24:12 <zbyszek> Ah, sorry, I misread.
15:24:19 <sgallagh> No worries.
15:24:32 <bowlofeggs> yeah this is concerningly late
15:24:57 <contyk> bowlofeggs: dnf currently doesn't store modulemds in its database or anywhere, so if you lose access to the repodata and don't have it cached, dnf forgets what RPMs on your system are modular
15:25:06 <bowlofeggs> but as jforbes pointed out, there are copy-pasta users out there who this might negatively affect if we release with what we have now too :/
15:25:14 <contyk> bowlofeggs: the hope was to make dnf remember modulemds for enabled and installed content to avoid that
15:25:31 <contyk> bowlofeggs: the u-t case is just a simple reproducer/example of where you generally lose the repodata
15:25:37 <bowlofeggs> yeah cool
15:25:59 <bowlofeggs> the proposal does sound sound to me, but i also do worry about big changes this late in the cycle
15:26:11 <bowlofeggs> is it a big change?
15:26:13 <sgallagh> Another example would be a bad mirror that missed the modulemd, etc.
15:26:26 <nirik> I worry how long we will have to delay... this code isn't written yet right?
15:26:32 <contyk> I don't think it's necessarily a big change
15:26:36 <contyk> but what do I know :)
15:27:00 <sgallagh> Our team is also lending resources to DNF to try to do this for them.
15:27:15 <contyk> you could just keep the modulemds on the disk and concatenate that with whatever comes from repodata
15:27:16 <zbyszek> I think if we make this a hard requirement for F29 GA, we face a big delay, even in the best-case scenario
15:27:31 <bowlofeggs> i guess the question might be "which is worse? shipping the current dnf, or holding the release and possibly risking a buggier dnf"
15:28:11 <bowlofeggs> or if you are an optimist: which is better? ☺
15:28:14 <nirik> it's hard to guess without the code existing yet or the upstream dnf folks not yet wanting to write it. ;(
15:28:22 <sgallagh> adamw: Since I notice you're commenting on the bug, you may want to be involved in the conversation as well
15:28:38 <adamw> oh, you're talking about it now?
15:28:41 <sgallagh> Yup
15:28:50 <contyk> :)
15:29:00 <adamw> i honestly don't have a strong opinion about what the outcome ought to be, from a qa perspective we just need it to be clear what is expected to be 'done' here by f29 final
15:29:21 * sgallagh nods
15:29:41 <zbyszek> My proposal would be to *not* delay F29 for this
15:30:13 <zbyszek> I think this mostly affects modularity users, so just say "modularity is still in preview", and ship F29.
15:30:20 <bowlofeggs> would we be willing to allow a dnf update to stable to address this issue post release?
15:30:26 <sgallagh> zbyszek: In F29, all users are modularity users
15:30:30 <contyk> I wouldn't want to say it's in preview
15:30:42 <sgallagh> The repos are enabled for everyone and some packages (e.g. Maven) are only available now as modules
15:30:50 <bowlofeggs> yeah module repos are enabled on all systems now
15:31:05 <bowlofeggs> and some packages are becoming module only (like a big part of the java stack according to devel list)
15:31:12 <contyk> from my point of view this is a major issue
15:31:17 <nirik> well, I suppose we have next meeting before freeze... we could try and get code and convince upstream and decide next week? or ?
15:31:31 <contyk> as sgallagh said before, we probably don't need extra recovery mechanisms to clean up corrupted modulemd database
15:31:36 <contyk> I wouldn't block for that
15:31:39 <sgallagh> ack
15:31:52 <contyk> but keeping the very minimum on your system, I'd really like to see that before GA
15:31:54 <sgallagh> I think we want to block on situations that could result in getting incompatible updates
15:31:54 <zbyszek> ack
15:32:00 <bowlofeggs> i'd +1 a week of code proposing and further discussion
15:32:06 <sgallagh> (meaning updates that don't remain on the selected stream)
15:32:19 <nirik> stratis is another module only one I think... and thats a f29 change...
15:32:24 * sgallagh nods
15:32:25 <bowlofeggs> the argument that all users are module users now is compelling me to think this is important for f29 too
15:33:44 <bowlofeggs> proposal: let's give modularity+dnf folks a week to propose code and/or ideas and revisit next meeting
15:33:49 <sgallagh> Honestly, I think I could settle for "distro-sync must work as expected for available repos"
15:34:06 <sgallagh> As long as we have that, we can get out of any otherwise unexpected situations
15:34:11 <nirik> sgallagh: and 'available' means 'enabled' ? or 'ever been enabled' ?
15:34:16 <nirik> bowlofeggs: +1
15:34:32 <jforbes> I would really like to see some sort of estimates as to a) how long the dnf changes will take to actually implement, and b) how risky/invasive those changes are before making a final call. We don't have those. Hopefully we could get them in the next week.
15:34:40 <bowlofeggs> sgallagh: yeah that's a good point, but i'd think we'd need to define "as expected" a bit too
15:34:56 <sgallagh> nirik: The repo must be enabled and available. But the module RPMs must not change stream from "ever been enabled"
15:35:23 <sgallagh> They *can* downgrade if the repo only has older versions for that stream, but must not change streams
15:35:38 <zbyszek> bowlofeggs: +1
15:36:17 <sgallagh> Well, I'm hoping that by constraining the problem to the above, DNF can get us a fix even if it's not the complete one we hope for with the modulemd local DB
15:36:53 <sgallagh> Can we as FESCo agree that the distro-sync example I cited above is at least the minimum we need to be comfortable shipping?
15:37:12 <sgallagh> As I said, as long as we have that, users have an escape hatch from other issues.
15:37:36 <nirik> yeah, that seems reasonable...
15:37:37 <bowlofeggs> sgallagh: can you write up a proposal that expands the "as expected"? i'm in favor of the general idea, but would like something that defines the expectation a bit
15:37:40 <zbyszek> sgallagh: I can agree with that.
15:37:43 <bowlofeggs> like that stuff about not changing streams
15:38:01 <sgallagh> Yeah, I'll add something to the ticket
15:38:04 * sgallagh starts typing
15:38:29 <bowlofeggs> and what happens if the u-t update *is* a new stream?
15:39:04 <bowlofeggs> i guess that would be like installing an rpm from an enhancement u-t update that doesn't exist yet in the stable repos?
15:39:12 <bowlofeggs> i.e., a distro-sync would do nothign?
15:39:31 <bowlofeggs> sorry, s/enhancement/newpackage'
15:39:51 <bowlofeggs> or does distro-sync remove packages it doesn't see in teh distro?
15:39:57 <bowlofeggs> i guess maybe it does? /me can't remember
15:40:22 <zbyszek> Do we have agreement that sgallagh posts in the ticket, and we just ack bowlofeggs' proposal to wait a week for discussion?
15:40:33 <bowlofeggs> ah, distro-sync does not remove packages it doesn't find in the distro
15:40:46 <bowlofeggs> i have one RPM i made for myself on my local system and distro-sync does not propose removing it
15:41:09 <sgallagh> bowlofeggs: An update of a new stream is sort of like a new package. It should not impact the update process
15:41:28 <bowlofeggs> sgallagh: yeah that's how i see it too now that i think about it some ☺
15:42:02 <sgallagh> bowlofeggs, others: I just submitted my proposal to the ticket
15:42:16 <contyk> thank you
15:43:06 <nirik> https://pagure.io/fesco/issue/1974#comment-534269 for any looking for the link
15:43:24 <sgallagh> Thanks
15:43:31 <contyk> hmm
15:43:42 <nirik> so that would mean if there was a new default module it wouldn't enable on distro-sync?
15:43:44 <contyk> so "dnf update" could change streams?
15:43:57 <bowlofeggs> sgallagh: +1
15:44:18 <sgallagh> contyk: I wasn't setting a constraint on that in this proposal
15:44:35 <sgallagh> nirik: I expressly avoided talking about what the non-modular RPMs should do in that proposal
15:44:49 <sgallagh> But yes, a non-Modular RPM *may* become a modular RPM of a default stream
15:44:56 <sgallagh> If you want me to add that to this proposal, I can
15:45:14 <nirik> I doubt we can list all cases. ;)
15:45:23 <sgallagh> Right, but I think that one's probably worth it, actually
15:45:33 <sgallagh> Since it's going to become common as packages start switching over
15:45:39 <nirik> true
15:46:08 <bowlofeggs> +1 to the amendment
15:46:58 <zbyszek> OK, we have been on this for 45 minutes, and we have a concrete proposal
15:47:10 <sgallagh> Amended
15:47:14 <sgallagh> See the same link above
15:47:43 <zbyszek> proposal: table for a week, discuss proposal in the ticket, revisit next week?
15:48:00 <sgallagh> zbyszek: Seems reasonable, but given time constraints please discuss... soon :)
15:48:09 <nirik> +1
15:48:19 <bowlofeggs> sgallagh: +1
15:48:33 <contyk> I don't know, this seems like something totally different than what the bug is about
15:48:39 <nirik> I'm for the proposal I think, but it would be nice to get more input and think about it a bit instead of a few minutes monday morning. ;)
15:48:42 <contyk> and I think it already works, too (good)
15:48:43 <jforbes> +1 to table, but yes it *has* to be discussed next week.
15:49:05 <bowlofeggs> i could +1 rediscussing/checking-in next week
15:49:12 <bowlofeggs> but i also like the proposal
15:49:48 <contyk> +1 to another week of "offline" discussions and proposals
15:50:00 <jforbes> bowlofeggs: I like the proposal, I would also like to see some feedback from the dnf team on the proposal
15:50:14 <sgallagh> jforbes: Reasonable
15:50:39 <zbyszek> jforbes, nirik: sgallagh's proposal in the ticket is *not* being voted here
15:50:40 <bowlofeggs> sure
15:50:52 <sgallagh> contyk: I think we're probably 99% of the way there, but I still see at least one case that wouldn't  work, which is the original proposal I made this morning.
15:51:03 <jforbes> zbyszek: I know, I voted on your motion to table
15:51:14 <sgallagh> Install an RPM from a module that we no longer have any repo reference ofr
15:51:15 <sgallagh> *for
15:51:35 <sgallagh> This has to cover at least ensuring that this doesn't get "upgraded" back to non-modular
15:52:06 <sgallagh> Anyway, I'll stop talking now.
15:52:45 <zbyszek> ok, for clarity: sgallagh, bowlofeggs, contyk, can you please vote on *my* proposal explicitly
15:53:03 <bowlofeggs> zbyszek: +1
15:53:03 <contyk> zbyszek: and your proposal is which one?
15:53:18 <zbyszek> zbyszek> proposal: table for a week, discuss proposal in the ticket, revisit next week
15:53:30 <contyk> zbyszek: +1
15:53:53 <sgallagh> zbyszek: +1
15:54:31 <zbyszek> #agreed We table this for a week to give modularity+dnf folks time to discuss and respond to the proposed requirement. We will revisit next meeting. (+6, 0, 0)
15:54:34 <zbyszek> #info proposal for requirements for DNF behaviour at GA: https://pagure.io/fesco/issue/1974#comment-534269
15:54:37 <zbyszek> #info given time constraints, we ask for the discussion to start now
15:54:53 <zbyszek> The next one should be easier.
15:54:58 <zbyszek> #topic #1927 F29 Self Contained Change: Origin 3.10
15:54:58 <zbyszek> .fesco 1927
15:54:58 <zbyszek> https://pagure.io/fesco/issue/1927
15:55:00 <zodbot> zbyszek: Issue #1927: F29 Self Contained Change: OpenShift Origin 3.10 - fesco - Pagure.io - https://pagure.io/fesco/issue/1927
15:55:12 <bowlofeggs> several of us voted in ticket for this one
15:55:19 * zbyszek is counting
15:55:37 * jcajka is around if there are any questions
15:55:37 <nirik> +1 here
15:55:43 <zbyszek> we're at +4 in the ticket: jforbes, jsmith, zbyszek, bowlofeggs
15:55:58 <zbyszek> contyk ?
15:56:01 <contyk> +1
15:56:05 <sgallagh> zbyszek: You missed me. We're already +5
15:56:09 <sgallagh> Well, +6 with contyk
15:56:15 <bowlofeggs> +7 with nirik ☺
15:56:37 <zbyszek> Right.
15:56:57 <zbyszek> #agreed The update of the Change from 3.10 to 3.11 is approved (+7, 0, 0)
15:57:21 <zbyszek> #topic Next week's chair
15:57:36 <jforbes> I can do it
15:57:44 <zbyszek> Sorry for the late announcement today, I returned from ASG2018 late yesterday
15:57:58 <zbyszek> #action jforbes will chair next meeting
15:58:03 <zbyszek> #topic Open Floor
15:58:22 <contyk> thanks jforbes
15:58:33 <smooge> https://pagure.io/fesco/issue/1970
15:58:37 * bowlofeggs looks around at how wide and open this floor is
15:59:12 <sgallagh> smooge: Do you have a specific question?
15:59:26 <smooge> it is more of an ongoing issue
15:59:42 <smooge> s/ongoing/developing/
16:00:05 <zbyszek> This needs more manpower to be resolved.
16:00:12 <smooge> tibbs had a package for EPEL only which got orphaned by someone else
16:00:49 <tibbs> Actually the best I can figure out is that the act of unretiring that package removed my access completely.
16:01:10 <tibbs> And then the package was orphaned a few days after it was unretired.
16:01:20 <bowlofeggs> haha that's weird
16:01:39 <tibbs> I believe it was intentional to start the six week clock between orphaning and retirement.
16:02:23 <tibbs> But I didn't receive any notice that any of this had happened, and I didn't notice the state of the package between the unretirement and the orphaning.
16:02:31 <tibbs> So I don't know exactly what step removed my access.
16:02:44 <smooge> tibbs mentioned that ticket number so I wanted to bring it up in open floor as a heads up that FESCO may be seeing some upset packagers
16:02:53 <tibbs> https://pagure.io/fesco/issue/1970#comment-532232
16:03:04 <zbyszek> tibbs: I think the issue with python2-matplotlib is not directly related to teh main part of that ticket
16:03:09 <nirik> that seems like a non ideal process...
16:03:12 <tibbs> Well 1970 is the ticket and that's my comment requesting coordination.
16:03:29 <adamw> f29 blocker review meeting is starting up in #fedora-blocker-review now
16:03:34 <smooge> sorry for the slow typing.. I am trying to make sure I had accurate references
16:04:14 <tibbs> I didn't see the ticket at all until I was mentioned in it and basically just replied to the mention.
16:05:10 <zbyszek> tibbs: fwiw, I think what you are asking for in the last comment seems reasonable.
16:05:30 <zbyszek> I think this is a corner case with EPEL-only packages that we didn't consider.
16:05:49 <zbyszek> Maybe we can continue the discussion in the ticket?
16:07:30 <zbyszek> I wonder how many cases like this we have
16:07:38 <smooge> EPEL only packages?
16:08:31 <smooge> zbyszek, do you mean EPEL only packages or do you mean that would be alternative corner cases?
16:08:56 <nirik> note that you can override the bug owner for fedora or epel, ie, set that to orphan... but yeah
16:09:51 <zbyszek> not epel-only, but rather "we want to retire the Fedora package, but keep the epel one"
16:10:43 <smooge> most of the epel python2 stub packages
16:11:06 <zbyszek> Then it sounds like we need to adjust the policy to take this case into account.
16:11:09 <smooge> well in this case was this ever in Fedora?
16:11:55 <smooge> things like python34 python36 etc would also show up like that.. (and the php, perl etc )
16:12:18 <nirik> also there's the other case... something we want to retire in epel, but keep in fedora...
16:12:53 <smooge> and that case too :) [as nirik writes what I was working on]
16:12:53 <nirik> see also: https://pagure.io/fedora-infrastructure/issue/6241
16:14:05 <smooge> .. thought he had written about this a long time ago elsewhere ..
16:15:17 <smooge> has nothing more to add on this at the moment
16:15:33 <nirik> ideally we should document all these cases here... ;(
16:16:36 * zbyszek has nothing more to add either
16:17:00 <zbyszek> Let's continue the discussion in the ticket.
16:17:17 <zbyszek> Concrete proposal are welcome.
16:17:27 <zbyszek> Anything else for open floor?
16:18:07 <zbyszek> So see next week
16:18:08 <zbyszek> #endmeeting