wiki/src/blueprint/delete_obsolete_Git_branches.mdwn

   1 Corresponding ticket: [[!tails_ticket 8616]], that's a blocker for [[!tails_ticket 8617]].
   2
   3 [[!toc levels=2]]
   4
   5 Initial design
   6 ==============
   7
   8 ## When do we delete merged Git branches?
   9
  10 After a new Tails release has been shipped, we should review which Git branches has been merged in the release and remove them accordingly. This will make sure that we keep a clean-ish Git repository for a new release cycle.
  11
  12 ## Deleting obsolete Git branches
  13
  14 There is a distinction between merged Git brances and obsolete ones. Obsolete ones may be branches that haven't been merged, they could've been around for longer then 6 months or even a year, the work might never be done but we will consider it a WIP branch and will thus not be deleted.
  15
  16 After a Git branch has been merged and we discover that it introduces a regression, the cleanest way would be to work on a resolution in a *new* Git branch, and not reuse the old Git branch.
  17
  18 ## Who does delete these Git branches?
  19
  20 Ideally, the one who deletes them has access to push to the official Git repository. If we would chose for having the release manager do this, it can be done post-release and it wouldn't require people from the sysadmin team to step in and issue a command.
  21
  22 ## What kind of privileges are required to do that?
  23
  24 Push access to the official main Git repository.
  25
  26 So far, only humans have write access there and we would like to not replace them with robots yet. That is for the future (e.g. the system that hosts our APT repository already has privileges akin to Git commit rights).