Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Subject: Re: git and deleting branches
To: infrastructure-dev@apache.org
References: <5641DE35.3050001@gmx.org>
 <CAAS6=7inZxvCSBYc=aePv9WTTdaH_nVk8Ka9QUD-_4UkGn-5fA@mail.gmail.com>
 <CEACAE58-4EB5-482A-A51E-0C2130166A2E@yahoo.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <5642DBB6.4050203@gmx.org>
Date: Wed, 11 Nov 2015 07:09:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CEACAE58-4EB5-482A-A51E-0C2130166A2E@yahoo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 11.11.2015 03:28, Joseph Schaefer wrote:
> Oh calm down Marvin.  None of this is being hotly debated at this point, particularly none of jochens concerns are.
>
> What is happening internally is a measured and mostly rational conversation about generic policy matters, some of which tangentially touch on this issue.

This is probably more directed at Marvin... I can perfectly well 
understand that we don't want to loose history to any release. But for 
example in he GROOVY_1_5_X branch... There is a GROOVY_1_5_8 tag 
describing the last release made from this branch. After that, there are 
3 small commits from 2010, to correct version number scheme changes, and 
there will never be any release from this branch. Deleting this branch 
would not mean loosing anything but those 3 commits, since the tag 
stays. After all, in git a branches and tags are just references to 
points in a DAG commits.

> But jochen's concern certainly hasn't been kicked around in any detail yet so sure why not discuss it here since projects are experiencing the ramifications as we speak.
>
> The problem is that when we created the git infra at apache, we intended for projects to use the master branch and a select set of other references to be considered protected from history modification.   Originally I believe the thinking was to protect the entire repo but that was considered too invasive by people smarter than me.

As of 
https://git-wip-us.apache.org/docs/switching-to-git.html#protected-ref-lists 
the protected references are

refs/heads/trunk
refs/heads/master
refs/heads/rel/
refs/tags/rel/

Since we come from a existing repository (that was formerly SVN, that 
was formerly CVS) we never used the /rel/ structure to begin with. At 
the same time we would not want anyone to delete GROOVY_2_3_X right now, 
since that is the current maintenance version. We usually have up to 3 
branches in work in parallel of which releases are done. Problem here: 
the names change, since they are version oriented. For major versions 
there might also be branches for beta and rc versions, which might exist 
in parallel. Of course I realize now, that the branch should have been 
under rel as well, but even our change to git was done long before we 
came to apache

> So while what we came up with was essentially limitations on a few select reference namespaces, it turned out that many projects were either explicitly avoiding those references, or their tooling led them to make alternate choices when it came to the use of the master branch for development.  In effect our policies were being circumvented so someone made a call to deal with the situation and that leads us to where we are today.  In no way should this be viewed as a permanent change, but one that level sets the problem across the board.

The release process is often a reason, pre apache structures another. 
The 72h voting period is also not helping here. In the end it means a 
lot of work for infra, if all branches and tags stay protected. A 
non-protected namespace would help, but not sure if the tooling can do 
that properly (after all, most of those tools would not need to have a 
branch in the remote repo at all)

bye Jochen