Just received an email today from Infra that force pushes are allowed again. Relevant excerpt below:
-------------- First, If a forced commit is pushed, the subsequent commit email will contain '[Forced Update!]' in the subject line. The hope here is that it draws extra attention to the situation for a project community to be aware, and take appropriate action if needed. Second, we've changed the 'protected' portions of git to primarily focus on refs/tags/rel - thus any tags under rel, will have their entire commit history. This provides the provenance that the ASF needs for releases, while still giving projects the ability to mold their repository in the way they see fit. -------------- On Thu, Jan 7, 2016 at 5:39 PM, Sangjin Lee <sjl...@gmail.com> wrote: > There was this on the infra email back in December: > > On 1 December 2015 at 13:55, David Nalley <da...@gnsa.us> wrote: > > > > As part of the steps to removing the git lockdown, the board has > > tasked the President (and by extension Infrastructure) with defining: > > > > some ASF-wide convention for identifying which Git references are to > > be treated as immutable within ASF controlled public copy of Git > > repositories. At a minimum, this must include a reference for each > > release. > > > > For historical perspective, we protected the trunk and master > > branches, as well as any branches under /refs/heads/rel, and tags > > under /refs/tags/rel/ > > > > The thought being that master or trunk were the locations of > > development that was going to end up in releases, and that releases > > would be tagged something like tags/rel/4.6.0. > > > > In general practice, a large number of folks were not operating in > > that manner. So, that brings us to today. At a minimum, the board is > > expecting that we identify a way to keep release references immutable. > > > > > > Thoughts, comments, flames? > > > > --David > > > I don't know that there has been concrete action taken by the > infrastructure. > > Regards, > Sangjin > > On Thu, Jan 7, 2016 at 3:50 PM, Karthik Kambatla <ka...@cloudera.com> > wrote: > > > Sangjin, Steve and others: > > > > just curious if you guys figured out a way to address/workaround this > > hurdle - not being able to delete or force push. Should we reach out to > > INFRA again? > > > > On Thu, Nov 12, 2015 at 10:21 AM, Allen Wittenauer <a...@altiscale.com> > > wrote: > > > > > > > > > > > > > > > > > > On Nov 12, 2015, at 10:14 AM, Sangjin Lee <sjl...@gmail.com> wrote: > > > > > > > > I don't think we're proposing project-specific rules. It would be a > > > > recognition of the git branch name prefix "feature/". > > > > > > > > If the file name had "HADOOP-67890-HADOOP-12345.001.patch" where > > > > HADOOP-12345 was the feature JIRA but the git branch was > > > > "feature/HADOOP-12345", if yetus didn't find a branch named > > > "HADOOP-12345", > > > > can it also look for "feature/HADOOP-12345" before failing the build? > > > > HADOOP-12345 can be any branch JIRA. > > > > > > > > > In a “everyone in the world including outside the ASF wants > this > > > magic branch matching happening” way, no, Yetus shouldn't do that. If > > > Yetus added a flag to the JIRA plugin where this patch file naming > stuff > > > happens or make it a personality setting, then potentially yes. Yetus > > > isn’t just Hadoop and it’s important to remember that when requesting > > > additions. > > >
