> >> 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]
