Hi, I'll first have to get some answers, as currently I feel that I have too less information to do a decision.
> 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. What is meant by "full-blown APT suite". Why we would need that for other solutions? How much work is this to maintain this? > - All our CI results are always about a product that makes sense. Well at least for my information state, I'd say no the CI gives wrong status. > 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"). Can you explain this? It all sounds like there is one level I don't really have in mind/understood. > 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. Are you talking about "packages built for the tails apt repository, that would also need to be rebuild for feature/buster"? > - 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. but we still need to merge such a patch to feature/buster. So a failing feature/buster makes sense for me in that case. > 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 > Cons: > - 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. Ah this sounds familiar ;D Okay I need to learn more about this before deciding. Your text sounds like, we should try to make it simpler. hefee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tails-dev mailing list [email protected] https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
