Great work Dave!
All E and N projects should be pointed to the main issuezilla to avoid that
someone creates issues and worsens the situation.
I have gone through the subcomponents and modernized the description of some
of them, and I created the SQL module subcomponent since there wasn't any.
Shall I create the Ruby module subcomponent too?
The projects in seeds need also be considered or at least pointed to the
main project. I guess they're all E's.
The argouml-downloads and argouml-stats project are project to publish
things in. They are set up as parts of the main project more or less. This
is to avoid having distributions and result from nightly build filling up
the disk (4,5Gig) for persons that have checked out the whole trunk.
As an experiment I will start by attempting to move the issues from the
argouml-gen and argoumlinstaller projects to the subcomponent Build scripts
and tools.
/Linus
2008/5/19, Dave Thompson <[EMAIL PROTECTED]>:
>
> > >> Could you, before we proceed in this, try to get an idea of how this
> > >> is going to affect the current projects. How many projects have
> > >> issues in their issuezilla that would then be moved and the persons
> > >> working in those projects, how do they feel about this?
> > >
> > >> To avoid making things worse we should go through all projects that
> > >> haven't got any issues in their issuezilla and make sure the issues
> > >> link in the project_tools point to the ArgoUML issuezilla and that it
> > >> is appearant what subcomponent should be used.
> > >
> > > I will take a look.
>
> Here are my findings:
>
> N = no link to any issue tracker found.
> M = using main ArgoUML issue tracker
> A = using separate issue tracker, and active
> E = using separate issue tracker but currently empty
>
> M argouml-andromda
> E argouml-classfile
> A argouml-cpp (26 issues)
> M argouml-csharp
> A argouml-db (6 issues)
> E argouml-de
> M argouml-downloads
> E argouml-en-gb
> N argouml-es
> N argouml-fr
> A argouml-gen (9 issues)
> M argouml-i18n-zh
> E argouml-idl
> E argouml-it
> M argouml-java
> N argouml-nb
> E argouml-php
> A argouml-pt (1 issue - discussing validity of issue tracker!)
> E argouml-pt-br
> E argouml-ru
> A argouml-ruby (1 issue)
> E argouml-sql
> M argouml-stats
> A argoumlinstaller (6 issues)
>
> It is clear that we are only talking about a small number of issues
> outside of the main project. argouml-cpp is the exception to this, and
> as Luis has requested, we should probably leave this alone.
>
> I think that all projects with E or N classifications, should be
> converted to the main issue tracker (just by updating the link). The
> others could be moved to the main argouml project if we wanted to, with
> out much work, as there are only 21 real issues in total.
>
> It just depends on what people's preferences are...
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
