Procedural Document for BL Release Lifecycle

jimjamz · 2022-12-03 12:34:53

As there is no PM feature any longer, this was originally for @johnraff, but I guess I can open it to a wider audience of contributors.

Do we have a procedural document available for what is involved during a release lifecycle of BL?
Given that Beryllium has taken far too long for an official release, it might be worth investing the time to document everything that goes into a release for the next BL distro when Bookworm is released this year (soft freeze in February, hard freeze in March 2023).
A procedural document should cover the lifecycle, ranging from the Debian-latest package compatibility research, planning and pre-requisites, through configuration, external contributions (e.g. themes and quality-of-life improvements to BL) to testing, release and hosting.

I would like to be involved where my skill-set allows, and having access to such a document, allows me to see where I can jump in and contribute.

johnraff · 2022-12-04 02:25:16

Jimjamz thank you for your wish to help with BL - it is appreciated!

As you know, we have been going through a difficult phase, but the delay in releasing Beryllium is not because of the distro itself, but because of a migration of the server, along with a major redo of our online infrastructure. This became necessary because of changes in the team and a need to adapt to present day internet regulations. It's very unfortunate that the issues arose just as Beryllium was almost ready for release, and it otherwise could have gone out early this year. As I'm sure you know, the beta iso has been available since July.

The migration work is now almost done, and in order to do an official release we now have to:
1) transfer the official BL package repo to the new server, bring it up to date with the experimental repo and sign it with the correct key
2) build the iso once more reflecting the (very small) changes done since July
3) upload the new beryllium isos to the new download server, along with bittorrent files, signatures etc
4) edit the information on the website to reflect the new situation
5) make the announcement here
6) spread the word on Distrowatch, Twitter etc

None of those steps are particularly difficult, but might take a couple of weeks, say. Work on a server requires root access so there's nothing an outside helper can do unfortunately, except perhaps with (6)

jimjamz wrote:

...it might be worth investing the time to document everything that goes into a release for the next BL distro when Bookworm is released this year (soft freeze in February, hard freeze in March 2023).
A procedural document should cover the lifecycle, ranging from the Debian-latest package compatibility research, planning and pre-requisites, through configuration, external contributions (e.g. themes and quality-of-life improvements to BL) to testing, release and hosting.

All these are excellent suggestions, but you hit the issue with "invest the time". Our development team is extremely small right now, with many outside commitments (this might change in the future) and just getting the server fixed up and Beryllium out of the door is all we can cope with.

As for the release path to Boron/Bookworm I currently see it as:
1) Set up a BL repository for the Boron packages. This time there will be no "experimental" repo - new packages will go straight into the official BL boron repo, which will be regarded as experimental up until the official release.
2) Incorporate any proposed changes into the Boron packages. I see those as being rather few this time.
3) Check Debian Bookworm for any infrastructure changes that might affect how BL operates. Fingers crossed that there are few (Debian usually changes rather slowly).
4) Create a suitable graphics stack (themes, images, configs). This might look similar to Beryllium, or might be quite different.
5) Ask users to try the Boron/Bookworm system (possibly unstable for a while) and report any bugs they find.
6) Around Debian Bookworm freeze time, declare a freeze on new feature suggestions here too, only fix bugs from that point.
7) Build a beta iso and share it for testing and more bug-checks.
8) Follow items (2) to (6) in the first list to release BL Boron, target release date this time just after Debian Bookworm release.

Sorry I just don't have the time to write out a proper document such as you describe, but I hope the above makes the release path a bit clearer for our users!

---
NB There are no PMs on this forum, but you can send an email to any user who has enabled them (as I have) using the email form.

Last edited by johnraff (2022-12-06 00:16:34)

or1o9 · 2022-12-06 04:59:39

johnraff wrote:

As for the release path to Boron/Bookworm I currently see it as:
1) Set up a BL repository for the Boron packages. This time there will be no "experimental" repo - new packages will go straight into the official BL boron repo, which will be regarded as experimental up until the official release.
2) Incorporate any proposed changes into the Boron packages. I see those as being rather few this time.
3) Check Debian Bookworm for any infrastructure changes that might affect how BL operates. Fingers crossed that there are few (Debian usually changes rather slowly).
4) Create a suitable graphics stack (themes, images, configs). This might look similar to Beryllium, or might be quite different.
5) Ask users to try the Boron/Bookworm system (possibly unstable for a while) and report any bugs they find.
6) Around Debian Bookworm freeze time, declare a freeze on new feature suggestions here too, only fix bugs from that point.
7) Build a beta iso and share it for testing and more bug-checks.
8) Follow items (2) to (6) in the first list to release BL Boron, target release date this time just after Debian Bookworm release.

A good summary @johnraff for the Boron/Bookworm development. Thank you for sharing it with us.

In my very humble opinion about this there are two points that stand out. These are #6, because if not there are no end to changes that might occur and that one have to invent solutions for new consequences that pops up if one keeps adding stuff.

And #7, an iso to install is crucial to get more testers. It just is a bit too much for many users to do the netinstall. That is the way it is. Plus, the installation process get to be tested too in addition to the finished setup of Boron.

Just my 2£ in these inflationary times we live in.

jeffreyC · 2022-12-06 05:24:50

An ISO is needed, I will not bother with a netinstall when trying out a distro or new release.
I want to see it working on that computer before installing it, not go through the install only to find out it does not work or end up cleaning up a failed install.

jimjamz · 2022-12-11 00:26:37

Thanks for the update @johnraff.
I appreciate that the server migration came at an unsuitable time, and there is certainly no criticism for how this has affected the velocity of any BL release.
I thought that a procedural document (even if it's a simple checklist) of the entire lifecycle for a single release) may expose areas where myself including others can feel confident enough to jump into certain sections of it and contribute. There may also be suggestions (like there already has in the thread) on offering ways to make the process more efficient or produce more value.
I'm not sure how such a lifecycle is managed by you, presumably hhh and nobody. Perhaps something similar to JIRA in order to help you track progress and address blockers.
I'm interested in the thought process and strategy taken for steps (2) and (3) - where it begins, what considerations and decisions need to be taken when implementing these new packages etc... even if this simply ends up in a @johnraff blog, it would still make good reading, and allow others to keep up to date with the progress and obstacles faced.

At the very least, I am willing to offer my time towards testing for Boron (pending availability when that test window occurs).
I'm aware of the Beryllium packages being available, as I've created by own unattended scripts to configure and install these packages for the Raspberry Pi4 (arm64), ThinkCentre Mini boxes (amd64) and Eee PC's (i386).

I'm happy to continue testing from netinstall, although I do appreciate not everyone will be in the same position to do so. I understand the requirement for some ephemeral beta ISOs which can be released and destroyed regularly enough so that they are regularly up to date.

or1o9 · 2022-12-11 06:41:06

There is also an official "Roadmap for Beryllium and Boron" thread in the News & Announcements section now.

https://forums.bunsenlabs.org/viewtopic … 46#p124846

hhh · 2022-12-11 06:44:43

^ Official? Yes, in the sense of the Pirate Code from the Johnny Depp films. To paraphrase "It's more of a guideline, really".

johnraff · 2022-12-13 04:34:06

jimjamz wrote:

At the very least, I am willing to offer my time towards testing for Boron (pending availability when that test window occurs).

Much appreciated!
There's a little bit more about ways people can help in the announcement I posted (mostly copied from here):
https://forums.bunsenlabs.org/viewtopic.php?id=8329

#1 2022-12-03 12:34:53

Procedural Document for BL Release Lifecycle

#2 2022-12-04 02:25:16

Re: Procedural Document for BL Release Lifecycle

#3 2022-12-06 04:59:39

Re: Procedural Document for BL Release Lifecycle

#4 2022-12-06 05:24:50

Re: Procedural Document for BL Release Lifecycle

#5 2022-12-11 00:26:37

Re: Procedural Document for BL Release Lifecycle

#6 2022-12-11 06:41:06

Re: Procedural Document for BL Release Lifecycle

#7 2022-12-11 06:44:43

Re: Procedural Document for BL Release Lifecycle

#8 2022-12-13 04:34:06

Re: Procedural Document for BL Release Lifecycle

Board footer