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