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
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.
