Formalize a release strategy

[jhuntwork]

There is no formalized release strategy yet, though there is a basic concept in place. Having a documented release strategy will help set user and developer expectations, and should lead to improved quality.

Right now, the automatic build workflow will create packages on pull requests and publish them to the testing repo after the pull request is merged. This is working well enough for the moment, but there are at least two questions still:

• Does the testing repo need to be even more stable than this? Arch, for example, seems to publish things first to staging where it is expected that breakage can happen at any point.
• What is the time/process for promoting things from testing to core (or other production-ready repos)?

[lufv]

Does the testing repo need to be even more stable than this? Arch, for example, seems to publish things first to staging where it is expected that breakage can happen at any point.

Alpine only has testing but even it is rather stable which is great. On the other hand it means that packages need to wait longer to get merged. This can be a problem when in order to add a program some dependencies are needed in repo first. It seems that staging repo could solve this by allowing to add packages fast and then debug them on the system if needed.

[jhuntwork]

It seems that staging repo could solve this by allowing to add packages fast and then debug them on the system if needed.

So what would be the condition that triggers moving packages from staging to testing?

[lufv]

Maybe there could be an action that automatically merges package to staging if it passes lint and build tests. Then this package could be moved to testing or higher after being checked by contributors.

Edit to clarify a bit more: I see staging as repo that most people wouldn't have enabled on their systems. It probably would be extremaly unstable and in fact usable only for people developing packages.

[jhuntwork]

Yeah, that sounds good, I think that makes sense. Will have to think a bit about the specifics of implementing that. For example, I'd like the promotion from staging to testing and from testing to core to be automated, perhaps triggered by a specific type of commit merged into main. But I think we can go with that as a working proposal.

[fungilife]

My understanding:

When one person builds and uses in one system, no testing is needed. Although, just because you build a package doesn't mean you have to install it and use it right away. Sometimes you have to wait until you build ALL of its dependents, then install it, so they don't break. So you implement a staging for your own system. Once the tree of affected dependents have been built you can install "them" and rebuild them based on each other, so they don't break each other. Most importantly you don't want to break your builder/pkg-mngr or only a stable chroot can help you downgrade then.

If it is 2 people now, building and using, one must watch not to break the other's system. That is 2 people with dedicated pkgs one could be building the other's dependencies and v-v. So then for GE 2 builders, testing is needed and all have to be conscious of this testing functionality.

So staging, even though the pkg is perfect, it will break things if you install it. Testing will only break dependents that have not been built yet, so you install the testing pkg and build based on this upgrade. Testing is like telling your fellow builders to go repeat their tedious work. Things like icu glibc openldap, etc. must always go through the staging-testing-stable circle. With more than 1 builder, to avoid using staging and testing, you have to have really organized communication channels open at all times. This way nobody surprises anyone else.

Furthermore, for distros basing their system on another, and that build some of the pkgs on their own, then stable becomes like testing for them, lacking the internal communication that a dependency has been rebuilt. This is why in such distros pkgers should be running behind the mothership, and paying attention to testing, to have affected packages ready made to flush out to the repo. when testing pieces are thrown to stable. Obarun struggles with this all the time, artix, finally after years, having the resources and capacity, just copied everything from arch into their own, so they are not in a rush to rebuild and there are no external surprises.

So back to manpower, to create something like void-musl/alpine/adelie from scratch on different policy, assumptions, guidelines, for anything more than a very minimal base, is an enormous task for little benefit of being different. To build following Arch and using pacman/makepkg in any more intrusive way, other than substituting glibc for musl, is also madness. By the time you reach a stable wlroots, xorg, wm, it would take years of collaboration between 2-3 people.

So before staging-testing-tested-stable is decided upon, the question that needs answering is "WHY?" There is kiss,carbs,chimera,sabotage, and others out there waiting for contribution. Why is mere so different than those mentioned?

Building and using arch from source without systemd and pests, from 0, on glibc, has been hard enough for me. It has taken my free time for more than 4 months, I am still not done with core, although I have built some extra, and the product is used daily with everything else (+ everything that Obarun rebuilds, so it is complimentary to Obarun). Init tried has been s6-66, runit, sinit. When it reaches full success, I will start replacing everything with musl, see how far I go, no other changes intended.

[jhuntwork]

I believe I now have a solid enough plan.

In part, I believe it will benefit from also following through on #384 and separating out some things. While I don't know if it is entirely what @lufv had in mind when creating that issue, I think the release strategy and the improved CI/CD process mentioned in #560 will all benefit from creating a tight group of core packages, and then moving them into https://github.com/merelinux/core as a new repo.

That repo, in turn will correspond to "one" pacman repository. I say "one" because it will really be two, one main one and one associated testing one. In practice, that would be something like:

[core]
Server = https://pkgs.merelinux.org/$repo/os/$arch

And for testing:

[core]
Server = https://pkgs.merelinux.org/$repo/testing/os/$arch

pacman won't let you have both defined at the same time in the same system, but I think that's ok, for the way that we will rotate out testing.

Just for the sake of kickstarting things and testing out the waters, I think I will introduce a quick release cadence for core. Every two weeks, I will halt any additional changes to testing, and then sync testing to the main core repo. So that at the end of every two weeks, they are the same. We'll see how that goes for a bit, and if there are reasons to change the pace, or do anything differently, we can adjust.

For an initial idea of what will be in core, a package would need to fit one of the following parameters.

• It is required to run a minimal Mere system. (e.g., base-layout, pacman, busybox, s6)
• It is required to build any of those that fit the first criteria (includes custom tooling for development and CI/CD which will be turned into its own packages.
• Tools needed for setting up / installing Mere in some environments (e.g., e2fsprogs, parted, cloud-init potentially, etc). Will be evaluated on a case-by-case basis
• Simple services (e.g., nginx). Evaluated on a case-by-case basis, but running a simple web server is a primary use case for a minimal system.

So with those four principles in mind, I think we can begin moving things out of this repo into a new core one, tightening that up and creating the CI/CD tooling and workflow to match, and we'll have a release strategy in mind.

In the meantime, I haven't forgotten about other's requests to finalize desktop usage. I have firefox built again with the latest version, 108, and it's waiting to be added here. But I think I need to get this sorted out finally first.