On 6/25/21 10:25, Neal Gompa wrote:
On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar
<l...@fedoraproject.org> wrote:
Hi list,
I own the rhcontainerbot account. Apologies it took so long to respond to this
thread. A number of legitimate concerns have been raised about the bot, so let
me address those below on behalf of the Containers team.
We have disabled all autobuilds for now.
The podman RC build landing in updates a month ago was a one-off and it has
been discussed at:
https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/
The fuse-overlayfs downgrade occurred unintendedly during the upstream branch
rename from master to main. That has been fixed at:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442
Disabling autobuilds during the branch rename phase would’ve evidently avoided
this issue.
Going forward:
We will only manually build upstream release tags for Fedora releases. We
would prefer to send RC tags to Fedora rawhide as that will trigger gating
tests and allow us to test podman with FCOS and toolbox CIs, so please let us
know if that would be a deal-breaker.
RCs and final releases are generally okay IMO even for stable
releases, as long as you're prepared to address feedback brought up in
bodhi updates. The problem here is nobody is paying attention to Bodhi
at all.
We may look at re-enabling the bot only for koji builds of upstream releases,
while bodhi updates will still be manual. We’ll make sure to check for
breakages / version downgrades before re-enablement. The bot has so far
compared upstream tags, rpm installability, version number sanity, but
evidently it has missed a lot of cases including git branch changes.
If we re-enable the bot, we will mention the human’s name and email for every
changelog entry in every relevant package as well as regularly monitor the
bot’s email. Please let us know if there are any concerns with this approach.
We will use openSUSE’s OBS for builds of the latest upstream commits for our
users who need the latest packages. We would need this to check if the latest
commits in podman work well with new kernel features and selinux.
Team members will not add karma to containers’ packages, with the exception of
our QE Engineer who owns our gating tests and is in charge of final testing of
our builds. Currently Ed Santiago (FAS: @santiago) owns that responsibility.
The important aspect isn't who is doing it, but that it's actually
*tested* to work. Very serious breakages have happened in the past,
and that's we want to avoid going forward.
And sometimes this breakage is caused by other parts of the system. For
example a kernel update caused breakage in Podman when it suddenly
enabled overlay mounts, which no one had tried. We quickly fixed the
container-selinux package to handle it, and got the fixes in F33 and F34
before the kernel showed up.
If we remove Podman updates from Rawhide other then when we prepare for
release. Their will be errors that do not get caught early.
Forcing us to treat Rawhide like we do F34 makes Rawhide less
interesting to the container effort.
We will also notify the containers’ communities that rawhide will no longer
contain the latest builds as some of them are accustomed to using.
Having a COPR would be nice for this. With tools like Packit and such
able to continuously build in COPR for every PR and every commit, you
can provide a fairly nice experience here. I do this with rpmlint, for
example.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
