Well, a grand new year was had, I went over to a party some friends were holding to discover they all seemed to know each other purely by reading each other LJ.
Anyway I said I'd post about the bug system I was sorking on some here or some docs culled from the development directories. It pretty much works as described although I have yet to actually use it anger - and it still need some debugging itself. I haven't even tried the search yet, although I have coded an algorithm which should work as per described . (Famous last , I know).
PS: - I can believe how long it took me to compose this , especially since I started with well formed html, produced by pod2html. Sigh. And the html seems to have got worse not better..
The 'current' status of a bug is tracked using a record object, which is stored in a file. This file is checked into the SCM/VCS system alongside the code.
The dates the bug was first committed and subsequently revised reflect the date the information in the update were made available in the bug database. So it important not to use commit dates for bug records in to much of a similar way to you might for code files.
If you consider the usual lifetime of a bug this make sense - a bug is coded at some arbitrary point in the development cycle but only some time later is it discovered and added to the bug database. When a bug is fixed we leave the bug record in the VCS and change it status 'Fixed'. And similarly for other terminal states.
By using symbolic tags to indicate which versions of the code suffer from the bug, this means we can only retrospectively track bugs against tagged versions of the software. But this is not unreasonable as most , if not all development shop use tags to mark 'versions' of the software , which are used outside of the development team itself.
This gives us or first SCM requirement - our SCM system must provide us with a mechanism for adding a existing tag to new files, some distributed SCM systems may have a problem with this concept. Indeed in some people's view this is a violation of proper SCM semantics - as you should be always able to track all changes to the data /and/ metadata a SCM system stores. In pure software terms adding a file to an already released version is clearly a stupid thing to do as it changes to exact build used by that version.
However these semantics allow the development team to track bugs by date in the current version and by tag in earlier versions. For SCM system which don't support this , we should be able to simulate it with extra tracked data, which contains the bug revision to symbolic tag
mapping. (TODO).
A desired side-effect of this semantic is that new versions (tags) of the software will automatically be assigned with the current status of all the reported bugs, so if the bug has been fixed the new version of the code will still show the code was fixed, and similarly if it is still open the database show the current version as having that bug.
Unfortunately the above would suggest there is a problem if someone reports a bug in 1.x which has already been (maybe unwittingly) fixed in (say) 2.0 . At first site this seems to be a problem, as it would show 2.0 has having the bug - assuming you want to keep the bug open for fixing in 1.0.
But as you can see in this case 2.0 would have to be on a separate VCS branch to 1.0 otherwise you wouldn't be able to continue to track changes to 1.x .So in this case you only need to create the bug record in the 1.x branch.
However, the Corollary to this that if the bug exists in both versions you need to create separate bug records in both branches. Of course this happened automatically for bug which exist when you branch, as your VCS system takes care of this.
OPTION:1:
The system currently provides no tools to keep these records synchronised.
OPTION:2:
To keep both bugs synchronised you need to decide on of the bugs is the master and create a reference record on the other branch. : Problem , this is not what standard branching does, so if bugs which are creating before a branch point end up as back to option 1.
Bugbase::Bug - Operate on Bugbase bugs
use Bugbase::Bug ;
my $bug = new Bugbase::bug(Summary => "bug title",
Severity => "Baad",
Status => "Open");
$bug->save();
$bug->version($version);
my $otherbug = Bugbase::bug::find($pathlist , @findspec);
print $other->version();
Provides methods to manipulate the bug records with bug management centric names.
This module is basically a wrapper around either VCS::xxx , and DB::rfc822 which does the approriate thing.
This removes the need to thing about the bugs as anyhing else and just thing about the operations in terms of the bugs, rather than how this might be expressed at the back end.
- new
- Creates and returns and new bug object, for a new bug.
- find($pathlist , @searchspec )
- return a bug object matching the arguments .
- Path list is an arrayref of paths to search, and search spec is an a array of hashrefs. Each hashref contains a key/value pair where the key is the field to be matched - the value is a an array of regexps, to match.
The specification is considered matched if all the regexp's in any hash
set match.
- Status
- An accessor for the status method of the bug.
This accessor clears the version array, so that $bug->status('Fixed'); doesn't mark the bug as fixed historically.
- Resolution
Priority
- Hardware
- Os
- Creator
- Assignee
- Summary
- Commentary
- Accessors for the simple bug fields, these are store in the bug file. The only exception is commentary which is stored in the bug record's body. You can use any fieldname here which is compatible with DB::rfc822.
- version
- This is an accessor for version array which constains a list of 'tags' the currently selected bug revision. For instance if the currently selected revision has status 'Open' , this will return an arrary contain the versions of the software which are believed to contain the bug.
- FIXME
1.This method cannot currently be used to clear the tags on a version.
2.This method currently operates on the HEAD.
-
- revision
- This returns the revision number of the selected bug record.
- commit ( message )
- Save and commit to the repository the currnet chnages in the bug record.
- fullname
- this returns the full path name of the bug file.
- shortname
- this returns the leaf name of the bug file.
- canonicalname
- this returns a globlay unique a staticname for the bug, it is normally based in the VCS naming conventions.
