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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.