My comments below!
2008/5/17, Dave Thompson <[EMAIL PROTECTED]>:
>
> On Sat, 17 May 2008 01:12:10 +0200, "Linus Tolke" <[EMAIL PROTECTED]>
> said:
> <snip>
> > I can think of the following pros and cons:
> >
> > - Use of the project issuezilla allows developers interested in a
> > certain project to subscribe to the corresponding mailing list
> > for notifications on issues without getting notifications of all
> > issues.
> Is there any way of subscribing to issues relating to a particular
> component? Could the notification email address for a particular
> component be set to the issues mailing list for that subproject? That
> might solve this one.
Not currently. It is probably possible to set up a mailing list dispatcher
function that does this by receiving each mail and doing some ingenious
filtering.
> - Use of the project issuezilla allows a different notification
> > policy (sending mails when issues are getting old).
> I see what you mean, although I never even realised that this feature
> was available.
>
> > - Use of the argouml issuezilla simplifies the handling of versions
> > and milestones. (I have not created them anywhere but in the
> > ArgoUML project because it is extra work).
> I suppose that by not including the subproject issuezillas in the
> versions & milestones, we are effectively assigning all their issues to
> an unspecified milestone, i.e. 'we will fix these issues as and when we
> can'. Also, all the lists of OSs, Platforms etc are seperate and
> possibly inconsistent. I think that for all subprojects, it would be
> better to have targets and priorities that relate to the main project
> and this should not involve extra work).
Platforms and operating systems are mostly a Tigris default even if it is
possible to set them per project. I haven't done anything with them.
> - Use of the argouml issuezilla increases the visibility of the
> > issue for the rest of the argouml project.
> I agree.
>
> <snip>
>
> Another thing to consider here, is where users will post their issues.
> They will probably submit issues to the first issue tracker they find.
> We then have a dilemma of whether or not to delete the issue and
> recreate it on the correct issue tracker, or just leave it as is. If it
> was one tracker, the triage procedure would simply be to assign new
> issues to the correct component.
>
> My suggestion would be to combine all issuezillas into one, and enforce
> this for new and old projects, rather than making it an option.
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.
/Linus
