Return-Path: Delivered-To: apmail-continuum-dev-archive@www.apache.org Received: (qmail 51880 invoked from network); 19 Dec 2008 06:27:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Dec 2008 06:27:52 -0000 Received: (qmail 31861 invoked by uid 500); 19 Dec 2008 06:28:04 -0000 Delivered-To: apmail-continuum-dev-archive@continuum.apache.org Received: (qmail 31826 invoked by uid 500); 19 Dec 2008 06:28:04 -0000 Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@continuum.apache.org Delivered-To: mailing list dev@continuum.apache.org Received: (qmail 31815 invoked by uid 99); 19 Dec 2008 06:28:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Dec 2008 22:28:04 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [207.188.87.164] (HELO smtp2.israfil.net) (207.188.87.164) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Dec 2008 06:27:42 +0000 Received: from [IPv6:::1] (mikail.israfil.net [127.0.0.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.israfil.net (Postfix) with ESMTP id CE906AD4427; Fri, 19 Dec 2008 01:33:53 -0500 (EST) Message-Id: <6A6B83E4-2122-4FE8-ABFD-644F5654792C@israfil.net> From: Christian Edward Gruber To: dev@continuum.apache.org In-Reply-To: <1a57a2980812182216k7aeb66baldeab449616609dd1@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Initial Efforts for Parallel Builds Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Dec 2008 01:27:18 -0500 References: <1a57a2980812181905r7e2d6d21kbfde5e20f0d5cd70@mail.gmail.com> <1a57a2980812182216k7aeb66baldeab449616609dd1@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org You should probably do both, in that if there's a non-web way to get at release (or if not, is eventually exposed) then the UI block won't stop the other mechanism. Can you make the release mechanism enabled or disabled based on appropriate criteria, which would include a given project currently building, and let the button drive off of that state? On 19-Dec-08, at 01:16 , Maria Odea Ching wrote: > On Fri, Dec 19, 2008 at 1:22 PM, Wendy Smoak wrote: > >> On Thu, Dec 18, 2008 at 8:05 PM, Maria Odea Ching >> wrote: >> >> A couple of things came to mind... (I haven't tried it yet) >> >>> 1. In the Configuration page, set Number of Allowed Builds in >>> Parallel to >> a >>> value greater than 1 and save the changes. >>> 2. Create a new Build Queue. You can create a few more if you want >>> but >> you >>> shouldn't be permitted to create more than the Number of Allowed >>> Builds >> in >>> Parallel you've set in the configuration. >> >> What should happen if you go back to Configuration and reduce the >> number of allowed builds in parallel below the number of queues? > > > I don't think we have this scenario covered in the implementation > yet. Good > catch Wendy :) > > >>> 2. handle instances when a project is still building and a release >>> is >>> triggered >> >> Just disable the Release buttons? >> > > Yeah, I was thinking of blocking the release & returning an error > message, > but having the Release buttons disabled is way simpler & easier. > > >> >> -- >> Wendy >> > > > Thanks, > Deng > > -- > Maria Odea Ching > Software Engineer | Exist Global | 687-4091 | Skype: > maria.odea.ching | > www.exist.com | Innovation Delivered