Peter Donald wrote:
On Wed, 6 Nov 2002 11:58, Daniel Rall wrote:
Nicola Ken Barozzi <[EMAIL PROTECTED]> writes:
Peter Donald wrote:
Secondly make it so each project can have multiple vcs entrys (ie Avalon and it's 6 or 7, turbine with the same).
Hmmm... this descriptor should have a 1-1 relationship with a single VCS entry, as it defines what in CVS is a "module", as in the Gump descriptor.
Then it's not really a project descriptor, now is it? We already have plenty of projects at the ASF which have multiple CVS repositories -- look at httpd. Even the new infrastructure project will have several (so it's a growing trend).
We also have projects that propose one VCS ([EMAIL PROTECTED]) where codebases have subdirectorys (like serf/, httpunit/ etc). Other projects share mailing list for multiple codebases. Which sort to starts to get back to that icky state of flux that the alexandria (then gump) descriptors went through.
The truth is that I think you are rught, we will never come to a solid relationship with these entities, and history is here to warn us.
What happens when a particular "resource" is used across multiple codebases? Possible resources being;
* mailing lists * VCS * issue trackers * developers * schedulers/task trackers
If it was a normalized database model it would be simple because there would just be relationships between the entities. But because XML is a hierarchial data store then it no work.
As you know, Gump resolves this by defining common entities separately and "linking" them, like CVS repository info, that can be defined in one place and "linked" in all project descriptors.
Maybe it would be a good idea to start from a fully normalized database model and then work towards exporters that denormalize for particular purposes. The information could then be shared between different users and they could formulate it as they desire.
Conceptually it's basically the same as with what Gump does, but I'm interested in pursuing alternative paths if they are better.
What do you see in the Gump-like information-sharing system that needs to be redone or that cannot be done?
Does this sound like a good idea?
Sure clears up the picture :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------