Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
In-Reply-To: 
 <OFC7C2DC6F.52BA580F-ON86256F69.0050117D-86256F69.00530F18@lawson.com>
To: "Gump code and data" <general@gump.apache.org>
Subject: Re: [RT] Gump 3.0 - Database Model
MIME-Version: 1.0
Message-ID: 
 <OF7D8CE751.B996E698-ON86256F69.0055A792-86256F69.00568EB5@lawson.com>
From: Wade.Stebbings@Lawson.com
Date: Mon, 13 Dec 2004 09:45:45 -0600
Content-Type: multipart/alternative;
 boundary="=_alternative 00568EB486256F69_="

--=_alternative 00568EB486256F69_=
Content-Type: text/plain; charset="US-ASCII"

Stefano,

Some afterthoughts.  Hopefully to help clarify.  The scope of a "Project"
in our system (currently) is that of a build (a series of builds) for a 
given
instance of (1) product-release on a given (2) target.  This of course
means that a single configuration for a given instance of #1 would then
"fan out" to several "Projects" (as we have used this word).

I am not completely happy with this arrangement, since our "Project"
does not distinguish between:

 (a) separate configurations, or
 (b) the same configurations build on different targets.

And somehow I think this distinction should be more clearly represented
in the data model.

I think if (1) were to be defined as the "Project" and the (2)'s under it
would be "SubProject" (to use some names), and keep the arbitrary
grouping mechanism, though now at the SubProject level, then I think
we've gained something w/o any other feature loss.

wade


Wade.Stebbings@Lawson.com wrote on 12/13/2004 09:07:32 AM:

> Stefano:
> 
> See my responses below.
> 
> 
> [...]
--=_alternative 00568EB486256F69_=--