- BUGS - Bug repository
- REPO - Source code repository
Contains a collection of bug-items (BI) with the following attributes:
- ID - unique identifier of the bug
- From - RFC2822 identifier
- Affects - list of identifiers into REPO (may begin w/ '-' to remove item)
- Status - 'status' of the bug
- [Revision] - REPO identifier associated w/ this message
- [IsHead] - should this be considered the 'head' bug item?
The basic storage is expected to be an RFC 2822 type of message.
To make the interfaces as simple as possible, the operations list should be minimal.
- Query - search for bugs based on attribute-values
- New - create a 'stored' bug with a new unique ID
- Append? - add a new message for a given unique ID
Internal ops - applied from REPO hooks or automatically
- AppendGenerated - add a new generated message for a given unique ID
- RefreshGenerated - in cooperations w/ REPO check for update/remove on a generated message
This data is expected to be split into two categories:
Generated items will be stored in a cache, ready to be regenerated/cleared as need-be due to changes in repository. Ex: A 'rebase' event could cause an item to be eliminated.
Since this data is probably not the easiest to search in a meaningful way, a cache is expected to be created on demand.
An example caching mechanism would be a normalized SQLite database containing data items likely w/ indexes on the following:
The BUGS data should be stored in a repository with a plain-old directories/files structure. How this layout is to work is yet to be resolved...
Distribution can be alongside the primary repository as its own branch.
Directory layout: BUGS/ Bug Unique ID 1/ Bug Unique ID 2/ HEAD
- Is there any sane way to integrate w/ email client since they already speak RFC 2822?... or would this lead to trouble.
- How should the 'main' BI be handled... the one that marks the 'head' subject/etc..
- How should BI merges be handled (see above for 'head' item alteration)
- Distribution... how should modifications to a BI be ordered (last one for specific history is truth)?
The storage location for the source code that BUGS is associated with.
Initially this will be Git, but it should be easy to adapt due to the limited operation set.
- Log (START..STOP) - obtain a list of log messages from START to STOP Used for parsing out 'generated' bug messages (ex: fix locations, progress markers)
- Branches - obtain a list of branches
Usage of 'hooks'
To avoid having to 'always' query for change logs, hooks may be used to assist the bug system w/ knowledge about events as they happen rather than on-demand.