hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sj...@apache.org>
Subject Re: [UPDATE] New ASF git policy on force-pushes / Tags / Stale branches
Date Fri, 15 Jan 2016 16:44:11 GMT
I deleted all the obsolete 2928 branches (except for YARN-2928 and
feature-YARN-2928) a few days ago. Do you still see them?

On Fri, Jan 15, 2016 at 5:54 AM, Junping Du <jdu@hortonworks.com> wrote:

> There are also several stale branches for YARN-2928 that we should
> consolidate:
>   remotes/origin/YARN-2928
>   remotes/origin/YARN-2928-new
>   remotes/origin/YARN-2928-old
>   remotes/origin/YARN-2928-old-2015-11-09
>   remotes/origin/YARN-2928-rebase
>   remotes/origin/feature-YARN-2928  (the latest one)
> I think we should remove all stale ones and rename the latest one
> feature-YARN-2928 to YARN-2928 to follow our practice for branch
> development. Thoughts?
>
>
> Thanks,
>
> Junping
> ________________________________________
> From: sjlee0@gmail.com <sjlee0@gmail.com> on behalf of Sangjin Lee <
> sjlee@apache.org>
> Sent: Friday, January 15, 2016 7:17 AM
> To: yarn-dev@hadoop.apache.org
> Cc: Hadoop Common; hdfs-dev@hadoop.apache.org;
> mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli
> Subject: Re: [UPDATE] New ASF git policy on force-pushes / Tags / Stale
> branches
>
> Thanks Vinod for the proposal. I deleted my branch (sjlee/hdfs-merge) the
> other day.
>
> Sangjin
>
> On Thu, Jan 14, 2016 at 1:26 PM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org
> > 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
>

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