#41 Run a Fedora 34 retrospective after GA release
Opened 3 years ago by jflory7. Modified 2 years ago

Summary

Run a retrospective on our work to produce a Spin this first time and document our processes/workflow

Background

The i3 SIG spans four continents. For all of us, this was our first time going through this process. We learned a lot, like the differences between package groups and fedora-comps, the fedora-kickstarts repo used for release images, and the pungi-fedora repo for nightly builds.

Now that we are almost finished with this process, we should reflect on how we manage our kickstarts and which bits are distributed across repositories. This also makes it easier to on-board newcomers to the SIG because we will better document the work required to ship new releases and ISO builds.

After the Fedora 34 release, we should pick this ticket up in a synchronous meeting. In the meantime, any notes or comments to note are welcome in this ticket.

Details

Our retrospective should be documented somewhere. We can start with this Pagure ticket to track ideas, and later move to an Etherpad/HackMD pad after the Fedora 34 release.

The final deliverable to complete this ticket is new and/or improved documentation on how to prepare a Fedora i3 Spin for new Fedora releases.

Outcome

  • Reduce bus factor of project maintainers by documenting how we built the i3 Spin
  • Improve on-boarding of new contributors with clear places to include others

My top wish is better management of our kickstarts. Some of our work is duplicated across multiple repositories. Where possible, we can stop maintaining some files in our repositories and instead maintain them in the upstream repository where Fedora Infrastructure actually runs composes from.

Part of this is documentation, part of this could be fancy scripting to figure out how we make our release deliverables. Will revisit after F34. :three: :four:

My top wish is better management of our kickstarts. Some of our work is duplicated across multiple repositories. Where possible, we can stop maintaining some files in our repositories and instead maintain them in the upstream repository where Fedora Infrastructure actually runs composes from.

Part of this is documentation, part of this could be fancy scripting to figure out how we make our release deliverables. Will revisit after F34. :three: :four:

And we should contribute this documentation to the Fedora docs, so that
new SIGs can get started more easily.

We should look at the Fedora i3 Spin website and add to the page. @bcotton mentioned we can show applications, icons/screenshots, and a description to go along with them. We should make sure the information found there about the S.I.G. is accurate.

https://spins.fedoraproject.org/i3/

Discussed in 2021-05-18 meeting.


We ran a short retrospective in the meeting. It suffers from convenience bias, but it is a first attempt at capturing some of our pluses and minuses from the Fedora Linux 34 release cycle:

positives

  • (+) Caught many bugs during Beta freeze and fixed problems before releases
  • (+) We have nightly ISO composes thanks to RelEng / Fedora QA!
  • (+) The Respins SIG helped us with lessons learned and experience on common bugs with making Spins from kickstarts
  • (+) Great feedback from Reddit and Fedora Magazine, it helps to publish news there!

negatives

  • (–) lack of default tool/utility to change brightness
  • (–) azote shipped for wallpaper management, but does not run
  • (–) Kickstarts are difficult to manage. We have different upstream versions (our Pagure repos) from downstream versions (RelEng composes and builds)
  • (–) Some advanced users were underwhelmed by the i3 Spin and that it was mostly vanilla i3.
    • Note: We are discussing a new package of default config changes, see #49.
  • (–) urxvt was underwhelming as a default terminal. It was not the most aesthetically pleasing option.
  • (–) Sometimes it was hard to know where to point newcomers on how they could help us with the Spin
  • (–) Lack of a welcome guide / on-boarding steps for new contributors on how to get involved
  • (–) Need better guidance on how to propose new articles or guides in the Fedora i3 SIG documentation

miscellaneous

  • A common question we were asked us why not Sway.

Login to comment on this ticket.

Metadata