Ticket #4883 (closed enhancement: worksforme)
Opened 5 years ago
Last modified 17 months ago
Automatic feature list of the software being developed through commit logs
| Reported by: | laxminarayan@… | Owned by: | jonas |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | general | Version: | |
| Severity: | major | Keywords: | tracobject notification |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
Currently, feature lists of large softwares are managed manually. But additions, modifications, and removals of features are dependant on commits. So I was wondering if there is any way to manage a special wiki page which contains the feature list of the software, just like the tickets ("#fixes" kinda stuff).
Features can have numbers too! Feature lists have a tree structure, so the numbering must be in order with that.
One example commit message can be
AddFeature 12.4.3 Automatic feature-list management. Fixes #5000
and one more
AddsFeature 12.4.3.7 #5001 Optional storage of ticket number where feature was requested. Fixes #5001
So now you not only have an automatically managed feature list, but also a complete timeline of when a feature/subfeature was added, modified or removed.
Attachments
Change History
comment:1 Changed 5 years ago by laxminarayan@…
- Summary changed from Automatic feature list of the software being developed to Automatic feature list of the software being developed through commit logs
comment:2 Changed 5 years ago by cboos
- Component changed from version control to general
- Keywords tracobject notification added
- Milestone set to 2.0
- Owner changed from cboos to jonas
comment:3 Changed 22 months ago by cboos
- Milestone changed from 2.0 to unscheduled
Milestone 2.0 deleted
comment:4 Changed 17 months ago by cboos
- Milestone triaging deleted
- Resolution set to worksforme
- Status changed from new to closed
Something like this can now be implemented as a plugin using the IRepositoryChangeListener interface.



Sounds like requirement management (Feature lists have a tree structure).
I believe that adding such a subsystem to Trac should be easily done as a plugin once a more generic data model is in place. See GenericTrac.
Also, the link between commit message and actions taken on the requirements would be facilitated by a changeset notification mechanism, see TracDev/Proposals/Journaling.