Sanjay Radia wrote:
----- Original Message -----
From: Steve Loughran <ste...@apache.org>
To: core-dev@hadoop.apache.org <core-dev@hadoop.apache.org>
Sent: Mon Feb 09 08:39:27 2009
Subject: Re: Hadoop 0.19.1
Konstantin Shvachko wrote:
Doug Cutting wrote:
Commits to a feature branch will send a message to the dev list, like
any other commit. And when folks commit to a feature branch, they
should reference the Jira issue id, as in any other commit, so that
folks browsing Jira can see the commits.
When someone starts a feature branch they should note it in the Jira
issue, so that folks know to browse the "Subversion Commits" tab to
see the patch history. I'd expect this to proceed as follows:
1. A comment proposing that a feature branch be added.
2. A comment by a different committer, endorsing the feature branch,
and no comments objecting.
3. A comment stating that the feature branch has been added, what
it's url is, and that folks should henceforth use the "Subversion
Commits" or "All" tab to track the issue.
4. Committers can commit directly to the feature branch, without
reviews. Since committers must have a CLA on file, Apache license is
assumed.
5. Non-committers can submit patches against the feature branch to
the issue in Jira. These would require the license signoff as usual.
+1. I agree: no review requirement for feature branches, and 1-5.
I would add to this (6) merging a feature branch to an official branch
goes through regular patch process, that is, a new jira is created with
the patch attachment, which now goes through the review process.
I'm not sure about the merge, but it is possible. What is important is
that the branches get reviewed regularly before the big commit day. For
those active branches, that means that we may want some oversight/review
process, and an action plan to deal with unmaintained branches (turn to
jira patch, remove the branch?)
+1
Everything would still be in public, on the dev list, as now.
Note that we do *not* want feature branches in external repositories,
since commits there would not generate commit messages to the dev list
nor would they generate links in Jira, etc.
I'm guessing Doug means Git repos and the like.
Now. apache is starting to set up some Git/SVN sync via github, for
efficient branching . That's the alternate place for me to go with my
code, though I quite like SVN myself.
Also, I am not above using HADOOP- issue tags in the commits to our
sourceforge hosted repository...Jira does have the ability to scan other
repositories if needed.
I don't know about Github; IDEA 8.1 is adding git support though. That's
the other place I would put stuff, as it would let me share it while the
lawyers tick things off their lists.
One thing about Git is that it has a more laid back notion of what is
"trunk"; you'd end up with more a blurred distro, with -maybe- the Y!
production scheme, the Cloudera branch, the steves-modified-branch, etc,
etc -with people able to pick and choose which to merge in. There's less
of a trunk+branches, more just a set of branches.
I dont know how well things like major refactorings with directories
being moved about goes down in this world, something I'd be reluctant to
play with.
