Hi,
Sandro Knauß:
>> 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?
We built packages locally and upload them there ("Importing a new
package" section on that page).
> Okay let's summarize the current situation for feature/buster from my point of
> view:
This reflects my understanding of the situation as well.
>> 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.
Fully agreed. I've just done it and this time there was no conflict to
resolve whatsoever; I didn't check if the resulting feature/buster
builds on Jenkins yet (but it was broken before anyway). If that's the
main or only blocker for option A (vs. option C), then I volunteer to
do that myself regularly.
>> 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.
Absolutely.
>> 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'm fine with you folks trying this out for a while if you want, e.g.
until we ship a first public beta/RC with security support (once we're
there, I don't think that these lower expectations will fly anymore,
and we'll need to revert to either option A or B).
>> 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.
Fair enough. As you know, I personally think that the drawbacks of
removing this precondition outweigh the advantages, but I won't argue
endlessly about it and I'm happy to see you try your preferred way :)
> And if it is mostly about po conflicts, we can help the merge
> strategy for po files.
Right, it's good to keep this in mind!
Cheers,
--
intrigeri
