11:03 a.m.
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).
11:39 a.m.
On Fri, 2017-02-24 at 12:03 -0500, 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.
This is correct, and jskladan is very strongly of the opinion that it
shouldn't.
AFAIK, there isn't yet
a database that says which tests need to pass to go, but Fedora does
need something like that.
This is also broadly true, AIUI. Ralph probably has a better overview
of where he wants to go with this sort of thing.
We have the same issue with compose gating. It is not an easy issue to
solve. What you wind up building is basically a true test case
management system, and they always tend to be awful. There is also a
substantial problem of who owns (and is responsible for) keeping the
information up to date and in sync with the actual test systems.
AIUI, right now Bodhi can *already* reject updates for failing
automated tests, but the update submitter has to manually declare which
tests the update will block on at the time of creation.
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
All I have to say on this one is that the problem is only going to get
bigger, because what I'm working on right now is having openQA test
updates and report those results to ResultsDB. So Bodhi's going to have
more results to show, very soon. Dunno what other input you're looking
for from me here.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:21 p.m.
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
10:25 a.m.
On Fri, 2017-02-24 at 11:21 -0800, Laura Abbott wrote:
I'm not sure how well these two would work as projects based on
what
you
described above plus what Adam had to say.
I think I agree.
> * Convert Bodhi's masher to use Pungi.
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?
I agree that it is not quite a beginner project. I've had a few talks
with lsedlar (he works on Pungi) about doing this. Some tasks that come
to mind:
* Learn about Pungi (I know little about it myself).
* Study the Bodhi code that composes OSTrees today.
* Identify any missing features in Pungi, potentially contributing to
Pungi what Bodhi needs.
* Replace that code with either API calls to Pungi, or by running Pungi
in a child process.
* Lots of testing.
* If the above goes well, a stretch goal could be converting Bodhi to
use Pungi to make its Yum repos as well.
> * Add bash completion to the bodhi CLI.
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.
Based on how frequently I get bug reports, I'd say it's a popular way
to use Bodhi. It allows developers to automate Bodhi, which is handy
for developers who have updates with lots of packages (like Gnome or
KDE). Some developers also prefer cli tools in general. The CLI itself
also lacks a lot of features that Bodhi 1 had, so improving the CLI
could also be a companion task for this project. This project should
also be a bit more beginner friendly than the others.
> * Port to Python 3.
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?
It is possible to do this in parts, and it is the kind of thing that
definitely could not be accomplished to completion in one summer. The
weird thing would probably be that we can't really convert Bodhi to
Python 3 until its dependencies are Python 3 compatible. This page
gives an overview of what's blocking Bodhi from being Python 3:
http://fedora.portingdb.xyz/pkg/bodhi/
Essentially, the project would really to be getting involved in one of
those blocking projects and working to get them to be Python 3. I could
certainly help mentor them, but I am not personally involved in those
project so it could be a little strange.
So what do I do now? Should we pick on of these to be "the project", or
should we just interview interns with these project-candidates in mind,
and try to pick an intern that seems good generally and then try to use
what we know about them to decide which project is best?
10:36 a.m.
Ooooh, one more idea I had that I think could be nice:
I had an idea last fall for a feature that could either be done in the
Bodhi CLI or as a dnf plugin that would allow users to install a Bodhi
update, or upgrade to a Bodhi update. The behavior of the two would be
slightly different: install would install all the subpackages found in
the update, where upgrade would only upgrade the subpackages that are
already installed on the client machine with the subpackages from the
update.
I think this would make testers lives a little easier, especially for
updates that have a lot of subpackages (like Gnome/KDE). I've not done
thorough asking-around to make sure something like this doesn't already
exist so I should do that, but it could be a fun and useful project.
10:41 a.m.
I love this idea! Would a newbie be able to do it?
~m
On 02/28/2017 11:36 AM, Randy Barlow wrote:
> I had an idea last fall for a feature that could either be done in the
> Bodhi CLI or as a dnf plugin that would allow users to install a Bodhi
> update, or upgrade to a Bodhi update. The behavior of the two would be
> slightly different: install would install all the subpackages found in
> the update, where upgrade would only upgrade the subpackages that are
> already installed on the client machine with the subpackages from the
> update.
>
> I think this would make testers lives a little easier, especially for
> updates that have a lot of subpackages (like Gnome/KDE). I've not done
> thorough asking-around to make sure something like this doesn't already
> exist so I should do that, but it could be a fun and useful project.
11:04 a.m.
On Tue, 2017-02-28 at 11:41 -0500, Máirín Duffy wrote:
I love this idea! Would a newbie be able to do it?
I think this one would be on the easier side of things compared to some
of the other ideas I've had. It should be a fairly simple operation to
query what builds are in an update using the Bodhi API and compare that
with which packages are installed on the local system to form a dnf
command.
10:50 a.m.
On Tue, 2017-02-28 at 11:36 -0500, Randy Barlow wrote:
Ooooh, one more idea I had that I think could be nice:
I had an idea last fall for a feature that could either be done in the
Bodhi CLI or as a dnf plugin that would allow users to install a Bodhi
update, or upgrade to a Bodhi update. The behavior of the two would be
slightly different: install would install all the subpackages found in
the update, where upgrade would only upgrade the subpackages that are
already installed on the client machine with the subpackages from the
update.
I think this would make testers lives a little easier, especially for
updates that have a lot of subpackages (like Gnome/KDE). I've not done
thorough asking-around to make sure something like this doesn't already
exist so I should do that, but it could be a fun and useful project.
Well, you can already do it with two commands. Bodhi 1.x:
1. bodhi -D (updateid)
2a. dnf update *.rpm
2b. dnf install *.rpm
Bodhi 2.x:
1. bodhi updates download --updateid (updateid)
2a. dnf update *.rpm
2b. dnf install *.rpm
You could in theory improve on this a bit for the 'update' case by only
downloading packages that would actually be involved in an update -
this would be a substantial help in a few cases, where there are
hundreds of subpackages in the update but you only need one or two.
However, this does get tricky because of renames: you can't just
download only packages that are already installed, you have to consider
packages that obsolete existing installed packages.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:09 a.m.
On Tue, 2017-02-28 at 08:50 -0800, Adam Williamson wrote:
Bodhi 2.x:
1. bodhi updates download --updateid (updateid)
2a. dnf update *.rpm
2b. dnf install *.rpm
You could in theory improve on this a bit for the 'update' case by
only
downloading packages that would actually be involved in an update -
this would be a substantial help in a few cases, where there are
hundreds of subpackages in the update but you only need one or two.
However, this does get tricky because of renames: you can't just
download only packages that are already installed, you have to
consider
packages that obsolete existing installed packages.
Yeah I do this when it's a large update (like KDE) now. That's what
made me think of this feature actually - I wanted to try a new KDE
update and it was a bit of a pain to avoid installing RPMs that weren't
already installed on my system, while still installing RPMs that were
actually new dependencies. I ended up making a crazy shell thing with
lots of grepping and pipes to sort it out in my case (because I didn't
want every KDE package, just the ones I use). I think it could be cool
to be able to be able to do something like this:
$ dnf bodhi_update FEDORA-2017-blahblahblah
and have it do "the right thing". We could also give a bodhi_install
that does install all of them for testers who prefer that behavior. Or
maybe there are better names. Or we could just give this feature to the
bodhi CLI itself, something like:
$ bodhi updates install --updateid (updateid)
$ bodhi updates upgrade --updateid (updateid)
I put a todo in task warrior to look into doing this myself, but it's
sitting pretty low on the list compared to my other tasks ☺
11:30 a.m.
On 02/28/2017 08:36 AM, Randy Barlow wrote:
Ooooh, one more idea I had that I think could be nice:
I had an idea last fall for a feature that could either be done in the
Bodhi CLI or as a dnf plugin that would allow users to install a Bodhi
update, or upgrade to a Bodhi update. The behavior of the two would be
slightly different: install would install all the subpackages found in
the update, where upgrade would only upgrade the subpackages that are
already installed on the client machine with the subpackages from the
update.
I think this would make testers lives a little easier, especially for
updates that have a lot of subpackages (like Gnome/KDE). I've not done
thorough asking-around to make sure something like this doesn't already
exist so I should do that, but it could be a fun and useful project.
I like this idea too!
2607
days inactive
2611
days old
outreachy@lists.fedoraproject.org
9 comments
4 participants
participants (4)
-
Adam Williamson -
Laura Abbott -
Máirín Duffy -
Randy Barlow