Hi,
anonym wrote (04 Sep 2013 11:18:19 GMT) :
> 19/08/13 22:28, intrigeri wrote:
>> 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.
For experimental: yes.
For devel: I don't think we should merge *snapshots* into devel.
IMHO a t-p-s or t-g branch that is deemed worth merging into devel at
the Git level, should be merged at the APT level in the form of a new
t-g or t-p-s release, not a snapshot.
> 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 is certainly a problem in theory.
> 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.
I don't get how stable or devel could be in this state. May you
please clarify?
> 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: [...]
> devel: [...]
OK.
> master (corresponds to Tails' stable): [...]
I'd rather call it `stable', so that we have 1-1 mapping with the main
Tails repository.
> 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?
I actually have been tempted to propose something like this a few
times. I suggest we think of it more seriously once it hits us in
pratice often enough, or when we have automatic Debian package build
and upload, as in:
When I merge feature/XXX into t-p-s devel branch
And I prepare a new t-p-s release in this branch
And I push a signed tag to t-p-s Git repository
Then a new .deb is automatically built and added to the devel APT suite
... or perhaps even something more streamlined, with t-p-s and friends
becoming submodules of the main Tails Git repository, that would
enforce the Git --> APT relationship more strictly, like:
When I merge feature/XXX into t-p-s devel branch (and push it)
And I update the Tails devel branch to reference this merge commit
And I push the Tails devel branch
Then a new upstream release of t-p-s is automatically built
And a new .deb is automatically built and added to the devel APT suite
If we go this way, ideally we would stop preparing releases and
packages of t-p-s (and friends) manually, and (more important in the
context of the current discussion), we would stop having to take care
of the Git <--> APT relationship ourselves.
Well, these are rough ideas, and I'm sure I'm missing things here and
there, but hopefully this is good enough food for thought :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
