Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MailScanner-NULL-Check: 1316767403.9771@30/o3cHT0EFjP7+F/e48jw
Message-ID: <4E730C25.4090902@apache.org>
Date: Fri, 16 Sep 2011 09:43:17 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: common-dev@hadoop.apache.org
Subject: Re: [PROPOSAL] Two Jira infrastructure additions to support
 sustaining
 bug fixes
References: 
 <CA+z3+9E=aPm7bV-wSu0JzesMcZaJaFDneMmchyCjY6z5nRC+SQ@mail.gmail.com>
In-Reply-To: 
 <CA+z3+9E=aPm7bV-wSu0JzesMcZaJaFDneMmchyCjY6z5nRC+SQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15/09/2011 19:58, Matt Foley wrote:
> Hi all,
> for better or worse, the Hadoop community works in multiple branches.  We
> have to do sustaining work on 0.20, even while we hope that 0.23 will
> finally replace it.  Even after that happens, we will then need to do
> sustaining releases on 0.23 while future development goes into 0.24 or 0.25,
> and so on.

seen this.

Another way to do it could be to create sub-issues, one for each branch, 
so you have a super-issue for all branches, and a sub-issue for the 
individual branches. Then we'd need a tag for "test-branch" which could 
be used by jenkins to know which branch to patch-test against. ]]

The advantage of this approach is that the sub-task mechanism is built 
into JIRA, lets you see at a glance from the super-task which branches 
are still open, and lets you have a sub-lifecycle (progress, wontfix, 
logged hours) for each branch, and you could easily separate the jenkins 
outputs.

The risk is that discussions would take place in the sub-tasks, not the 
supertask, but that is a team process issue