Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] Diversions of bundled packages due to Tails
point-releases [Was: Please review feature/consistent-persistence-path]
19/08/13 22:28, intrigeri wrote: > Hi,
>
> anonym wrote (19 Aug 2013 12:24:46 GMT) :
>> Or have I missed something obvious?
>
> How about we use on 0.7.16.1 for the next point-release's l10n
> updates, and keep 0.7.17 for the next major release (with your new
> feature in)? This way, 0.7.17~$N >> the version in the point-release.
>
> If we go this way, perhaps it's time to change t-g's versioning
> scheme, and e.g. go for 0.7.17 (point-release) and 0.8 (targeted at
> the next major release).
>
> What do you think?
It definitely sounds like an improvement. However, I can also foresee
issues when merging diverging snapshots of the same bundled package into
Tails' devel and experimental APT suites. The core of the problem is
that our bundled .debs are separate from our Tails git which complicates
our merge based work flow; after all, .debs in our APT suites cannot be
merged, they just replace one another, so an APT suite merge may in fact
remove functionality unlike a properly handled git merge.
This could be especially problematic in experimental: a bundled package
can be replaced before it has been reviewed, and depending on what the
branch is about (imagine one that doesn't change functionality, like a
refactoring branch), it may get merged without its code actually having
been tested, because "testing looked good". This could bring some nasty
surprises for the RM at release time. For devel and stable the same
applies, which is less problematic, but it means they would
intermittently be in states where they don't have all functionality
that's supposed to have been merged into them.
Maybe our bundled packages' git repos and work-flow need to more closely
mirror our Tails git repo and work flow, e.g. each have the following
branches:
experimental: *all* features and bugfixes up for review should be merged
into it, and the snapshot uploaded to Tails experimental APT suite
should be built from this branch.
devel: after a review ACK of a new feature or bugfix, it's merged into
this branch and a new snapshot is built and uploaded to Tails devel APT
suite. Note that all such snapshots will be replaced with a proper
release when the RM builds this branch during the release time of the
next Tails major release.
master (corresponds to Tails' stable): after a review ACK of a new
bugfix, it's are merged into this branch and a new snapshot is built and
uploaded to Tails stable APT suite. Note that all such snapshots will be
replaced with a proper release when the RM builds this branch during the
release time of the next Tails point-release.
I'm not sure I actually propose that we start following this procedure
as it adds a fair bit of overhead, but I at least hope it makes clear
the problem as I see it. Or do we think that we can just go on solving
these situations in an ad-hoc, case-by-base basis without experiencing
major headaches along the way?
