On 25 August 2014 23:45, Karthik Kambatla <ka...@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 <zs...@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 <em...@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. -steve -- 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.
