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
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
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
* 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
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:
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?