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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
