You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by J Aaron Farr <fa...@apache.org> on 2004/01/17 13:32:11 UTC
JIRA Proposal Summary
Hello everyone.
This thread is to summarize the discussion, suggestions and concerns
surrounding our adoption of JIRA. Hopefully next week we can bring this
to a VOTE (if necessary) and submit the request to infrastructure.
= Unanimous Support of Adoption =
First, I want to point out that thus far, there has been unanimous
support for adopting JIRA. Moreover, we would like to start fresh with
JIRA and not worry about importing historic data from Bugzilla. No one
has yet posted an objection to these proposal.
= JIRA Admins =
Aaron Farr, Stephen McConnell, and Noel have been suggested as admins.
I would like to add that rather than limit the administrative duties to
a few, perhaps all the PMC (if not all committers) be given admin
rights. Even if only a couple of us actually perform most admin duties,
this more open approach might encourage more participation and would
spread out the work.
= JIRA Project Organization =
There has been quite a bit of discussion about how to organize projects
in JIRA. To review, there are three levels in JIRA (from large to
small): categories, projects, and components. Categories provide a view
of related projects. Projects support versions, roadmaps, changelogs,
etc. Components are subproject units to which specific issues can be
assigned. If you haven't already, please visit a JIRA site and
familiarize yourself with this layout (http://issues.apache.org/jira).
There are currently two main proposals for how to organize our projects
in JIRA:
== The Aggregated Approach ==
Category: Avalon
Avalon
Excalibur
Cornerstone
Logkit
Merlin
Phoenix
Fortress
== The Component Approach ==
Category: Avalon
avalon-extension-spi
avalon-extension-impl
avalon-framework-api
avalon-framework-impl
avalon-meta-api
avalon-meta-impl
avalon-meta-spi
avalon-meta-tools
avalon-meta-plugin
avalon-composition-api
avalon-composition-impl
avalon-composition-spi
avalon-activation-api
avalon-activation-impl
avalon-activation-spi
avalon-util-exception
avalon-util-criteria
avalon-util-defaults
avalon-util-env
avalon-plugin
avalon-repository-api
avalon-repository-impl
avalon-repository-main
avalon-repository-spi
avalon-repository-util
Fortress
Phoenix
LogKit
Category: Merlin
merlin-api
merlin-cli
merlin-impl
merlin-plugin
merlin-unit
Category: Cornerstone
cornerstone-connection-api
cornerstone-connection-impl
cornerstone-datasources-api
cornerstone-datasources-impl
cornerstone-scheduler-api
cornerstone-scheduler-impl
cornerstone-sockets-api
cornerstone-sockets-impl
cornerstone-store-api
cornerstone-store-impl
cornerstone-threads-api
cornerstone-threads-impl
Category: Excalibur
excalibur-compatibility
excalibur-component
excalibur-configuration
excalibur-datasource
excalibur-event
excalibur-i18n
excalibur-instrument-manager
excalibur-instrument
excalibur-lifecycle
excalibur-logger
excalibur-monitor
excalibur-naming
excalibur-pool
excalibur-sourceresolve
excalibur-thread
There are obviously several other solutions, but these two approaches
give us somewhere to start.
Aggregated Pros
* Maps well to our 'high-level' product list
* Most Excalibur/Cornerstone projects are released together as a
group. The same is true of Merlin (see recent release vote).
* Easy to administer
* Easily allows old components to be retired and new ones added.
Aggregated Cons
* Glosses over sub-component differences
* Difficulty of determining proper level of aggregation (should things
like repository and meta be in a group with framework?)
* Cannot properly track versions for components. There will be some
discrepancy in artifact versions vs JIRA versions. Changelogs and
Roadmaps will also reflect this.
Component Pros
* Maps well to our actual versioned products (or maven artifacts).
* Individual change logs and roadmaps for each project
* Encourages each component to have its own release cycle
Component Cons
* Difficult to administrate and view/browse (there's over 60!)
* Greater likelihood of issues getting assigned incorrectly
* Requires new projects be created in the future for all new
components. Deprecated components will remain as a project in JIRA.
= Closing Thoughts and a VERY biased opinion =
The issue of how to organize is really all about 'view.' To put it in
maven terms, one is a view of the GroupID level, the other is a view of
the individual ArtifactID. ( On a tangent, I'd like to point out that we
don't have groups and artifacts very well defined and this might be a
good time to get that ironed out as well. ) It's also interesting to
note that in the current Bugzilla setup we have one product (project),
Avalon, and three components: Avalon, Excalibur, Framework.
My very biased opinion: go with the aggregated view. Avalon is
complicated already. The component view only seems to add to that
complexity. Let's keep it simple.
Moreover, and I think this is a VERY important point, if we made the
'component' list a year ago, it would have looked different. Very
different in fact. While we can always request new projects be made,
this approach seems like an administrative nightmare. We regularly have
components being sent over to jakarta-commons and new ones popping in
and out of the sandbox. The aggregated approach will be more dynamic
and more easily grow with Avalon.
For those who are concerned about Roadmaps and Changelogs and versions,
I would like to point out that we're currently releasing products as
groups anyways. See the current merlin release. Look at how we've
released Excalibur and Cornerstone in the past. It won't be that hard
to point out in the release notes which artifact versions correspond
with which group release version. And anything would be an improvement
over the current situation in which good Roadmaps and Changelogs and
issue tracking is all but nonexistent.
Finally, I feel it would be easier to start small and grow if
necessary. Most of us are new to JIRA. It will be much easier to break
out issues into new projects than aggregate later.
I will fully support whatever approach the developer community decides
on. I'm very excited to make this move and see Avalon improve as a
result.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JIRA Proposal Summary
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-01-17 at 17:12, Stephen McConnell wrote:
> It's a starting point - and I figure the sooner we start the sooner we
> will have a better idea about the real overhead concerning potential
> changes.
I like your suggestions.
Many of us feel that avalon-excalibur could eventually be dissolved into
Avalon Components (Cornerstone) and a set of Avalon utilities (probably
held under the avalon CVS module). But doing so will not be easy due to
the amount of legacy support needed. For example, Cocoon committers
have access to excalibur and will be equally interested in its future.
So, we're now looking at:
Category: Avalon
avalon-framework
avalon-extension
avalon-meta
avalon-util
avalon-repository
avalon-site <-- or should site be a component somewhere?
Fortress
Phoenix
Logkit
Excalibur <-- at least to start. Perhaps will expand or
disappear completely
Category: Avalon Components
cornerstone-connection
cornerstone-datasources
cornerstone-scheduler
cornerstone-sockets
cornerstone-store
cornerstone-threads
Category: Avalon Merlin
avalon-composition
avalon-activation
merlin
merlin-http
merlin-jmx
Yeah, this looks much more reasonable.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JIRA Proposal Summary
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
> On Sat, 2004-01-17 at 19:02, Stephen McConnell wrote:
>
>
>>>The JIRA people must have been thinking about this before and during
>>>development, since IMHO
>>>Category = Avalon
>>>Product = Cornerstone
>>>Component = Cornerstone Datasources
>
>
> So this is basically the aggregated approach listed. Other components
> would include things like Documentation and Test coverage.
>
>
>>Instead ... I'm thinking along the following lines:
>>
>> Category = Avalon Components
>> Product = Cornerstone Datasources
>> Component = Documentation
>
>
> I've been burning out a few brain cells myself on this one too. :)
> Seeing the exact list of project helps me understand the situation
> better. So under this setup we have:
>
> Category: Avalon
> avalon-framework
> avalon-extension
The avalon-extension package is currently under the Merlin tree but
really needs to move to Avalon level because:
(a) its future relationship to the repository package
(related to classloader construction).
(b) its not a component
> avalon-meta
> avalon-composition
> avalon-activation
I suggest we keep avalon-composition and avalon-activation under a
Merlin category for now.
> avalon-util
> avalon-plugin
The avalon-plugin should be handled as a "component" of the avalon-util
product.
> avalon-repository
> avalon-site <-- for site-wide documentation.
> Fortress
> Phoenix
> Logkit
>
> Category: Avalon Components
> cornerstone-connection
> cornerstone-datasources
> cornerstone-scheduler
> cornerstone-sockets
> cornerstone-store
> cornerstone-threads
>
> Category: Avalon Excalibur (should this be combined with Components?)
I don't think we should do this as sweeping move. Instead I would keep
Avalon Excalibur as a category and deal with changes on a step by step
basis as the respective products evolve.
> excalibur-compatibility
This one could/should go under a new Avalon Archive category.
> excalibur-configuration
Recommend moving excalibur-configuration to avalon-util.
> excalibur-datasource
> excalibur-event
> excalibur-i18n
Recommend moving excalibur-i18n to avalon-util.
> excalibur-instrument
> excalibur-lifecycle
Should move to avalon category.
> excalibur-logger
> excalibur-monitor
> excalibur-naming
> excalibur-pool
> excalibur-sourceresolve
> excalibur-thread
>
> I intentionally left Merlin out. Not sure if it would be a category or
> single project. Under this scheme I could see it going either way.
Here is the breakdown for a Merlin Category.
Category: Avalon Merlin
Product: avalon-composition
Product: avalon-activation
Product: merlin
Product: merlin-http
Product: merlin-jmx
> This seems much more reasonable. Still a little uneasy about components
> coming and going. Several of these Excalibur components could disappear
> this next year, being merged into a cornerstone equivalent, sent to
> jakarta-commons, or just deprecated. This, more than anything else, is
> really my concern about such an approach. And more so with Excalibur
> than anything else too.
Yep - its a headache.
> Maybe we could initially have just one for excalibur and have everything
> else as listed above. At least until we have a better feel for these
> component's future.
It's a starting point - and I figure the sooner we start the sooner we
will have a better idea about the real overhead concerning potential
changes.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JIRA Proposal Summary
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-01-17 at 19:02, Stephen McConnell wrote:
> > The JIRA people must have been thinking about this before and during
> > development, since IMHO
> > Category = Avalon
> > Product = Cornerstone
> > Component = Cornerstone Datasources
So this is basically the aggregated approach listed. Other components
would include things like Documentation and Test coverage.
>
> Instead ... I'm thinking along the following lines:
>
> Category = Avalon Components
> Product = Cornerstone Datasources
> Component = Documentation
I've been burning out a few brain cells myself on this one too. :)
Seeing the exact list of project helps me understand the situation
better. So under this setup we have:
Category: Avalon
avalon-framework
avalon-extension
avalon-meta
avalon-composition
avalon-activation
avalon-util
avalon-plugin
avalon-repository
avalon-site <-- for site-wide documentation.
Fortress
Phoenix
Logkit
Category: Avalon Components
cornerstone-connection
cornerstone-datasources
cornerstone-scheduler
cornerstone-sockets
cornerstone-store
cornerstone-threads
Category: Avalon Excalibur (should this be combined with Components?)
excalibur-compatibility
excalibur-configuration
excalibur-datasource
excalibur-event
excalibur-i18n
excalibur-instrument
excalibur-lifecycle
excalibur-logger
excalibur-monitor
excalibur-naming
excalibur-pool
excalibur-sourceresolve
excalibur-thread
I intentionally left Merlin out. Not sure if it would be a category or
single project. Under this scheme I could see it going either way.
This seems much more reasonable. Still a little uneasy about components
coming and going. Several of these Excalibur components could disappear
this next year, being merged into a cornerstone equivalent, sent to
jakarta-commons, or just deprecated. This, more than anything else, is
really my concern about such an approach. And more so with Excalibur
than anything else too.
Maybe we could initially have just one for excalibur and have everything
else as listed above. At least until we have a better feel for these
component's future.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JIRA Proposal Summary
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Saturday 17 January 2004 04:32, J Aaron Farr wrote:
>
>
>>My very biased opinion: go with the aggregated view. Avalon is
>>complicated already. The component view only seems to add to that
>>complexity. Let's keep it simple.
>
>
> I agree with your very exhaustive analysis of this. (Thanks).
>
>
>>Finally, I feel it would be easier to start small and grow if
>>necessary. Most of us are new to JIRA. It will be much easier to break
>>out issues into new projects than aggregate later.
>
>
> The JIRA people must have been thinking about this before and during
> development, since IMHO
> Category = Avalon
> Product = Cornerstone
> Component = Cornerstone Datasources
>
> Seems to map fairly well with what we have and to make it reasonably
> manageable.
Have been thinking hard following Aaron's post. The result of that
(aside from burning a few cells) is that I think the above approach is
wrong in that it does not map down to the Component concern (where
Component in JIRA != Component in Avalon).
Instead ... I'm thinking along the following lines:
Category = Avalon Components
Product = Cornerstone Datasources
Component = Documentation
The component category should (IMHO) typically contain things like
"Documentation", "API", "Implementation". Using this approach assumes
that we have a distinction between "Product Version" and the set of
artifact versions that the product is composed of.
Cheers, Steve.
>
> Niclas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JIRA Proposal Summary
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 04:32, J Aaron Farr wrote:
> My very biased opinion: go with the aggregated view. Avalon is
> complicated already. The component view only seems to add to that
> complexity. Let's keep it simple.
I agree with your very exhaustive analysis of this. (Thanks).
> Finally, I feel it would be easier to start small and grow if
> necessary. Most of us are new to JIRA. It will be much easier to break
> out issues into new projects than aggregate later.
The JIRA people must have been thinking about this before and during
development, since IMHO
Category = Avalon
Product = Cornerstone
Component = Cornerstone Datasources
Seems to map fairly well with what we have and to make it reasonably
manageable.
Also, I happen to believe that with a bit better build system, we could easily
have Product Releases and sync all the Artifact versions to it, i.e. I change
cornerstone-thread-impl, the whole Cornerstone product is released and all
JARs in it is updated with the new version number. (I mean we don't have 36
hour build times!)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org