hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [DISCUSS] Migrate from svn to git for source control?
Date Fri, 08 Aug 2014 21:03:13 GMT
In the bylaws, I see this under PMC responsibilities:

* Maintaining the project's shared resources, including the codebase
repository, mailing lists, websites.

This seems to indicate that the repo (i.e. svn or git) is managed by the
PMC. Of the available PMC vote actions, the closest seems to be "Adoption
of New Codebase":

When the codebase for an existing, released product is to be replaced with
an alternative codebase. If such a vote fails to gain approval, the
existing code base will continue.
This also covers the creation of new sub-projects within the project
Lazy 2/3 majority of PMC members

This would be my recommendation for the vote, but I'll defer to more
experienced PMC members.

Thanks,
Andrew


On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur <tucu@cloudera.com>
wrote:

> funny, i'd treat it as a merge vote.
>
>
> On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
>
> > Thanks Steve. Including that in the proposal.
> >
> > By the way, from our project bylaws (
> http://hadoop.apache.org/bylaws.html
> > ),
> > I can't tell what kind of a vote this would be.
> >
> >
> > On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran <stevel@hortonworks.com>
> > wrote:
> >
> > > On 6 August 2014 22:16, Karthik Kambatla <kasha@cloudera.com> wrote:
> > >
> > > > 3. Force-push on feature-branches is allowed. Before pulling in a
> > > feature,
> > > > the feature-branch should be rebased on latest trunk and the changes
> > > > applied to trunk through "git rebase --onto" or "git cherry-pick
> > > > <commit-range>".
> > > >
> > >
> > > I'd add to this process the requirement to tag any feature branch
> before
> > a
> > > rebase, with some standard naming like
> > >
> > > tag_feature_JIRA-2454_2014-08-07_rebase
> > >
> > > Why? it keeps the state of the branch before the rebase in case you
> ever
> > > want it back again. Without the tag: lost data. Once the feature is
> > merged
> > > in you can rm the tags, but until then they give you a log of what
> > changes
> > > went on, and make it possible to switch back to the pre-rebase version.
> > >
> > > Without those tags you do lose history of the development.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>
>
>
> --
> Alejandro
>

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