Thanks for doing the survey, Dave. You've probably visited all these sites more than anyone else in years!
The C++ module has 35 issues (7 open) in the main project bug tracker in addition to the 26 issues (17 open) in the separate bug tracker. Personally, I have strong preference for a single place to check for all bugs to do with ArgoUML and its sub-projects, but it really comes down to a matter of philosophy. If these separate projects are all intended to be autonomous, then the project leader should get to pick and their say is final. Of course that seems a little bit at odds with all projects using the same release vehicle, the same schedule, the same coding conventions, etc, etc. Certainly I would direct everything back to the main project for projects which haven't clearly made an explicit choice. For the others I guess it depends on how strongly the individual project leaders feel about having things separate. One thing I'm curious about is the release criteria for bundled modules. Do they get included regardless of their bug status? Does someone check the separate bug trackers (I know I don't). Someone asked earlier about filtering issues for specific components. I deal with all issues through Mylyn in Eclipse and have separate categories set up for things assigned to me, blockers, new things assigned to nobody, etc. You can set up as many categories as you want with arbitrary criteria and you can easily set up a category for just a specific component. Incoming updates are shown in little popups as they come in and the display is updated with markers for bugs that have unread updates. I find that a good way to keep up with things without having to wade through all the emails. Tom p.s. If we do end moving bugs between trackers, we should try and keep as much history/context as possible. I think there's a way to export/import XML with the Tigris tracker, but I'm not sure how well it works between trackers which have different schema. On Mon, May 19, 2008 at 8:10 AM, Dave Thompson <[EMAIL PROTECTED]> wrote: >> >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
