Hey,
> 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.
What I find is not clear enough: How new packages enters the APT repo? Is
Jenkins building all packages and adds them to the repo when a tag was made,
for all suites?
* link to
http://mirrorer.alioth.debian.org/ (link should been updated ;D)
Okay let's summarize the current situation for feature/buster from my point of
view:
* low priority for FT
* no one is taking care of merging devel into feature/buster
- I only know that at the last sprint kibi said, that he'll try to get more
test data out of buster branch and not about merging. And I said I'll take
care about some tickets for buster in between.
- I don't knew, that we should have to made sure, that someone needs to do
periodically merges from devel into buster
* developed mostly in sprints
> A) Treat feature/buster as any other topic branch (status quo)
we need to make sure, that someone is taking responsibility to merge devel
into buster regularly. Otherwise this work it put on the shoulders for those
you want to do fix unrelated stuff and mixing different task in one branch makes
it all more complicate to do reviews and use the branch.
> B) Treat feature/buster as a "main" branch, like stable and devel
IMO think it is too much overhead for the moment. We may switch to this
solution if feature/buster needs a diff against devel packages. I think we will
switch to it if we focus more on getting a version ready for Buster.
> 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
For me this sounds like kibi and I see this branch. As long as the overlay is
small, that should be fine for the moment. And I am not arguing against merging
with devel I think this should be our way to solve things.
> 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 know both that releasing Buster tomorrow doesn't make sense, as Buster
isn't even released. I fully understand, that "can we merge devel into
feature/buster" is a very good question and the answer from CI is helpful. But
I don't see why "can I merge devel into buster" should be a precondition for
any review on the buster branch. And if it is mostly about po conflicts, we can
help the merge strategy for po files.
hefee
