www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: Git pragmatics
Date Fri, 06 Nov 2015 03:01:06 GMT
Hi
Configure the release plugin with
-DlocalCheckout=false
-DpushChanges=false

So the tag neither the changes will be push to upstream repo (i.e ASF one).

Then push that to your git repo (i.e your fork on github) once the vote has
passed push it to the mainstream (ASF) and that's it.



On 6 November 2015 at 13:48, Julian Hyde <jhyde@apache.org> wrote:

> I’m posting to this list because this seems to be the forum to discuss
> recent interim changes in git policy. I did not post to the "Git, history,
> protection, and other topics” thread because it seems to be about technical
> implementation of the policy.
>
> I wanted to share how the interim policy affects the Calcite project and
> the Drill project. Hopefully we can find some short-term mitigation, and we
> can shape long term policy to accommodate our use case.
>
> Specifically, we use “scratch” branches for the many release candidates
> and screw ups that occur while making a release (typos in the release
> notes, small changes to the web site, fat-fingered URLs, mis-typed version
> numbers, forgotten entries in the KEYS file, etc.). We don’t want to commit
> that mess to the permanent record.
>
> To be clear, our final release candidate is based off of a commit that
> enters the permanent record. Its sha is present in the release and the very
> same sha becomes part of the master branch.
>
> This might be a particular problem for those of us who use
> maven-release-plugin. It commits, pushes and clones as part of its ordinary
> operation. If you are producing a release candidate using
> maven-release-plugin, you HAVE to commit and push. We’d just rather that
> that commit does not become permanent if the release candidate.
>
> My proposal is that any branches whose names starts “temp-“ would be
> exempt from the new rules.
>
> A committer would be extremely unlikely to choose such a branch name
> accidentally; thus if they created such a branch and did a force push or
> deleted it they would be intentionally changing the way history looks, and
> since we trust committers, I believe we should allow such behavior.
>
> Julian
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message