Hello! I went trawling through Bodhi's issue tracker today to try to
find some ideas for Outreachy this summer. I came up with a few:
* Integrate Bodhi's backend with ResultsDB so that updates can be
rejected for failing tests.
This one and the next are why I CC'd Adam Williamson, as there are a
few things about it that are unknown to me. I believe that ResultsDB
doesn't know which tests should or shouldn't block a build from going
out to users, just which tests passed/failed. AFAIK, there isn't yet
a database that says which tests need to pass to go, but Fedora does
need something like that. If we went this route, we could either have
an intern participate in creating such a database, or we could try to
create it before they start and then have them integrate Bodhi with
it and ResultsDB so updates can be rejected automatically.
* Rework how ResultsDB results are displayed on Updates.
Bodhi currently has trouble displaying all the ResultDB results on
Updates. For large updates, Bodhi resorts to only showing failures as
it would crush the web browser otherwise. It also doesn't display
them in a particularly useful/attractive manner.
This one would probably involve a lot of JS/CSS/HTML work, which to
be honest isn't my strong suit. That might not make me the best
mentor for it.
https://github.com/fedora-infra/bodhi/issues/983
Adam, you can ignore the rest of these unless you just want to read
more e-mail today.
* Convert Bodhi's masher to use Pungi.
Pungi is used to build Rawhide and Fedora releases, and Bodhi is used
to generate updates to Bodhi's releases after the fact. There is some
duplicated effort here, since Pungi and Bodhi both create repos and
OSTrees. If Bodhi instead used Pungi, Bodhi could delete a lot of its
code and could benefit from the work of others. This one could be
done in two stages: first we could convert Bodhi to use Pungi just
for OSTrees, which would be less invasive and have an immediate
benefit of Fedora finally having OSTrees for arches other than
x86_64. The stretch goal could be using Pungi to make the yum repos
as well.
https://github.com/fedora-infra/bodhi/issues/1219
* Add bash completion to the bodhi CLI.
This one could be fun. The bodhi CLI does have some dynamic options,
so it could be a fun way to learn how to use the REST API as well.
It's the kind of thing that could probably be done basically rapidly,
and then expanded on to make fancier as time allows. I.e., it'd be
easy to get something useful quickly, while also giving opportunity
for stretch goals.
https://github.com/fedora-infra/bodhi/issues/1188
* Port to Python 3.
Bodhi is on Python 2 and the date for Python 2 to go away is looming.
Unfortunately, converting Bodhi isn't so simple because we are
currently blocked by some dependencies, such as Koji.
This may not be the best idea for an intern, because it can't be
fully completed in a summer and isn't a feature (could be boring).
