Difference between revisions of "Bugzilla"

From Eigen
Jump to: navigation, search
(Relations between bugs =)
m
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
<div style="background:#FFDDDD;font-size:170%;text-align:center;margin-bottom:1em">The Eigen project has switched to [https://gitlab.com/libeigen/eigen GitLab] and the information on this page is deprecated.</div>
 
[[Category:Developer]]
 
[[Category:Developer]]
 
 
[http://eigen.tuxfamily.org/bz Bugzilla] is the issue tracker that we use for most of our feature development, not just for handling bug reports.
 
[http://eigen.tuxfamily.org/bz Bugzilla] is the issue tracker that we use for most of our feature development, not just for handling bug reports.
  
 
== Reporting a bug ==
 
== Reporting a bug ==
  
Go [http://eigen.tuxfamily.org/bz/enter_bug.cgi there]. Make sure to select the right severity: 'normal' is good for bugs, 'enhancement' is good for feature requests.
+
Go [http://eigen.tuxfamily.org/bz/enter_bug.cgi there].  
 +
While entering the summary, a list of possible duplicates appears. Check these to avoid entering duplicates -- you can add yourself to the corresponding cc-list, add a new comment or edit the fields.
 +
Try to select the right component, or set it to 'General' if you don't know.
 +
Use the 'severity' field to indicate the kind of problem. If you are unsure use 'Unknown', or ask in IRC or the mailing list for other values. This has been added recently (2014-06-10), so many old bugs still have 'Unknown' severity.
  
 
== Developing a new feature ==
 
== Developing a new feature ==
Line 12: Line 15:
  
 
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.
 
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.
 +
 +
If your feature should make it into a specific Eigen release, add to the 'Blocks' field the tracking bug for that release. You don't need to know the tracking bug id, as tracking bugs have the version number as alias, e.g. the tracking bug for the 3.0 release has 3.0 as alias
 +
 +
== Tracking the development of future Eigen versions ==
 +
 +
Each planned future Eigen version should be represented by its own 'tracking bug', for example Eigen 3.0 is [http://eigen.tuxfamily.org/bz/show_bug.cgi?id=25 bug 25].
 +
 +
Tracking bugs have the corresponding version number as alias, so you don't need to remember their ids.
 +
 +
Features wanted in a given release are the bugs blocking the tracking bug.
 +
 +
== Assignees ==
 +
 +
If you're taking care of a bug, mark it as 'assigned' to you. By default, bugs are assigned to the dummy 'Nobody' user, which means that they need someone to take care of them.
  
 
== Attaching a patch ==
 
== Attaching a patch ==
Line 41: Line 58:
 
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'.
 
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 ==
+
== Blocks/depends relationships ==
  
 
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.
 
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.
+
Notice that certain important bugs have aliases so you don't need to remember their bug ids. In particular see the section about [[#Tracking the development of future Eigen versions|tracking bugs]]. For example, to mark a bug as blocking the 3.0 release, just enter 3.0.
  
== Tracking the development of future Eigen versions ==
+
Notice that for each bug you can view its dependency tree and graph.
 +
 
 +
== Duplicates ==
 +
 
 +
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.
  
Each planned future Eigen version should be represented by its own bug, for example Eigen 3.0 is [http://eigen.tuxfamily.org/bz/show_bug.cgi?id=25 bug 25].
+
== Email notification ==
  
The features or bugs that we consider 'blocking' the release are precisely the bugs listed as 'Blocking' the release's bug.
+
Email notification works by "watching" other users. Just by watching the 'Nobody' user, which is the default assignee for new bugs, you'll get notified of almost all new bugs.

Latest revision as of 22:59, 27 February 2021

The Eigen project has switched to GitLab and the information on this page is deprecated.

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. While entering the summary, a list of possible duplicates appears. Check these to avoid entering duplicates -- you can add yourself to the corresponding cc-list, add a new comment or edit the fields. Try to select the right component, or set it to 'General' if you don't know. Use the 'severity' field to indicate the kind of problem. If you are unsure use 'Unknown', or ask in IRC or the mailing list for other values. This has been added recently (2014-06-10), so many old bugs still have 'Unknown' severity.

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.

If your feature should make it into a specific Eigen release, add to the 'Blocks' field the tracking bug for that release. You don't need to know the tracking bug id, as tracking bugs have the version number as alias, e.g. the tracking bug for the 3.0 release has 3.0 as alias

Tracking the development of future Eigen versions

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

Tracking bugs have the corresponding version number as alias, so you don't need to remember their ids.

Features wanted in a given release are the bugs blocking the tracking bug.

Assignees

If you're taking care of a bug, mark it as 'assigned' to you. By default, bugs are assigned to the dummy 'Nobody' user, which means that they need someone to take care of them.

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

Blocks/depends relationships

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.

Notice that certain important bugs have aliases so you don't need to remember their bug ids. In particular see the section about tracking bugs. For example, to mark a bug as blocking the 3.0 release, just enter 3.0.

Notice that for each bug you can view its dependency tree and graph.

Duplicates

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.

Email notification

Email notification works by "watching" other users. Just by watching the 'Nobody' user, which is the default assignee for new bugs, you'll get notified of almost all new bugs.