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 various forms of the presentation of the data
Can you elaborate more on this?
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 would be all Windows/2003 builds. It
is merely a way of seeing a limited set of project names, though when
presented on the web page, I do also display some project attributes for
each project displayed, like the lable & link of the current build as well as the "last good" build.
Ok, I see.
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 the model is complex enough already).
I agree that this meta-metadata layer will be very useful (for annotation, grouping and further user interaction around the collected data) but this is something we can add incrementally later on.
- the general notion of "attributes" associated with each: - build (instance) - project - group - the whole system
"attributes" as in "annotations" or as in "related data"?
I'm not sure what is the difference between annotations (like added noted, do you mean?) and "related data". But what these tables do is, basically to allow one to add new fields to the associated table without a schema change. They are name/value pairs, with the added key (foreign key) of the id of the table to which they relate. Thus, for the Project table:
Project Attributes: - proj_id (foreign key) - name (string, key) - value (blob)
Project: - proj_id (key) - ... etc ...
In the case of the system wide attributes table, there is no "id" field. That table I use for stuff like debug on/off/level, motd, and so far little else.
Ok, this is again another meta-metadata layer but this is something that I'm not sure I like. It smells of overdesign and at this point I want to keep features that are just critical for having the system working. "the simplest thing that can possibly work".
And since my system is focused on creating interaction between people
about given built baselines, I have the notion of a notes history associated
with any given build, in a similar spirit as the comment history of a given
"bug" in bugzilla.
I like the concept of allowing bugzilla-style communication to happen without requiring people to subscribe to various mail lists, like a common ground for communication to happen.
But I don't want this to be too global, because I want gump-related discussions to happen on the mail list.
You could tie-in email notification when this table is updated. We don't do that, but it's not a bad idea. Bugzilla of course does this.
Good suggestion. Again, this applies to the meta-metadata layer but it strikes me as a very useful feature to have right away. What do others think?
Like the notes table, I have separate tables for (references to) artifacts,
yes, the artifact table is missing, that's a good point.
I use the notion of an external Artifact Repository and refer into that with this table. The artifacts themselves are not stored in the database nor on the database server. Just wanted to be clear about that.
The notion of an Artifact Repository: ah, well, I have my idea of what I want, and then there's the reality that we don't have much more (at present) than a web-based storage mechanism, organized hierarchically within the file system. Thus "version information" is exposed in the file-path name space, and 3rd party artifacts are managed in yet another system. My notion of an Artifact Repository would be a place to store any 3rd party artifact that any build could depend on. Build themselves would be producers, but could also be consumers. One of the main points of this is: that I separate, architecturally, the Artifact Repository, as a separate service, from the build system itself.
Keep in mind that we DO NOT WANT gump to build anything that anybody would start use for their own stuff. It is critical, socially and politically and for the security ecosystem that gump's artifact repository is not used for anything else rather than distributed gumping and fallback scenarios.
Consider it a cache, a repository of "precomputed calculations" rather than anything else.
This is true for executables: for javadocs and docs, this is a different story but we should not attack too many problems at the same time.
and another for results, to support any arbitrary number of artifacts/results
to a given build-instance.
Good point.
[...]
So, things missing are:
1) bugzilla like comments (on build results only? or what else?) 2) artifact table / artifact type table
Anything else you guys see missing?
Note: The results per build table (to support an arbirary number of results per build) was a separate table from the artifact table.
In fact, at present in my schema, for a single build table entry, there can be:
- any number of notes - any number of artifacts - any number of results
This is interesting. How can you have different numbers of results if you have only one output signal for a given build?
[snip color coding]
Thanks for including me in the discussion. I look forward to more.
me too! :-)
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
