Information
ID: 351
PHID: PHID-TASK-72tzuxctj7bjb4hcz6je
Author: Patrick
Status at Migration Time: wontfix
Priority at Migration Time: Normal
Description
I was wrong about a few things on how it’s actually handled in QubesOS. - See T351#5797
current situation:
qubes-whonix package:
- currently Whonix11 branch contains latest commits
- master contains status of latest Whonix stable (Whonix 10 at time of writing)
all Whonix packages, such as whonix-gw-firewall etc.
- master contains status of latest developments
- Whonix10 maintenance branch
- Whonix11 maintenance branch (since soon to be released)
most (all?) Qubes packages such as qubes-builder-debian, qubes-core-agent-linux:
- master contains status of latest developments, looks like
- branches for maintenance (and history perhaps) such as release2, looks like
proposal:
To sync things… Adapt the same style to qubes-whonix package. I.e. let master reflect latest commits.
Advantages:
- No need to explain to future contributors “don’t base on master, that’s just maintenance, base on Whonix11 branch, is latest”, followed by replacing that with Whonix12 in future.
- Most common way to handle use of master branch?
- Activity on github looks better. Github defaults to master. People see latest commit was not so long ago and perhaps look into those. Better than being swamped when it’s merged into master at release time.
- One step less (choosing Whonix11 branch) when creating github pull requests.
- Most pull requests are based on latest (ideally: master) rather than specific versions.
Comments
Patrick
2015-06-30 14:07:06 UTC
nrgaway
2015-07-01 00:37:16 UTC
Patrick
2015-07-10 15:01:08 UTC