[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 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.
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, then on making it easy to add the ones we want.
I can't really "see through" Wade's setup right now (I'd like to see more, it sounds very interesting :-D), but what I do have is a hunch is addresses quite a few use cases (like redistribution of stuff) which we really don't want to worry about right now.
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
