Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - Hadoop 0.19.1


Copy link to this message
-
Re: Hadoop 0.19.1
Sanjay Radia 2009-02-14, 23:52
                         

----- Original Message -----
From: Steve Loughran <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
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?)
>
>> 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.