On 07/26/2012 01:41 PM, Peter Robinson wrote:
Ultimately I think it's very hard in a lot of the cases to draw a line
between two trac instances and say "This should be open" and "This
should not be open" and in a a non small amount of cases the tickets
move from one side to the other in either direction during the tickets
life time and there's no way of even finer grained control to be able
to make certain updates public or private.
Perhaps the mistake we have been doing all this time is that we have
been to focused on using trac ( most likely due to the fact
infrastructure was/is familiar with it ) to handle requests instead of
something that well was designed to handle this. At the university
where I was working we used Best Practical's request tracker [1] to
handle these issues and here at the IBM partners which I currently work
for we are using JIRA.
So perhaps it would be better if we approach the solution to the problem
we are faced with ( open what can be open while keeping closed which
arguably would should be closed ) by looking at switching to another
issue tracker instead of deploying multiple track instances and or
trying to patch trac to suit our needs.
JBG
1. http://bestpractical.com/rt/ ( Package well maintained within Fedora )
2.http://www.atlassian.com/software/jira/overview ( Commercial/Expensive
license arguably not really an option for the project )
( Both solution are mobile friendly which kinda is a requirement now on
the 21 century )
_______________________________________________
advisory-board mailing list
advisory-board@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
