Stick - Bugs with branches

• git://git.eharning.us/stick
• http://git.eharning.us/cgi-bin/gitweb.cgi?p=stick.git

Concept

Discussion

Entities

• BUGS - Bug repository
• REPO - Source code repository

BUGS

Bug Items

Contains a collection of bug-items (BI) with the following attributes:

• ID - unique identifier of the bug
• From - RFC2822 identifier
• Date
• Subject
• 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?
• Message-Body

The basic storage is expected to be an RFC 2822 type of message.

Operations

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

Storage

This data is expected to be split into two categories:

• Stored
• Generated

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.

Handling

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:

• ID
• Affects
• Revision
• Status

Distribution

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 Bug Item 1 - Unique ID Bug Item 2 - Unique ID

Questions

• 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)?

REPO

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.

Operations

• 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.