Thanks for putting these together! I'm going to make commentary
on things I know nothing about so please correct me if I get stuff
wrong.
On 02/24/2017 09:03 AM, Randy Barlow wrote:
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
I'm not sure how well these two would work as projects based on what you
described above plus what Adam had to say.
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
I like this one for being concrete work that it sounds like it needs
to happen anyway. From the description it sounds like this could be
an intermediate to advanced project? Do you have an idea what subtasks
might involve?
* 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
This also looks like a good project. How widely used is the bodhi
CLI? I ask for my own biases because I've only ever used the web
interface.
* 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).
This could be more workable than you think. One of the past Outreachy
rounds for the kernel had someone working on converting over parts
of the kernel to be year 2038 compatible (32-bit timestamps). She
did patches for different parts of the kernel. Is it possible to
do this in parts?
Thanks,
Laura