Christopher Taylor schrieb: > this too is possible....... requires a creative use of custom fields > and some sql wizadry .... > Right, but my collegues don't understand why and when they have to fill which field with which information.
> for that one, try a custom field with a trac/code-browser url and then > write a query to search based on an input path. (what you would > search for is everything that has a prefix of <input>). > I'm currently looking for a hook script, that will fill out this information whith the checkin. > don't understand #2 > Our software goes through a lot of version and fixes. We have the normal major.minor.revision.buildnumber style for the version number. In most cases I can explizitly state in which version/revision a bug was introduced, or a feature was missing. Since we service at least two releases of our software, I have to fix the same bug at least three times, one time in the trunk, and two times in to different releases. If I could separate the solution for each release of our software, I could close the ticket one time for the trunk and two times for the branches. Additionally if you could attach a ticket to a revision, e.g. via a custom property in subversion, you could easily tell for each branch, which tickets are open an which are closed in specific branches. Currently I have to copy the ticket for each branch, and I have three ticket stating the same information. For me the issue and the resolution is a 1..n relationship. > #3, don't understand why ... if a milestone is a future version ... > where is the problem > if you track hardware and software issues within trac and also customer dates, the concept of milestone and "future version" does not mix very well. E.g. you must have finished a specific task for a specific milestone, but this does not necessarily mean, that this will result in a specific version. A bugfix or feature is sheduled for a specific future version. A milestone is simply an event, where a few things have do be done. Naturally you can use the same concept, but in respect with #2, I often want to distinguish between milestone and future version. > #4, the concept of a version is in there .... what kind of > relationships b/n versions are you intending? > 1. version ordering is not identical to natural ordering, e.g. 1.1, ...1.9, 1.10, ... and so on. 2. The most common use case is: which bugs are fixed in version 1.17.5 and please list all issues, also the one from 1.17.4, 1.17.3, 1.17.2, ... 1.16. In this moment you need to now, which version is the ancestor of which version in order to build. Again, everything can be done with different queries, but if trac would understand this, it would be easier. Additionally, not everybody uses this concept of versioning. E.g. one could use names to identify his version. But still one version will follow another, and version version is a bugfix release of another. and this is an important relationship 3. If versions are directly understood by trac, and the ticket is assigned to a specific release/version I would be able to tell "fixed in next version" and trac could fill out the rest for me. And finally I forgot to mention: * bulk edititng of ticket. We are currently using trac, and we expand it's usage now into testcasemanagement and requirements management. The above points are currently some of my findings, where I have additional overhead to get to my information. This is no rant, only some ideas, that I would like to see in some future. > -Chris > > On 6/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Hello John, >> >> are we working for the same company ;-) >> >> I would like to add a few more wishes to your list: >> >> * Ticket System >> * attach tickets to revisions and branches in subversion to be able >> to query which issues are still open in which branch >> * different solutions for issues in different branches >> * separation of "milestone" and "target version" >> * a concept of a version and the relation between versions >> >> Dirk >> >> >> >> John M Camara schrieb: >> >>> My company is in the process of selecting tools for change and >>> requirements management. They initial were looking only at commercial >>> products but I have been pushing for an open source solution. I felt >>> that Subversion & Trac already handles at least 60% of the >>> requirements and customizing Trac and building a simple Requirements >>> Management system would cost close to what it would cost to buy the >>> commercial products. >>> >>> Areas in Trac that I see need to be worked on are: >>> >>> * creating a plugin to manage custom permissions with web interface >>> * permissions web page >>> * make it easier to use when large numbers of users exist >>> * separate forms for adding users and roles (just cosmetic nothing >>> would change in the back end) >>> * add a view for displaying roles vs users >>> * ticket >>> * multiple ticket types (subclasses of Ticket) >>> * support for ticket hierarchies (child tickets) by adding a >>> parentTicketID field >>> * ticket fields >>> * defining and modifying custom ticket fields through a gui >>> * custom fields get assigned to a ticket type >>> * define the work flow transitions in which fields are writable, >>> required, readonly >>> * work flow >>> * separate workflows for each type of ticket >>> * add a gui for defining and modifying ticket workflows >>> * SQLAlchemy migration >>> * and some additional template customizations >>> >>> Most of these changes are minor changes to Trac or simple plugins that >>> need to be created except for the SQLAlchemy migration. >>> >>> The largest piece of work required in my proposal would be to create a >>> requirements management system. This system would have to support >>> features like >>> >>> * Managing requirements for multiple requirement documents >>> * Traceability between requirements from within a requirements >>> document, to a requirement in another document, external references, >>> or to files in the repository >>> * Integration with Trac's ticket/workflow >>> * Management of different views of the requirements >>> * Version control of requirements >>> * managing requirement properties >>> * support for multiple requirement document types - i.e test case, >>> user requirements, etc >>> * support for multiple requirement types - i.e use case, functional >>> requirement, marketing, unit test, etc >>> * etc >>> >>> I have noticed lately that more and more large companies are starting >>> to adopt Trac so maybe some of you that are reading this would also be >>> interested in this development. If you have any interest in this >>> project let me know. Especially if your interested in doing some of >>> this development or if you company may be interest in sharing the cost >>> of some of the development. >>> >>> Any support from the community will greatly improve the chances that >>> my company will accept my proposal. If they do accept it they would >>> be willing to spend a reasonable amount of funding for this project >>> although I don't know the exact level at this time. This would be a >>> great opportunity for Trac to gain additional corporate users as well >>> adding some new features to Trac, especially completing the SQLAlchemy >>> migration. >>> >>> If my company accepts the project (decision to be made mid July) >>> development would be ramped up quickly as a beta would be expected by >>> the end of the year. >>> >>> John >>> >>> >>> >>> >>> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
