hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yongjun Zhang <yzh...@cloudera.com>
Subject Re: [UPDATE] New ASF git policy on force-pushes / Tags / Stale branches
Date Fri, 15 Jan 2016 04:07:49 GMT
Thanks Vinod and Akira..

I assume we will have at least a committer review of any force-push. Say,
if the commit history already has x, y, z, now we need to force push with
x', we'd better not torget y and z, and if there is conflict putting in y
and z after x', the conflict is better reviewed.

Maybe we should have some guideline documented at a wiki page.

Hope that makes sense.



On Thu, Jan 14, 2016 at 6:28 PM, Akira AJISAKA <ajisakaa@oss.nttdata.co.jp>

> Thanks Vinod for the information.
> +1 for removing origin/bracnh-2.8 and origin/sjlee/hdfs-merge.
> In addition, I'm thinking we need to delete origin/master,
> which was pushed wrongly. I've already deleted
> origin/ajisakaa/common-merge before force-push protection starts.
> > — There is a general recommendation from INFRA team to take all of our
> existing release tags under "tags" and copy them to “rel”.
> +1 for following the recommendation.
> Regards,
> Akira
> On 1/15/16 06:26, Vinod Kumar Vavilapalli wrote:
>> Hi all,
>> As some of you have noticed, we have an update from ASF infra on git
>> branching policy: We no longer have a ASF wide mandate on disallowing
>> force-pushes on all branches / tags.
>> Summarizing information from the INFRA email for the sake of clarity in
>> the midst of recent confusion
>>   - We now can do force pushes, and branch/tag deletion on any branch or
>> tag except refs/tags/rel
>>   - Any force pushes will be annotated in the commit-email as “[Forced
>> Update!]” for the community to watch out for undesired force-pushes
>>   - Only tags under refs/tags/rel are protected from force-push for the
>> sake of release-provenance: Essentially, the releases that community votes
>> on are archived in their entirety with the development history and we
>> cannot alter that once a tag is created. As one might expect.
>> What this means for us
>>   - Stale branches: There are a few stale branches that got accumulated.
>>      — During this branch moratorium, origin/bracnh-2.8 got created (May
>> be as part of HDFS-8785, can’t say for sure)
>>      — A couple of stale branches that helped 2.6.1 release:
>> origin/sjlee/hdfs-merge and origin/ajisakaa/common-merge
>>      — I’ll wait till EOD tomorrow for any yays/nays and delete them
>>   - Feature branch updates: Developers can now go rebase and force-push
>> their feature branches.
>>   - Mainline branches: Mainline branches like trunk, branch-2 have always
>> been configured to avoid force-pushes. In general, force-push continues to
>> be recommended mainly for feature branches and definitely not on any
>> mainline branches from which we make releases.
>>   - Release tags:
>>      — To follow ASF provenance policy, we will now push the final
>> release tags under refs/tags/rel. We will first push the RC tags under
>> where they reside now (refs/tags) and if the vote passes, the final tag
>> will be created under refs/tags/rel.
>>      — I’ll update our release wiki page
>> http://wiki.apache.org/hadoop/HowToRelease <
>> http://wiki.apache.org/hadoop/HowToRelease> with the same details once I
>> can get 2.7.2 release done using this updated process.
>>   - Existing release tags:
>>      — There is a general recommendation from INFRA team to take all of
>> our existing release tags under "tags" and copy them to “rel”.
>>      — I’ll wait till EOD tomorrow for any yays/nays and copy existing
>> releases under refs/tags/rel following general recommendations.
>> Any comments / thoughts / questions welcome.
>> Thanks
>> +Vinod

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