hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Updates on migration to git
Date Tue, 26 Aug 2014 08:36:16 GMT
On 25 August 2014 23:45, Karthik Kambatla <kasha@cloudera.com> wrote:

> Thanks for bringing these points up, Zhijie.
> By the way, a revised How-to-commit wiki is at:
> https://wiki.apache.org/hadoop/HowToCommitWithGit . Please feel free to
> make changes and improve it.
looks good so far

I suspect we'll evolve it rapidly in use.

> On Mon, Aug 25, 2014 at 11:00 AM, Zhijie Shen <zshen@hortonworks.com>
> wrote:
> > Do we have any convention about "user.name" and "user.email"? For
> example,
> > we'd like to use @apache.org for the email.
> >
> May be, we can ask people to use project-specific configs here and use
> their real name and @apache.org address.
> Is there any downside to letting people use their global values for these
> configs?
I don't see any

> >
> > Moreover, do we want to use "--author="Author Name <email@address.com>"
> > when committing on behalf of a particular contributor?
> >
> Fetching the email-address is complicated here. Should we use the
> contributor's email from JIRA? What if that is not their @apache address?
I see aw's point, and as he notes, it just increases work.

But if we accept "git am" (squashed) patches, that comes for free. Maybe we
should recommend that as the format for future patches.

Some other post-migration thoughts

1. This would be a good time to clean up dead branches ... I promise to tag
then delete my old work

2. What's our policy of in-asf-git branch dev?

Single committer/few committers:

Say allen's 9902 work, which was a single committer's project, possibly
with many little commits? I think people should be allowed to work on
feature branches (naming policy? "minor/$JIRA(+text)" ?. At merge time we'd
squash these down to a single patch -this could be the one reviewed.

Large feature dev (par with today's feature branch/feature committer)

we could retain the current policy of JIRA per commit, or we could allow
feature-off-feature dev, where people can work on a JIRA in a branch, which
is then merged (squashed) back in to the main feature branch. This'd give
more visibility of dev work and still isolate the big feature from
individual work. At the end of the feature, it could be merged in directly,
without any squashing.

we could call these something like "feature/$JIRA(+text)"  to highlight
they are big works & differentiate from the minor projects.

we also need to plan for the promotion of minor -> feature, which could be
done with something like
 -1 create new feature branch off trunk
 -2 merge squashed minor branch into new feature

Finally, we've all be very lax about working on that pending patch list.
Much work, especially those very minor things, have been neglected. If this
git migrate eases committing, it's time to go through the backlist and
apply them.


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.

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