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