From Eigen
Revision as of 03:04, 4 October 2010 by Bjacob (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Bugzilla is the issue tracker that we use for most of our feature development, not just for handling bug reports.

Reporting a bug

Go there. Make sure to select the right severity: 'normal' is good for bugs, 'enhancement' is good for feature requests.

Developing a new feature

You should file a new 'bug' for each feature that you're developing. Henceforth it's important to note that in bugzilla terminology, a 'bug' is not necessarily a bug in the usual sense, it is just any issue under tracking.

You can split big features into smaller bugs, but then it's a good idea to file a meta-bug about the feature and mark it as 'depending' on the smaller bugs.

Attaching a patch

When you attach a patch to a bug, make sure to tick the 'patch' checkbox.

Asking for review

Asking for review serves two main purposes. First of all, unless you are a very experienced Eigen developer, we ask that you get your patches reviewed before you can push them. Second, asking for review means that the requestee gets notified about your patch and can't forget it.

In order to ask for review, when you attach a patch, or later on in the 'Details' page of the patch, at 'review', select the question mark '?' and select the person who should review your patch.

If you don't know whom to ask, you could look at Mercurial history for the files you're touching (hg log or hg annotate), but make sure to choose someone who's made lots of commits to Eigen already.

Reviewing a patch

By clicking on 'Details' for the patch, you can see on one page the raw patch, a text area to type your comment, and the review status controls. Don't hesitate to copy and paste lines from the patch into your reply. You can then replace the review '?' by a '+' to accept the patch, or '-' to reject it.

Updating a patch

If you're uploading a new version of a patch, please mark the previous version as 'obsolete'. This will cancel existing review requests and hide it by default.

If a review was pending for this patch, you need to review again.

If the patch had already been reviewed, and your changes are trivial (you only fixed a typo), you may review your own patch (select review '+') and add a comment saying 'Carrying forward r+ ...'.

Linking to other bugs

If you say 'bug 36' in a comment, bugzilla creates a link. You can link to a specific comment by saying 'bug 36 comment 12'.

Relations between bugs =

The lines 'Blocks' and 'Depends on' are where you can enter the ids of other bugs to create dependency relations. Note that if A blocks B, automatically B depends on A, and conversely.

Another kind of relation is that of being a duplicate. When you change the status of a bug, under RESOLVED, the entry DUPLICATE prompts you to enter the id of the other bug of which the current bug is a duplicate. If you hesitate between making X be a duplicate of Y or conversely, the rule of thumb is: make the bug with the most interesting content (patches...) be the one that remains open.

Tracking the development of future Eigen versions

Each planned future Eigen version should be represented by its own bug, for example Eigen 3.0 is bug 25.

The features or bugs that we consider 'blocking' the release are precisely the bugs listed as 'Blocking' the release's bug.