As the subject suggests, I am going to try to discuss several gigantic topics in Trac development. So brace yourselves ;-) (or abandon now)
The root for this discussion is my need for richer user management in Trac ( http://trac.edgewall.org/ticket/2456#comment:49), and Christian's reply that this should go into core, but employ GenericTrac (http://trac.edgewall.org/wiki/GenericTrac) instead of yet another model. I have spent a good part of the time since then looking into tons of wiki pages and tickets related to the topics mentioned in the subject (about 60 open tabs... good thing I have tab-kit for Firefox), that seem to be very inter-related to one another, and ended up with lots of insights and ideas, but also with much confusion as to how to proceed. >From the GenericTrac page it is not clear whether the concept is still being designed and actively discussed, or completed the design phase, and if implementation has begun somewhere (trunk / experimental branch / ..). Bottom line - what should I do in order to jump in and make it happen?? Furthermore, the details on the GenericTrac page are pretty focused on DB schema design, while I was also expecting details on a generic object model. This generic object model is mentioned in http://trac.edgewall.org/wiki/TracDev/Proposals/DataModel (which refers the reader back to GenericTrac), and also in http://trac.edgewall.org/wiki/TracObjectModelProposal (suggestions for a term for a "facet" of a TracObject: aspect, view, trait, descriptor). It's a little spaghetti-docs, so it's hard to tell which is the authoritative source on the subject, and the same questions as raised concerning GenericTrac apply here as well (state of design / discussion, state of implementation, pointer if I want to join). Considerations of multi-project support are intertwined throughout the previous 3 major topics, and I couldn't agree more that introducing GenericTrac and a unified generic ObjectModel is an excellent chance to apply multi-project considerations. Unfortunately - this makes the task even scarier in size than it's already is, which contribute to feelings of confusion and disorientation I experience (I'm certain that if it wasn't a holiday here, and I wasn't looking for excuses to avoid working on my thesis-research, I would never make it this far in digging into the docs and code). I think what should help in moving this forward is: - A coherent description of the state of things today (my questions above) - Some organization in the docs to avoid the spaghetti-sensation I experienced - An operative plan to implement the generic DB-schema and ObjectModel, that is clear enough to supply pointers to contributors who are interested in working on this (for example, I'm interested in working on user management, and am willing to do extra in order to make the generic stuff happen). If such a plan doesn't already exist in some way or another, I guess this is an opportunity to form that plan and discuss it. I think that, ultimately, there should be the following resources on t.e.o to track this endeavor: - Proposal-wiki-pages describing the *chosen* design of: Generic DB schema, Generic object model, Multi-project support (with historical ideas, discussions and brainstorming conveniently hidden in sub-wiki's under these proposals (or better yet, if it existed - another "facet", like discussions, or brainstorming)). - A dedicated milestone ("Generic Trac") with the operative plan as its description. - Assigning existing relevant tickets to this milestone, and creating new relevant tickets under this milestone. there are really lots of tickets that are relevant, so it might be useful to select a handful as leading use-cases and include them in the above operative plan. I'll finish with a little off-topic remark on the method of discussing proposals: if I read the wiki correctly, it appears that discussions took place directly within the wiki, by editing the content. this seems somewhat uncomfortable as compared to mailing list threads or ticket comments, since I don't get notifications for wiki-updates (no cc on wiki's), and it's not as trivial to track who changed what and why. don't read this as a complaint, but as a use-case for the generic object model, combined with the tabbed views concept (e.g. wiki's should also have cc-fields, and a discussion view (facet? :-) ), that can exist "behind" the "current content"). so, thanks for reading up to here, and I hope this will help make stuff happen! (there are numerous multi-year-old defects and enhancements that can be solved if we do this right!) Cheers, - Itamar O. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
