Ideas for Outreachy 2021 internships

[miabbott]

https://www.outreachy.org/

Interns work with experienced mentors from open source communities. Outreachy internship projects may include programming, user experience, documentation, illustration, graphical design, data science, project marketing, user advocacy, or community event planning.

3 months - internships run May 24 to August 24

---

We may have the opportunity for an Outreachy intern to work with the Fedora CoreOS community during the May to August timeframe.

I would like to collect some possible proposals from the community that could be handled by an intern during the course of 3 months.

Things to keep in mind:

• we only have 3 months to onboard an intern and make them successful
• ideas can come from outside of the usual engineering space
• we'll need one or more people to act as mentor(s) for the intern, in addition to folks usual $DAYJOB

Original List of Ideas from RHT internal mail

• design + implementation of community blog
• Integrating FCOS CI into Bodhi
• Adding FCOS to Fedora Media Writer
• Automatic rollback
• Making declarative and adding sugar for package layering
• Help with streamlining the FCOS release process
• CLI improvements

I think our time may be limited to come up with ideas (intern applications to Outreachy are due Feb 22) so if we feel strongly about any one idea, let's start the ball rolling on it.

cc: @jasonbrooks

[cverna]

I would +1 improving the FCOS release process because :

• we can split the tasks in different milestones and adapt the goal of the project to the intern progress (using stretch goals for example)
• we already have ideas on what can be done to improve the process
• Don't require very specific skills set to complete the work which allow us to have more candidates :-)

If we are happy to go with this project, I think the next step is to put together a list of tasks and see how these would fit within the 12 weeks schedule.

[jlebon]

I would +1 improving the FCOS release process because :

Was thinking about this. I know I'm the one who initially suggested this, though I do wonder still if it's too vague as an overall deliverable to be an internship project. Contrasted with something like "automatic rollback" for example, which has a clearly defined outcome. (That one would be super cool, though it might be too much for a 3 month internship.)

Not sure. I think we could make it work, though might be worth deliberating a bit more for a "crisper" project idea. WDYT about the "FCOS CI in Bodhi" one? Let's say the outcome is something like "FCOS tests are run on a subset of packages in Bodhi". The rough steps for that can be extracted out from the convo in #17 (comment), and I think it would really benefit FCOS and Fedora in general. (But we'll probably want to make sure we can lean on @AdamWill for help in mentoring).

[jlebon]

Some super recent examples of things we could've caught: the recent libsolv mess, SSSD unnecessarily shipping setuid binaries, and also I learned today that the latest Clevis release breaks TPM2-pinning in FCOS, though I haven't debugged it yet.

[AdamWill]

Yeah, no problem. In case this is useful: If you're just talking about taking the set tests we already run on CoreOS nightlies, and also running it on updates for the releases we currently run update tests on - which is Branched after Bodhi enablement, and stable releases - that's not a huge project. The trickiest part is figuring out where exactly to start the tests off from, but it's wrangle-able in several ways. That's probably only a few days of work for me or lruzicka. For someone starting from scratch it'd be maybe two weeks to a month of learning how openQA works and how we do scheduling in Fedora, then a few days of work. :)

Running the tests on Branched before Bodhi enablement and/or on Rawhide 'updates' is a bigger and squishier job because we don't run any tests on those updates currently, and it involves quite a lot of moving parts. Doing 'update' testing on Rawhide is actually something I want to try and get somewhere with this year, but it's complicated.

[jlebon]

Yeah, no problem.

Awesome, that's good to know! :)

In case this is useful: If you're just talking about taking the set tests we already run on CoreOS nightlies, and also running it on updates for the releases we currently run update tests on - which is Branched after Bodhi enablement, and stable releases - that's not a huge project. The trickiest part is figuring out where exactly to start the tests off from, but it's wrangle-able in several ways. That's probably only a few days of work for me or lruzicka. For someone starting from scratch it'd be maybe two weeks to a month of learning how openQA works and how we do scheduling in Fedora, then a few days of work. :)

Yeah, I was talking about releases we already run updates on. But to be clear, it would be kola tests, not the tests that openQA currently runs (or at least in addition to those). So essentially: Bodhi systemd update is opened, we run a cosa compose with current FCOS + systemd update, run at least kola run, but possibly more (could be package dependent), and then report back the results.

[AdamWill]

Ah, K. If it's not going to use openQA's existing tests or capabilities, it may make sense to do it in Fedora CI instead. Not sure who's the best contact person for that, ask in #fedora-ci on IRC...

[jasonbrooks]

I just spoke to Marie about deadlines for this. In order for it to be vetted by Fedora and entered into the Outreachy system in time, we need to get a project idea added to https://pagure.io/mentored-projects/issues by the end of this week.

[cverna]

Not sure. I think we could make it work, though might be worth deliberating a bit more for a "crisper" project idea. WDYT about the "FCOS CI in Bodhi" one? Let's say the outcome is something like "FCOS tests are run on a subset of packages in Bodhi". The rough steps for that can be extracted out from the convo in #17 (comment), and I think it would really benefit FCOS and Fedora in general. (But we'll probably want to make sure we can lean on @AdamWill for help in mentoring).

Sounds good to me :-)

[travier]

This has been discussed in today community meeting.

@jlebon and @travier will take an action to submit a proposal for one of the two rpm-ostree ones (TBD):

• sysusers support: Drop requirement on nss-altfiles, use systemd sysusers rpm-ostree#49
• origins / local / repo overrides support: Support non-local (repo) overrides rpm-ostree#1265

[travier]

Submitted https://pagure.io/mentored-projects/issue/99

[travier]

@jlebon How do you feel about closing that one now?

[jlebon]

@jlebon How do you feel about closing that one now?

Yeah, let's do that. :)
(And if anyone else is interested in submitting another proposal, please re-open!)