Haikuports: [RFC] R1beta1 branch policy

[waddlesplash]

So, R1beta1 is fast approaching, and we need to decide how we are going to conduct the r1beta1 branch here. For Haiku itself, the r1beta1 branch will probably get only bug fixes as they come, without a lot of major changes that will probably hit master. HaikuPorts should probably do something similar; but the question is exactly what?

I think there are 3 general options:

1. Security updates only. This is the "debian"/"ubuntu" model: apply patches to only those packages that have published CVEs and patches for them. Do not bump even for minor bugfixes.
2. Minor bug-fix updates. Everything from # 1, but also include minor bug fix updates (e.g. 4.0.1 -> 4.0.2 of some software, assuming it follows Semantic Versioning.) This is what openSUSE does (? I think?)
3. Moderate feature updates. Everything from # 2, but also include moderate feature updates (e.g. 4.0.1 -> 4.1.0 of some software, assuming it follows Semantic Versioning.) This is what CentOS does (though they usually mark point releases when they do this.)

I'm heavily in favor of the second option. Thoughts, @fbrosson, @alaviss?

[waddlesplash]

oh, and @extrowerk too.

[pulkomandy]

On Fri, Aug 17, 2018 at 09:04:41PM -0700, waddlesplash wrote:

So, R1beta1 is fast approaching, and we need to decide how we are going to conduct the r1beta1 branch here. For Haiku itself, the r1beta1 branch will probably get only bug fixes as they come, without a lot of major changes that will probably hit master. HaikuPorts should probably do something similar; but the question is exactly what?

I don't agree on this for Haiku, the way I see it, the beta1 branch
there will eventually lead to R1. If beta1 is a throwaway branch and R1
is built from trunk, then beta1 isn't really a beta.

Anyway, let's focus on Haikuports here :)

I think there are 3 general options:

1. Security updates only. This is the "debian"/"ubuntu" model: apply patches to only those packages that have published CVEs and patches for them. Do not bump even for minor bugfixes.
2. Minor bug-fix updates. Everything from # 1, but also include minor bug fix updates (e.g. 4.0.1 -> 4.0.2 of some software, assuming it follows Semantic Versioning.) This is what openSUSE does (? I think?)
3. Moderate feature updates. Everything from # 2, but also include moderate feature updates (e.g. 4.0.1 -> 4.1.0 of some software, assuming it follows Semantic Versioning.) This is what CentOS does (though they usually mark point releases when they do this.)

I'm heavily in favor of the second option. Thoughts, @fbrosson, @alaviss?

1 is too much work for us. Let's rather get the bugfixes from upstream.

I would define things in terms of sonames, rather than semantic
versionning (which not everyone follows). So, what I would set as rule
is:

• Don't break ABI. If you make an update that has a soname change, make
  sure the old lib is still available (eg by renaming the package, as we
  do for "libong12", "libpng16" and the like)
• Make sure what gets into the branch actually works. This probably
  means a staging branch or something where recipes can be tested by
  "early adopters" before they are added to the depot

This is what I see as ideal for the R1 release. However it may turn out
to be too much effort, so we can try a simpler scheme for beta1 and see
how it goes.

[fbrosson]

We should probably also define a few sets of important packages:
1) a "critical" set with, among others, packages such as openssl, gnutls, coreutils, curl, libpng16, bash, perl, python, git, util_linux, harfbuzz, icu,
2) a "system sensitive" set with, among others, packages such as pciutils, libusb, libusb_compat, sdl, qt5,

And when ~_important changes_~ _risky commits_ to Haiku are planned, the packages in the above sets should be rebuilt and tested with the planned changes before these changes reach master.

EDITS:

• lsusb :arrow_right: libusb & libusb_compat
• important changes :arrow_right: risky commits

[pulkomandy]

On Sat, Aug 18, 2018 at 02:21:07AM -0700, fbrosson wrote:

We should probably also define a few sets of important packages:
1) a "critical" set with, among others, packages such as openssl, gnutls, coreutils, curl, libpng16, bash, perl, python, git, util_linux, harfbuzz, icu,
2) a "system sensitive" set with, among others, packages such as pciutils, lsusb, sdl, qt5,

I don't even understand why we have ports of pciutils and lsusb. Haiku
provides its own implementation of them (listdev and listusb) and I
would rather remove the Linux equivalents from our packages, as I don't
think they add any value, but they can bring some confusion.

And when important changes to Haiku are planned, the packages in the above sets should be rebuilt and tested with the planned changes before these changes reach master.

In the beta branch there should not be important changes to Haiku.

[fbrosson]

My mistake. We don't have a recipe for lsusb. What I had in mind when I wrote _lsusb_ was actually _libusb_ and _libusb_compat_.

I know risky commits are not supposed to happen in the beta branch. My suggestion to have a few sets of important packages (that we could try to build to make sure there are no regressions in Haiku) is actually for the "devel" branch.

[waddlesplash]

Someone should probably subscribe to the ubuntu-security-announce mailing list as part of this, as it's one easy location to get notifications about security updates, rather than trying to track projects individually.

[waddlesplash]

@fbrosson, @extrowerk, @alaviss: I've run an "everything" build to update all missing packages, and quite a few things failed: https://build.haiku-os.org/buildmaster/master/x86_64/?buildrunDir=1904&viewMode=expanded

I intend to branch Haiku master later today, and HaikuPorts within the next few days; so if you have time to perhaps investigate some of these (especially if there's any recipes you've written), that would be helpful.

[extrowerk]

Cloog: builds fine here
cutter: radare2 bumped, cutter fixed.
IBM-Plex: updated checksum
Libpurple: patched
mlpack: theoretically solved trough bumping armadillo
openscenegraph: synced patchset

[waddlesplash]

Haiku itself has been branched. I intend to wait to branch HaikuPorts till after the final WebKit and Mesa are in, which hopefully won't be too long. So you have a few days' grace remaining...

[alaviss]

@waddlesplash

To fix sys-fs/ddrescue, install lzip for the builders.

[waddlesplash]

https://github.com/haikuports/haikuports/wiki/HaikuPorts-Policies

[waddlesplash]

@kallisti5, @pulkomandy, and I wound up having another discussion on IRC the other day, and we decided that at least for the first while, we are not going to branch HaikuPorts. If/when master breaks ABI vs. the beta branch, and it's still within the window we want to provide support for the beta branch on, then we will cut a beta1 branch of HaikuPorts.

So, you have been forewarned ... test your recipes before pushing them!