Hi,
Cyril Brulebois:
> […] the build in Jenkins failed because devel is automatically
> merged into it.
Yes, so far feature/buster has been treated like any other topic
branch, i.e. its base branch is "devel", and then when building
feature/buster:
1. As you've noticed, on Jenkins we merge devel into feature/buster
2. We use the "devel" APT suite as a basis, and on top of that we have
very few Buster-specific packages in the feature-buster
overlay suite.
> Does this automatic merge (due to config/base_branch I assume) make
> sense, as we're going to merge devel into it in a regular manner anyway?
> (Right now, that means somebody would have to fix the conflicts before
> we get a build and the resulting test suite run…)
Glad you're asking!
I believe there are three main ways to handle this. We've tried the
first two ones below (A and B) extensively. You might be proposing
a third one (C):
A) Treat feature/buster as any other topic branch (status quo)
Pros:
- We don't have to maintain a full-blown feature-buster APT suite.
- All our CI results are always about a product that makes sense.
Cons: when merge conflicts happen, until someone manually resolves
them, we have no CI results at all.
B) Treat feature/buster as a "main" branch, like stable and devel
Pros:
- No automatic merge so as long as changes in Debian don't break
stuff, the branch should always build on Jenkins ⇒ more data
from our CI.
Cons:
- We need to maintain a full-blown feature-buster APT suite.
We've done that in the past and it's been super painful and
error-prone (as in: "oops, I've replaced Buster-specific
packages with Stretch-specific ones in feature-buster").
Our release process doc assumes we're in this case but very
often, in this option the "merge devel into feature/buster" step
is just too hard _at the APT level_ so the RM skips it, and in
the end feature/buster lags behind devel like crazy most of the
time. Or sometimes even worse, it's in sync' at the Git level
but outdated at the APT level, which gives very
confusing results.
- The data we get from our CI is not very valuable as most of the
time, we're testing the port of an obsolete codebase to Buster.
E.g. as of today, feature/buster is lagging behind devel by
3 weeks.
- Sometimes feature/buster will FTBFS because it needs an update
that's been done in devel (e.g. Linux ABI bump). So all in all,
we don't necessarily get more data from our CI.
C) Treat feature/buster as a special case, i.e. use devel APT suite as
a basis + feature-buster overlay, but no automatic Git merge from
devel into feature/buster
Pros:
- We don't have to maintain a full-blown feature-buster APT suite.
- No automatic merge so as long as changes in Debian don't break
stuff, the branch should always build on Jenkins ⇒ more data
from our CI.
Cons:
- Mismatch between the code in Git (based on an old version of the
devel branch) and the packages installed from the devel APT
suite ⇒ CI results are at best low-value for the same reason as
in option B, and worst case they're super confusing (the code
assumes given package versions and vice-versa). If we go this
way, I suspect we'll spend more time debugging issues that would
be solved by merging current devel into feature/buster, than the
time it takes to resolve merge conflicts with option A.
- One more special case to reason about. I've found our whole
Git/APT integration to be one of the most complex pieces in the
Tails build system puzzle for newcomers and long-timers alike to
wrap their mind around. Making it more complex will make it
even harder.
- Sometimes feature/buster will FTBFS because it needs an update
that's been done in devel (e.g. Linux ABI bump). So all in all,
we don't necessarily get more data from our CI.
Personally, I very much like the simplicity and predictability of
option A. In my experience, dealing with these occasional merge
conflicts is simple in the vast majority of case: most of the time
they're in PO files, and until we start merging Buster-specific
translations into feature/buster, one can pick the versions from
devel, then run ./refresh-translations, then git add + commit and be
done with it. So I'm quite convinced that the savings we would get
from option C don't outweigh its drawbacks.
Now, I'm not going to work on feature/buster between sprints, so I am
happy to let those who will work on it pick the option they prefer :)
Cheers,
--
intrigeri
