Hi yoheeb,

> The biggest thing regarding this post you made, is that you would
> "expect" items x,y,z to make it into the core is potentially an issue
> with working with the trac team.  
You got me wrong in my initial request, that an explicit plugin x,y,z 
should make it into core. I'm more concearned about the possibility to 
write such plugins without major modifications to the core and without 
major reengeneering outside the core. You mentioned e.g. the 
"MasterTicktet" plugin that is implemented fully outside of the core. I 
think, that the inner workings of the interlinking belongs into the 
ticketing system so that other projects can use it as well. Without 
looking into the technical details, the two projects (agilo and master 
tickets) implemented two ways of interlinking tickets. Both keep their 
own tabels for the bookkeeping. No other additional plugin can rely on 
the basic of interlinking, e.g. the ticket dependecy graph. I strongly 
believe, that support for this belongs into the core. Consider e.g. also 
the "duplicate" handling that is way from optimal in trac. I was fooled 
to often by an issue that was closed and marked as a duplicate, without 
being resolved with a solution. I don't say, that MasterTickets belong 
into the core, but the handling for inter dependencies belongs there.

About Ticket domains: I as a user want to have at least three complete 
different ticket domains. Requirements (internal development, eg. 
scrum), real customer bug tracking and test tracking. While I'm able to 
bend the current single domain into my needs, the overhead seems to be 
higher than abstracting away the "basic" ticketing system with all it's 
features and instantiating three different standalone domains, all with 
their own workflow.

About separation of view/edit tabular interface: Also here I don't want 
to necessarily see it in the basic core (so I still think it is good 
feature ;-) I would like to see an interface in the core to enable it's 
exploitation in plugins, e.g. a plugin that can show all dependant 
checkings to a ticket. Currently we have a problem since we need to 
modify the ticket template page (so it already got better with 0.11)

I'm a C, C++ programmer, I can not help out. My major interest is the 
usage of trac in a business environment to support ISO certification and 
GAMP. I see a lot of interesting and necessary features for my needs 
implemented as plugins with a strong tendency to not rely on each other, 
but only on the core. Since working with trac, we where always faced 
with the problem of non interoperable versions of plugins and the core. 
As a OO designer I have some experience in building extensible systems. 
I'm trying to raise my voice, when I see an area of improvement.

And a word to the developers: keep up the good work. I will continue to 
use it.
Dirk


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to