> ticket: https://labs.riseup.net/code/issues/5854 > Tails branch: feature/consistent-persistence-path > Tails Greeter branch: feature/consistent-persistence-path > > I'd like to ask for a merge, too, but I'm unsure of how our merge > process handles this case.
So, if I had merged the tails-greeter feature branch into its master, then this new *feature* would end up in the next release of t-g, and so in the next point-release of Tails, which we don't want. Therefore I instead built a t-g snapshot, 0.7.17~1*, from the feature branch, and uploaded it. The problem is this: If we merge this feature into devel (both Git and APT) soon, then we'll lose the feature introduced in t-g snapshot 0.7.17~1* when we merge stable into devel (APT) after the next point release, since it'll be replaced with 0.7.17, which only has new translations/bug fixes. In this particular case, it'd mean that the additional packages persistence feature breaks. To avoid this broken state, it seems the post-release process would require rebuilding e.g. a new t-g snapshot (e.g. 0.7.18~1*) with this feature and upload it to devel right after the APT merge of stable into devel. In the worst case this can mean that the RM has to rebuild and upload each bundled package twice for each release. A simpler approach may be to wait with the merge (both Git and APT) of branches like this until the preparation of the release candidate of the next major Tails release. The submitter would still have to build and upload a snapshot to the feature branch so it can be properly tested and reviewed way before the release process starts. Of course, the merge could still introduce conflicts or other issues, but at least it then happens during RC time. Or have I missed something obvious? Cheers! _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev