Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 48265 invoked from network); 17 Oct 2006 21:45:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Oct 2006 21:45:05 -0000 Received: (qmail 21346 invoked by uid 500); 17 Oct 2006 21:45:01 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 21324 invoked by uid 500); 17 Oct 2006 21:45:01 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 21294 invoked by uid 99); 17 Oct 2006 21:45:01 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Oct 2006 14:45:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [216.148.227.154] (HELO rwcrmhc14.comcast.net) (216.148.227.154) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Oct 2006 14:44:59 -0700 Received: from [192.168.168.15] (c-71-202-24-246.hsd1.ca.comcast.net[71.202.24.246]) by comcast.net (rwcrmhc14) with ESMTP id <20061017214438m14003o7dme>; Tue, 17 Oct 2006 21:44:38 +0000 Message-ID: <45354EC2.8090102@apache.org> Date: Tue, 17 Oct 2006 14:44:34 -0700 From: Doug Cutting User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: java-dev@lucene.apache.org Subject: Re: jira workflow References: <392521EA2692A2418DF48C331E61E32522B7@professorville.windows.esseff.org> In-Reply-To: <392521EA2692A2418DF48C331E61E32522B7@professorville.windows.esseff.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Steven Parkes wrote: > It wasn't really about having a list of needs clarification. It was more > about bounding open. I suppose it's my product development side showing. > Generally we tried not to leave issues open indefinitely, for fear of > not getting back to a customer. Perhaps there's nothing comparable in > the ASF model. Just because you've gotten back doesn't mean the issue is gone. It sounds like the list we might need is of new issues that have not yet been responded to. So perhaps adding a field indicating whether a bug is new, or has been responded to should be added. Then we could try to keep the queue of new, as-yet-unresponded-to bugs small. Would that help? > A reviewer is someone whose opinion influences a committer. > > Mostly thinking about Jira state issues. If Jira state can be affected > by more than committers (for example assigning to oneself, as a member > of lucene-developers), should reviewers still just provide comments on > other issues and leave it to a committer to bounce patches? Don't mean > to make too much of this; perhaps it's obvious what one should and > shouldn't do. Only trying to figure out how reviewers can contribute > without going too far. If someone is confident enough to reject a patch and they're not a committer, then they should still reject the patch. If someone else disagrees with that judgement, then they can re-submit it. > Well, if patch available is added, there's always the issue of moving > issues into that state but I suppose contributors, if they're still > around, will do that themselves. So is Hadoop's workflow acceptable to all? Doug --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org