Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (athena.apache.org: domain of oching@exist.com designates
 209.85.198.245 as permitted sender)
Message-ID: <1a57a2980808122352ha19cb3do43f64bbdd774be51@mail.gmail.com>
Date: Wed, 13 Aug 2008 14:52:40 +0800
From: "Maria Odea Ching" <oching@apache.org>
Sender: oching@exist.com
To: dev@continuum.apache.org
Subject: Re: refactoring the SCM
In-Reply-To: <f345f3480808071332x6df22675uda9357552a23b530@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_91952_28513255.1218610360325"
References: <3AD39409-CACE-4134-A481-5775E8B0DA30@apache.org>
	 <77A7A49D-F584-4BCE-BEDC-EBA62E4ACA01@apache.org>
	 <10c62ca80807291906n6128df07jd29d4b9cbe952175@mail.gmail.com>
	 <C911AFD7-DF40-4A54-B7D4-A6861A3F8B76@apache.org>
	 <10c62ca80807301621u23da32ddvd80fb7a0cd64f832@mail.gmail.com>
	 <B7C8FBE6-DFF2-4757-A51D-71C390270006@apache.org>
	 <10c62ca80807302254t4fe8f02yd39f53aaed31abd2@mail.gmail.com>
	 <0F09A290-BE01-48EB-A5CF-BC161F454BD6@apache.org>
	 <10c62ca80807310046vb03a08j336eaa2da807ec72@mail.gmail.com>
	 <f345f3480808071332x6df22675uda9357552a23b530@mail.gmail.com>

------=_Part_91952_28513255.1218610360325
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

(Sorry, I just caught up now with discussions here in the list..)

+1 on the proposal..

On Fri, Aug 8, 2008 at 4:32 AM, Emmanuel Venisse <emmanuel.venisse@gmail.com
> wrote:

> +1 but few comments
>
> On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ctan@exist.com> wrote:
>
> > Ok here's my new proposal :)
> >
> > SCM Errors
> > 1. Separation of configuration/pre-build from actual build
> > 2. Create new state for svn failure but will use ( x ) for the icon
>
>
> In my vision, the icon for svn failures shouldn't be on the project, maybe
> on the group.
> With a scm failure, Continuum can't start the build so the project state
> don't change
>
> >
> > 3. Still send a notification if there's an svn failure. ( I would still
> > like
> > to be notified if something like this happens )
>
>
> Yes, but without a project context (project name, build definition), It
> should be a general message and sent only one time for all projects. I
> don't
> want to be spammed by the same mail for all modules.


+1 to Emmanuel's suggestion


> >
> > 4. Have a checkout/update error field on the project.
>
>
> I don't think it is the best place. A new table with the list of all scm
> root address with a state on each would be probably better.
>
>
> >
> > 5. Can release project even if it has a state of svn failure
>
>
> With a scm failure, the release process can't run, you must check if the
> scm
> is back or not.
>
> >
> > 6. Do not create a build result for transient errors
> >
> > Cancelling a build
> > 7. Cancelled build will trigger a skip but will still have it's previous
> > state.
>
>
> what do you mean?


I think this is for a project currently being built? If the build's
cancelled, the previous state (e.g. before the cancelled build) would be
retained?


>
>
> Emmanuel


Thanks,
Deng

------=_Part_91952_28513255.1218610360325--