On Wednesday 09 June 2004 06:51, Farr, Aaron wrote:
> In SVN our {ttb} structure is such that the WHOLE Avalon source tree is
> under one revision.
This is IMHO definately desirable. I want to be able to build the entire thing
with a single command.
> If this philosophy where carried to JIRA, then we
> should have only one JIRA project for all of Avalon. And while SVN shows
> our whole source tree is one singular project, we have a versioning system
> under /runtime/versioning which clearly shows this isn't the case.
Sorry, you are missing something. Source Control Versioning has nothing to do
with release management (and its versioning). I and Stephen has discussed
versioning to end of days, and there are several posts here touching on the
subject, and my personal conclusion is that one should not assign semantics
to a versioned artifact (as in a property of its name), but instead allow for
semantics to be added on top, complete agnostic of artifact version number.
> IMHO the following needs to be reconciled:
> * JIRA projects
I got no strong opinion here. But I do think that a 'users view' is more
important than 'artifact view'. Perhaps both can exists, so that users drop
issues in one end which they understand, and they are sorted into the
sections that are more closely related to development, by the developers.
> * SVN layout ( {ttb} structure )
IMO, things are already 'fine'.
If you need to branch, copy whatever you want to /repos/asf/avalon/whatever,
in practically whatever structure you care for; the whole of runtime or just
the Framework Impl if that makes more sense.
> * artifact versioning (which relates to repository structure)
Artifact versioning and Release Management is closely related. IMHO, the
artifact should probably be name with the SVN revision number if everything
is up-to-date, otherwise tagged with some type of 'inofficial' marker, which
means that the artifact can not be reconstructed.
In the Release Management, we would then need tools (Magic, for instance) to
tie-in which artifacts goes into a 'distro version', such as Merlin 4.0.
> Now perhaps I'm just too far behind on the learning curve for SVN, JIRA,
> and our own versioning scheme, so if someone else knows the master plan I'd
> really appreciate some illumination. Otherwise, we need to nail this down
> and reconcile our internal structure.
Except for;
1. JIRA
2. Release Management
I think things are pretty well nailed down.
One word about Avalon Planet...
The idea is that "Discovery" will become a 'Component Publishing System', i.e.
server side components, and Avalon Planet is "discovery" running 'somewhere'.
The Cornerstone and Facilities are "default content" on the Planet, but
anyone should be able to publish components fairly easily, and those
components are not part of our avalon/planet/ svn directory.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
