On 26-05-2005 17:58, Adam R. B. Jack [EMAIL PROTECTED] wrote:
Could we get back to this thread above (using http://tinyurl.com/4qt9a to
get to the attachment) and see where we want to take it?
Yes we can!
It probably still needs a lot of work.
One thing that's wrong with it at the moment is
Sent: Wednesday, December 08, 2004 6:32 PM
Subject: [RT] Gump 3.0 - Database Model
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the first step is to identify the entities that we want to
model, their relationships and their respective
Stefano:
see my responses below.
wade
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 12/15/2004 09:40:28 PM:
[...]
What I was thinking is that this (and other of your suggestions) adds a
meta-metadata layer and I'm not sure if I want to add this complexity
at this point (given that
Leo:
Leo Simons [EMAIL PROTECTED] wrote on 12/16/2004 02:46:14 AM:
[...]
yep, I seem to agree. Let's first implement the proposed setup and
optimize for understandability and cleanliness. Gump has a lot of
features already. Let's first focus on making the important ones easier
to use,
Stefano Mazzocchi wrote:
[EMAIL PROTECTED] wrote:
Yes, it is a many-to-many relation between the Project and Group tables.
Thus, I can define one group which is all mainline builds (we have
several release streams managed by separate branches), regardless of
platforms build on. Another group
[EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] wrote:
Stefano:
See my responses below.
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 12/10/2004 02:21:48 PM:
[EMAIL PROTECTED] wrote:
[...]
In my Build Results system, I have a schema that also includes a few
additional things:
- abritrary groupings of projects, which helps in
On Monday 13 December 2004 09:09, Stefano Mazzocchi wrote:
Eric, I really don't care what ID we choose, as long as it does identify
something univocally also in a global and distributed environment.
RDF ?
Isn't RDF a perfect fit for this kind of problems ?
Niclas
--
Stefano:
See my responses below.
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 12/10/2004 02:21:48 PM:
[EMAIL PROTECTED] wrote:
[...]
In my Build Results system, I have a schema that also includes a few
additional things:
- abritrary groupings of projects, which helps in organizaing
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
Just catching up on my email after being gone for a week. One thing that
strikes me about the project id's is that this seems to continue the same
discussion we have had in the past about maven generated project id's versus
the gump project id's...
Do the project id's have to have meaning?
Eric Pugh wrote:
Just catching up on my email after being gone for a week. One thing that
strikes me about the project id's is that this seems to continue the same
discussion we have had in the past about maven generated project id's versus
the gump project id's...
Do the project id's have to
On Wed, 08 Dec 2004, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Mon, 06 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, here is my first suggestion: split gump in three stages.
1) metadata aggregation
2) build
3) build data use
Sounds good.
One additional thing.
I'd
2a) SCM update
2b) syncing updated working copy with workspace
2c) building
We do actually have 2a and 2c already, in bin/build.py and bin/update.py,
they just never got the usage/fixing they might need.
regards
Adam
-
To
[EMAIL PROTECTED] wrote:
This is cool. FWIW, here's some bits from my experience, implemeting
something similar in a MySQL database.
Awesome!
In my Build Results system, I have a schema that also includes a few
additional things:
- abritrary groupings of projects, which helps in organizaing
Ok, here is my thinking on how we proceed towards Gump 3.0, i.e.:
1) Metadata Gathering
2) Processing (Build/Sync/Update)
3) Results/Presentation/History Query/Analysis
Fnor *now* ...
1) Phase One (Metadata
Adam R. B. Jack wrote:
Ok, here is my thinking on how we proceed towards Gump 3.0, i.e.:
1) Metadata Gathering
2) Processing (Build/Sync/Update)
3) Results/Presentation/History Query/Analysis
Fnor *now* ...
1)
On Fri, 10 Dec 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote:
[FWIIW: Personally, I'd love to get back to NAnt building except
that Mono is still my roadblock.
I still don't quite understand why it works far better on my oldish
RedHat box either. Hmm, have we tried Mono 1.0.4 or even 1.0.5
Since I received no pushback on my proposal, let's move on discussing
the database model.
I see this model is good enough for certain aspects of the proposed 3.0, but
not for all. We can't store the metadata in it, in order to perform builds
from, there is clearly insufficient information.
This is cool. FWIW, here's some bits from my experience, implemeting
something similar in a MySQL database.
In my Build Results system, I have a schema that also includes a few
additional things:
- abritrary groupings of projects, which helps in organizaing various
forms of the
On Mon, 06 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, here is my first suggestion: split gump in three stages.
1) metadata aggregation
2) build
3) build data use
Sounds good.
We should be maintaing the metadata representation only for the
projects that don't have
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the first step is to identify the entities that we want to
model, their relationships and their respective cardinality.
Here is what Leo and I came up with so far (attached as PDF).
Stefano Mazzocchi wrote:
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the first step is to identify the entities that we want to
model, their relationships and their respective cardinality.
Here is what Leo and I came up with so far
must be stripping attachemnts - maybe it can be put on the wiki or something?
On Wed, 08 Dec 2004 19:35:18 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the
Stefano Mazzocchi wrote:
Stefano Mazzocchi wrote:
Since I received no pushback on my proposal, let's move on discussing
the database model.
I think the first step is to identify the entities that we want to
model, their relationships and their respective cardinality.
Here is what Leo and I
I've been working for a while to describe an improved architecture for
Gump and I have decided to go public with the discussion because I
want this to be a community effort.
- o -
First and foremost, I believe that gump is one of the most exiting
things happening
Stefano Mazzocchi wrote:
Comments?
Not really. Most of it sounds obvious by now, actually :-D
More images related to this architecture are at:
http://svn.apache.org/repos/asf/gump/trunk/src/xdocs/gump.pdf
though I'm afraid some of the comments in the gump.ppt alongside there
didn't make
27 matches
Mail list logo
