I am too tired, I can't find the Import function. Please let me know if you
find it.

        /Linus


2008/5/19, Linus Tolke <[EMAIL PROTECTED]>:
>
> 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]
>>
>>
>

Reply via email to