hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Hadoop 0.19.1
Date Mon, 16 Feb 2009 16:23:56 GMT
Sanjay Radia wrote:
>  
> 
> ----- Original Message -----
> From: Steve Loughran <stevel@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.




Mime
View raw message