Re: [Tails-dev] Automerge of devel into feature/buster?

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: tails-dev
Temat: Re: [Tails-dev] Automerge of devel into feature/buster?
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