www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@apache.org>
Subject Re: Git pragmatics
Date Fri, 06 Nov 2015 05:09:26 GMT
Yeah, that's what we're doing. Just thought it was less than ideal that the
release candidate git isn't on Apache infrastructure until it passes
On Nov 5, 2015 7:01 PM, "Olivier Lamy" <olamy@apache.org> wrote:

> 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

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