Hi,
Sandro Knauß:
> intrigeri:
>> 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".
An APT suite that has _all_ our custom packages, e.g. tails-greeter.
At the moment our "devel" suite has 41 source packages. Chances
are that feature-buster would have slightly fewer packages.
With the current setup we don't need that: a build of feature/buster
will use the "devel" APT suite.
> Why we would need that for other solutions?
For B, that's basically the definition of a "main" branch: it lives in
isolation and is not built on top of another "main" branch.
For C we don't need that by definition of "use devel APT suite as
a basis + feature-buster overlay".
> How much work is this to maintain this?
Very rough estimate: I would expect 30-120 minutes of work after each
Tails release, depending on many factors.
>> - 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.
I understand we have different expectations wrt. what our CI is
supposed to tell us. I guess that's because you and I are implicitly
asking different questions to our CI.
The question I personally care about most is: "could we merge and
release this branch tomorrow?". The current setup correctly answers
"nope" for feature/buster. Options B and C would sometimes incorrectly
answer "yes". But the "yes" you would like to hear may very well be
the correct answer to another question, i.e. the one you're most
interested in personally :)
>> - 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.
Sure. I've answered part of it above. On top of that, please read the
"Overview" and "Build system" sections of the corresponding doc:
https://tails.boum.org/contribute/APT_repository/custom/ then let me
know if there's anything left unclear.
>> 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"?
Indeed, they're the biggest problem:
- We may have to update, build and upload them (e.g. once Tails
Greeter has itself a feature/buster branch).
- We have to ensure we don't replace them with a Stretch version.
We currently lack the tooling we would need to do this with great
confidence and avoid such mistakes.
(In the "Merging a main branch"instructions of the aforementioned
documentation, this is "Make sure you are not going to overwrite
newer packages with older ones".)
>> - 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.
Glad we're on the same page. I wrote this because the main (only?)
advantage of the B option is precisely the hope we would get more data
from our CI… and it turns out it's not clear that would be the case in
practice, so the drawbacks of option B seem to vastly outweigh its
potential advantage.
>> - 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.
FWIW anonym & I have occasionally dreamed of encoding more stuff about
our custom packages in Git, so that it's clearer at the Git level
what's going on, and possibly we would need something like that for
#14455. But it's a big project and it's not clear to me that it'll
decrease the complexity much (I would bet it'll mostly move the
complexity elsewhere).
Cheers,
--
intrigeri
