16:00:26 <bcotton> #startmeeting Prioritized bugs and issues
16:00:26 <zodbot> Meeting started Wed Feb 26 16:00:26 2020 UTC.
16:00:26 <zodbot> This meeting is logged and archived in a public location.
16:00:26 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:26 <zodbot> The meeting name has been set to 'prioritized_bugs_and_issues'
16:00:27 <bcotton> #meetingname Fedora Prioritized bugs and issues
16:00:27 <zodbot> The meeting name has been set to 'fedora_prioritized_bugs_and_issues'
16:00:42 <bcotton> #topic Purpose of this meeting
16:00:43 <bcotton> #info The purpose of this process is to help with processing backlog of bugs and issues found during the development, verification and use of Fedora distribution.
16:00:44 <bcotton> #info The main goal is to raise visibility of bugs and issues to help  contributors focus on the most important issues.
16:00:46 <bcotton> #link https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/#_process_description
16:00:53 <bcotton> #topic Roll Call
16:00:59 <mhroncok> hey there
16:01:15 <bcotton> hi mhroncok
16:01:31 <mhroncok> hi bcotton
16:02:57 * bcotton patiently waits for mattdm
16:04:47 <mattdm> i am here!
16:04:53 <mattdm> i was in the wrong meeting room
16:05:05 <bcotton> welcome!
16:05:19 <mattdm> i mean, i was also in this one, but, not, like, with my *attention*
16:05:23 <bcotton> lol
16:05:26 <bcotton> #topic Nominated bugs
16:05:27 <bcotton> #info 5 nominated bugs
16:05:28 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&f1=flagtypes.name&f2=OP&o1=substring&product=Fedora&query_format=advanced&v1=fedora_prioritized_bug%3F
16:05:33 <mattdm> SO MANY BUGS
16:05:43 <bcotton> #topic installation of slf4j is broken unless maven module is disabled
16:05:44 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1801882
16:06:16 <bcotton> looks like some bugs have been cleaned up
16:06:24 <bcotton> #info BZ 1801882 is ON_QA
16:07:06 <bcotton> we're just waiting on verification that it works in the upgrade case
16:07:34 <mattdm> so, should we come back to this next meeting?
16:07:38 <bcotton> i'm inclined to go ahead and make a decision on this, since it's not for sure settled
16:07:58 <mhroncok> info: ...
16:08:10 <bcotton> go ahead mhroncok
16:08:47 <mhroncok> without default modular streams and with the highly likely resolution of the "modules breaking the upgrade path" by resetting them all upon upgrade, this is moot
16:09:08 <mhroncok> but the highly likely resolution is not yet decided 100 %
16:10:17 <bcotton> mhroncok: so should we wait 2 weeks (the next meeting) and see where it stands?
16:10:30 <mhroncok> that is a reasonable thign to do
16:10:37 <mhroncok> *thing
16:11:21 <bcotton> #agreed We defer decision on BZ 1801882 to see if the decision to drpo modular streams and reset all streams on upgrade is implemented and renders this moot
16:11:31 <bcotton> #topic kexec/kdump kernel fails to load with EFI secure boot enabled
16:11:32 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1651016
16:12:09 <bcotton> so this one is interesting. it's pretty old, and mjg is the assignee. AFAIK, mjg hasn't done much (anything?) in Fedora for a while
16:12:33 <bcotton> pjones has all of the commits to this package in the last two years
16:12:52 <pjones> okay so I guess we need a newer shim build to fix this.
16:13:12 <pjones> can we fix the default assignee to be bootloader-eng-team@redhat.com ?
16:13:19 <mattdm> yes we can :)
16:13:43 <bcotton> #action bcotton to change the default assignee of the shim component to bootloader-eng-team@redhat.com
16:14:01 <pjones> #action also for shim-unsigned-x64 and shim-unsigned-aarch64
16:14:01 <mhroncok> should we also change the main admin?
16:14:11 <pjones> what does "main admin" mean?
16:14:13 <bcotton> mhroncok: on src.fp.o?
16:14:19 <mhroncok> bcotton: yes
16:14:30 <mhroncok> cannot be a group but can be pjones
16:14:45 <pjones> oh, for the dist-git repos etc, sure.
16:14:48 <bcotton> wfm if pjones is okay with it
16:15:09 <mattdm> pjones: what's your assessement of the relative importance of this?
16:15:10 <bcotton> #action bcotton to get the main admin of the shim repo on dist-git changed to pjones
16:15:42 <mattdm> and, is changing the bug assignee sufficient for raising attention, or should we put it on the priority list so as to keep bugging you about it
16:15:50 <mattdm> no pun intended. *sigh*
16:16:03 <pjones> mattdm: I don't even know how to evaluate the "importance"; how many kdump/kexec users are there in fedora?
16:16:29 <pjones> mattdm: that having been said, there is an easy workaround, which is literally just to enroll /any/ key or hash on the local machine
16:16:31 <mhroncok> #info switched mjg59 with pjones as main admin of shim
16:16:38 <mattdm> apparently none since f28? :)
16:16:47 <bcotton> mhroncok++
16:17:20 <pjones> mhroncok: thanks
16:17:36 <mhroncok> as a side note, mjg59 is not in the packager group, so I cannot add them back as "admin"
16:17:37 <bcotton> there are ones of kdump-related bugs in Fedora
16:18:02 <pjones> that's fine, he hasn't participated (downstream in fedora) in quite some time
16:18:14 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=__open__&list_id=10871277&product=Fedora&query_format=advanced&short_desc=kdump&short_desc_type=allwordssubstr
16:19:19 <pjones> #info workaround is to use mokutil to enroll the hash of any binary or enroll any certificate
16:20:09 <pjones> so that list looks like only the one bug is related to this issue
16:20:50 <bcotton> so i guess the question then becomes: is this an uncommon use case and that's why it's been broken so long. or has it been broken so long because no one uses it
16:20:59 <bcotton> seems like the latter
16:21:33 <bcotton> -1 prioritized bug from me for that reason. assigning it to an active maintainer should be enough to move it along
16:21:39 <mattdm> I'm kind of inclined to say "this got missed because it was assigned to an inactive maintainer, and now it's assigned to the right place and will eventually get dealt with."
16:21:40 <mattdm> yes that
16:21:42 <pjones> wait that's the same thing just phrased two different ways
16:22:02 <bcotton> pjones: it is. i have a fever. i know what i meant :p
16:22:10 <pjones> okay, good luck with the fever.
16:22:46 <bcotton> but yeah, i meant "no one uses it because it's been broken so long" :-)
16:23:03 <mattdm> in any case, I support your -1. next bug :)
16:23:33 <pjones> anyway, it's fixed upstream.  Right now we're doing common criteria cert for RHEL, and that's going to inform some short-term and long-term fixes we need; after the short-term parts of that (and some debugging) I'll release shim-16 and it'll get fixed when I do builds+signing for that.
16:24:11 <bcotton> #agreed BZ 1651016 is rejected as a prioritized bug. Assigning it to an active maintainer should be sufficient to move it along
16:24:13 <mattdm> ^ that, but #info
16:24:16 <bcotton> pjones++
16:24:21 <mattdm> pjones++
16:24:21 <zodbot> mattdm: Karma for pjones changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:24:29 <pjones> #info it's fixed upstream.  Right now we're doing common criteria cert for RHEL, and that's going to inform some short-term and long-term fixes we need; after the short-term parts of that (and some debugging) I'll release shim-16 and it'll get fixed when I do builds+signing for that.  (Not promising to a specific timeline. ;)
16:24:35 <mattdm> thanks :)
16:25:04 * pjones goes back in hiding
16:25:23 <bcotton> #topic No checkbox to install updates in the shutdown dialog
16:25:24 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1805265
16:27:11 <mattdm> I think this probably should be prioritized, because I agree that without it many people are probably never applying updates
16:27:49 <mhroncok> I think that the workstation people should decide whether thay want this or not and if they do, this should be prioritized
16:28:13 <bcotton> yeah, the question is if we consider this a bug or a feature request
16:28:33 <mhroncok> if the checkbox went away by accident, then it's a bug indeed
16:29:45 <bcotton> yeah. i agree that this is a good thing to have, but idk if it's something we can push on the workstation team about if they're not in favor
16:31:31 <mattdm> that makes sense.
16:31:37 <bcotton> objections to me opening a ticket with the workstation WG and deferring a decision to the next meeting?
16:32:00 <mattdm> nope
16:32:04 <mhroncok> bcotton: +1
16:32:15 <bcotton> #action bcotton to open a ticket with the workstation WG
16:32:47 <bcotton> #agreed We will defer decision on BZ 1805265 until the workstation WG weighs in
16:33:05 <bcotton> #topic fedora:rawhide is significantly older than registry.fedoraproject.org/fedora:rawhide
16:33:07 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1601216
16:33:32 <bcotton> iirc, this is a process issue on docker's side
16:33:56 <bcotton> so idk if there are things we can do better or if it's a fact of life we have to deal with
16:34:19 <mhroncok> there is no response whatsoever in that bz
16:34:26 <cverna> yes we update registry.fp.o and quay.io nightly but DockerHub requires an PR to be reviewed by the Docker staff
16:34:41 <cverna> so that will not be possible to open a PR every day
16:35:07 <bcotton> cverna: do we have a regular schedule for this or is it done ad hoc?
16:35:25 <mattdm> cverna: is that a pr in github?
16:35:44 <cverna> it is meant to be done every 2 weeks, but it heavily depends on the compose status
16:36:15 <mattdm> how can that possibly scale, docker staff?
16:36:23 <cverna> mattdm: yes for example https://github.com/docker-library/official-images/pull/7495
16:36:41 <cverna> I don't know I don't work at Docker :P
16:36:53 <mhroncok> cverna: can we swamp them daily?
16:37:20 <cverna> mhroncok: I don't think that would be very nice to do that
16:37:29 <mhroncok> anyway, I am +1 to make it a priritized bug. it is sad that there has been no response there for ages
16:37:47 <bcotton> what outcome would come from prioritizing it?
16:37:49 <mhroncok> cverna: that was not really serious. but maybe we can auto-update the existing PR if not yet reviewd
16:37:55 <bcotton> like what do we expect to fix?
16:38:09 <mattdm> maybe we can ask docker what they'd like?
16:38:18 <mhroncok> bcotton: talking to docker
16:38:20 <cverna> mhroncok: the review is usually really fast no more than a day
16:38:42 <bcotton> the other approach is we could stop putting rawhide in docker
16:38:52 <bcotton> which doesn't sound ideal
16:39:07 <mhroncok> cverna: got it
16:39:32 <cverna> I don't think this is a bit issue tbh if you need fresh rawhide there are 2 options registry.fp.o and quay.io
16:39:48 <bcotton> cverna: is this something we can improve with some automation on our side?
16:40:02 <mattdm> cverna: it's confusing for them to be out of sync
16:40:16 <mattdm> cverna: you file the PRs manually now?
16:40:16 <cverna> it is already mostly automated expect from the create a PR on Githut part
16:42:31 <mhroncok> cverna: is it an access issue or do you need code that creates the PR (I have experience with writing such code)
16:42:39 <mattdm> I think maybe we should file a ticket asking docker what they'd like us to do?
16:42:51 <mattdm> mhroncok: are you volunteering? :)
16:43:13 <cverna> so currently I am using https://pagure.io/docker-image-release
16:43:35 <mattdm> also see
16:43:37 <mattdm> #link https://github.com/docker-library/official-images/issues/527
16:44:04 <mhroncok> mattdm: I should stop volunteering really :D
16:44:13 <cverna> the script does all the heavy lifting I just have to update the dockerhub config file and open a PR
16:44:59 <cverna> mhroncok: there is also a file to update with the new commits etc ... it can be automated we just need to work on it
16:45:18 <mhroncok> this is a lot of information to process
16:45:28 <mhroncok> can we at least make sure the BZ is updated with all of it?
16:45:47 <bcotton> mhroncok: ack
16:45:51 <cverna> ideally we want the registry.fp.o quay.io and dockerhub to use the same automation we have a releng ticket for that
16:45:55 <cverna> let me find it
16:45:59 <mhroncok> then we can say: for capacoty reasons, we won't do this, but you can start here if you like to help ...
16:46:08 <mattdm> we should also document that the docker hub image is expected to lag
16:46:29 <bcotton> so i suggest we reject this as a prioritized bug but put together an epic brief to get this on CPE's radar for their Q3 planning
16:46:51 <cverna> https://pagure.io/releng/issue/8270
16:47:02 <bcotton> #link https://pagure.io/releng/issue/8270
16:47:26 <cverna> this can be a good opportunity to contribute to releng
16:47:26 <bcotton> #undo
16:47:26 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fdfe8d7f0d0>
16:47:31 <bcotton> #link https://teams.fedoraproject.org/project/fedora-release-tooling/us/722
16:49:22 <mattdm> If epic brief is the only hammer we have, then, sure
16:50:06 <mattdm> The requirement is "we want fedora rawhide container images in at least quay.io and docker hub updated nightly"
16:50:26 <mattdm> + "and consistently"
16:50:28 <bcotton> proposed #agreed BZ 1601216 is rejected as a prioritized bug, but we will work to improve the process so that rawhide images are updated more frequently
16:52:18 <bcotton> thoughts? we're coming up on the end of the hour
16:53:10 <mattdm> sure
16:53:33 <bcotton> #agreed BZ 1601216 is rejected as a prioritized bug, but we will work to improve the process so that rawhide images are updated more frequently
16:53:36 <mhroncok> could we assign this to soembody who will respond?
16:53:49 <cverna> you assign it to me
16:53:53 <cverna> can*
16:53:56 <bcotton> cverna: thanks, will do
16:54:31 <bcotton> #topic moby-engine does not obsolete proper version of docker, upgrading to Fedora 32 is blocked
16:54:39 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1804305
16:54:58 <bcotton> i don't suppose this violates any release criteria?
16:55:45 <mhroncok> bcotton: it doesn't
16:56:09 <mhroncok> docker was not part of the standard package set in f30
16:56:59 <bcotton> is the solution as simple as fixing the spec file for moby-engine?
16:58:30 <bcotton> +1 prioritized bug
16:58:49 <mhroncok> bcotton: yes, but I don't want to do it as a provenpackager if the stuff that ends up on all the user machines who had docker installed is in fact not maintained
16:59:12 <bcotton> mhroncok: makes sense
16:59:14 <mhroncok> dee my comment that says I'd like podman to take ove instead
16:59:18 <mhroncok> *over
16:59:28 <mhroncok> *see
16:59:42 * mhroncok has lost the ability to type
16:59:49 <bcotton> #agreed BZ 1804305 is accepted as a prioritized bug
17:00:36 <bcotton> we'll skip the accepted bugs this time
17:00:39 <bcotton> #topic Next meeting
17:00:40 <bcotton> #info We will meet again on 11 March at 1600 UTC in #fedora-meeting
17:00:44 <bcotton> thanks everyone!
17:00:49 <bcotton> #endmeeting