diff options
Diffstat (limited to 'docs/sgml')
| -rw-r--r-- | docs/sgml/Bugzilla-Guide.sgml | 3 | ||||
| -rw-r--r-- | docs/sgml/future.sgml | 619 |
2 files changed, 0 insertions, 622 deletions
diff --git a/docs/sgml/Bugzilla-Guide.sgml b/docs/sgml/Bugzilla-Guide.sgml index 0f5817221..2ee495eff 100644 --- a/docs/sgml/Bugzilla-Guide.sgml +++ b/docs/sgml/Bugzilla-Guide.sgml @@ -193,9 +193,6 @@ try to avoid clutter and feel free to waste space in the code to make it more re <!-- Integrating Bugzilla with Third-Party Tools --> &integration; -<!-- The Future of Bugzilla --> -&future; - <!-- Major Bugzilla Variants --> &variants; diff --git a/docs/sgml/future.sgml b/docs/sgml/future.sgml deleted file mode 100644 index 242418be0..000000000 --- a/docs/sgml/future.sgml +++ /dev/null @@ -1,619 +0,0 @@ -<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN" > --> - -<chapter id="future"> - <title>The Future of Bugzilla</title> - <synopsis>Bugzilla's Future. Much of this is the present, now.</synopsis> - <para> - Bugzilla's future is a constantly-changing thing, as various developers - <quote>scratch an itch</quote> when it comes to functionality. - Thus this section is very malleable, subject to change without notice, etc. - You'll probably also notice the lack of formatting. I apologize that it's - not quite as readable as the rest of the Guide. - </para> - <para> - <literallayout> - Bugzilla Blue Sky - -Customisability - - One of the major stumbling blocks of Bugzilla has been that it is too - rigid and does not adapt itself well enough to the needs of an - organisation. This has led to organisations making changes to the - Bugzilla code that need to be redone each new version of Bugzilla. - Bugzilla should attempt to move away from this to a world where this - doesn't need to occur. - - Most of the subsections in this section are currently explicit design - goals for the "Bugzilla 3" rewrite. This does not necessarily mean - that they will not occur before them in Bugzilla 2, but most are - significant undertakings. - - Field Customisation - - Many installations wish to customise the fields that appear on bug - reports. Current versions of Bugzilla offer limited - customisability. In particular, some fields can be turned off. - - However, many administrators wish to add their own fields, and rename - or otherwise modify existing fields. An architecture that supports - this would be extraordinarily useful. - - Indeed, many fields work similarly and could be abstracted into "field - types", so that an administrator need write little or no code to - support the new fields they desire. - - Possible field types include text (eg status whiteboard), numbers, - dates (eg report time), accounts (eg reporter, qa, cc), inter-bug - relationships (dependencies, duplicates), option groups (platform, os, - severity, priority, target milestone, version) etc. - - Ideally an administrator could configure their fields through a - Bugzilla interface that requires no code to be added. However, it is - highly unlikely this ideal will never be met, and in a similar way - that office applications have scripting languages, Bugzilla should - allow new field types to be written. - - Similarly, a common desire is for resolutions to be added or removed. - - Allocations - - ? - - Option Groups - - ? - - Relations - - ? - - Database Integrity - - Furthermore, it is desirable for administrators to be able to specify - rules that must or should apply between the fields on a bug report. - - For example, you might wish to specify that a bug with status ASSIGNED - must have a target milestone field that that is not untargetted. Or - that a bug with a certain number of votes should get ASSIGNED. Or - that the QA contact must be different from the assignee. - - "Must" relationships could be implemented by refusing to make changes - that violate the relationships, or alternatively, automatically - updating certain fields in order to satisfy the criteria. Which - occurs should be up to the administrator. - - "Should" relationships could be implemented by a combination of - emitting warnings on the process bug page, the same on notification - mails, or emitting periodic whine mails about the situation. Again, - which occurs should be up to the administrator. - - It should also be possible for whine mails to be emitted for "must" - relationships, as they might become violated through direct database - access, Bugzilla bugs, or because they were there before the - relationship was enforced. - - As well as implementing intra-bug constraints, it would be useful to - create inter-bug constraints. For example, a bug that is dependent on - another bug should not have an earlier milestone or greater priority - than that bug. - - Database Adaptability - - Often an administrator desires that fields adapt to the values of - other fields. For example, the value of a field might determine the - possible values of another field or even whether it appears (whether - it is "applicable"). - - Limited adaptability is present in Bugzilla 2, and only on the - "Product" field: - * The possible values of the target milestone, version and component - fields depend on the product. - * UNCONFIRMED can be turned off for specific products. - * Voting can be configured differently or turned off for different - products, and there is a separate user vote limits for each - product. - - It would be good if more adaptability was present, both in terms of - all fields relying on the product, as well as the ability to adapt - based on the value of all fields. - - Example ??? - - General adaptability raises the issue of circular references between - fields causing problems. One possible solution to this is to place - the fields in a total ordering and require a field refer only to the - previous fields. - - In Bugzilla 2, changing the product of a bug meant a second page would - appear that allowed you to choose a new milestone, component and - version, as those fields adapted themselves to the new product. This - page could be generalised to support all instances where: - * a field value must or might be changed because the possible values - have changed - * is going to drop off because it it is no longer applicable, and - this should be confirmed - * must be specified because it is suddenly applicable, and the - default value, if one exists, might not be acceptable - - Database Independence - - Currently Bugzilla only runs on the MySQL database. It would be - desirable for Bugzilla to run on other databases, because: - * Organisations may have existing database products they use and - would prefer to run a homogenous environment. - * Databases each have their own shortcomings, including MySQL. An - administrator might choose a database that would work better with - their Bugzilla. - - This raises the possibility that we could use features that are only - present in some databases, by appropriately falling back. For - example, in the MySQL world, we live without: - * record-level locking, instead we use table-level locking - * referential and record constraints, instead we checking code - * subselects, instead we use multiple queries and redundant "caches" - - Multiple Front Ends - - Currently Bugzilla is manipulated via the Web, and notifies via - E-Mail. It would be desirable for Bugzilla to easily support various - front ends. - - There is no reason that Bugzilla could not be controlled via a whole - range of front ends, including Web, E-Mail, IRC, ICQ, etc, and - similarly for how it notifies. It's also possible that we could - introduce a special Bugzilla client that uses its own protocol, for - maximum user productivity. - - Indeed a request reply might be returned via a totally different - transport method than was use to submit the request. - -Internationalisation - - Bugzilla currently supports only English. All of the field names, - user instructions, etc are written in English. It would be desirable - to allow "language packs" so Bugzilla can be easily used in - non-English speaking locales. - - To a degree field customisation supports this, because administrators - could specify their own fields names anyway. However, there will - always be some basic facilities not covered by this, and it is - desirable that the administrator's interface also is - internationalisable. - -Better Searching - - General Summary Reports - - Sometimes, the normal querying page leaves a lot to be desired. There - are other facilities already in place or which people have asked for: - - Most Doomed Reports - All Bugs or All Bugs In A Product, Categorised - On Assignee, Shows and Counts Number of Bugs For Each Assignee - Most Voted For Bugs - All Bugs, Categorised On Product, Shows Top Ten - Bugs Voters Most Want Fixed - Number of Open Bugs For An Assignee - Bug List, Categorised On - Developers, Counts Number of Bugs In Category - - The important thing to realise is that people want categorised reports - on all sorts of things - a general summary report. - - In a categorised report, you choose the subset of bugs you wish to - operate on (similar to how you would specify a query), and then - categorise them on one or more fields. - - For each category you display the count of the number of things in - that category. You can optionally display the bugs themselves, or - leave them out, just showing the counts. And you can optionally limit - the number of things (bugs or subcategories) that display in each - category. - - Such a mechanism would let you do all of the above and more. - Applications of this mechanism would only be recognised once it was - implemented. - - Related Bugs - - It would be nice to have a field where you could enter other bugs - related to the current bug. It would be handy for navigation and - possibly even finding duplicates. - - Column Specification Support - - Currently bug lists use the columns that you last used. This doesn't - work well for "prepackaged queries", where you followed a link. You - can probably add a column by specifying a sort column, but this is - difficult and suboptimal. - - Furthermore, I find that when I want to add a column to a bug list, - it's usually a one off and I would prefer it to go away for the next - query. Hence, it would be nice to specify the columns that appear on - the bug list (and general summary report) pages. The default query - mechanism should be able to let you specify your default columns. - - Advanced Querying Redesign - - ? - -Keywords - - People have a need to apply tags to bugs. In the beginning, people - placed designators in the summary and status whiteboard. However, - these fields were not designed for that, and so there were many flaws - with this system: - * They pollute the field with information that was never intended to - be present. - * Removing them with a bulk change is a difficult problem that has - too many pitfalls to implement. - * You can easily get the capitalisation wrong. - - Then dependencies were introduced (when?), and people realised that - they could use them for "tracking bugs". Again, dependencies were not - designed for that, and so there were more flaws, albeit different - ones, including: - * They aren't really bugs, so it's difficult to distinguish issues - from bugs. - * They can pollute bugs counts, and you must somehow exclude them - from queries. - * There is a whole lot of useless information on them. They have an - assignee but there is nothing to fix, and that person can get - whined at by Bugzilla. They have target milestones which must be - manually maintained. And so on. - - Finally, keywords were introduced (when?) for this purpose to remove - the need for these two systems. Unfortunately, the simple keywords - implementation was itself lacking in certain features provided by the - two previous systems, and has remained almost unchanged since its - inception. Furthermore, it could not be forseen that in large - installations, the sheer number of keywords could become unwieldly and - could lead to a movement back to the other systems. - - The keywords system was the right idea, however, and it remains so. - Fixing the keywords system is one of the most important Bugzilla - issues. - - Bringing Keywords Up To Par - - For the most part, keywords are very good at what they do. It is easy - to add and remove them (unlike summary/whiteboard designators), we can - simply see what issues are present on a bug (unlike tracking bugs), - and we do not confuse bugs with issues (unlike tracking bugs). - - However, there are still some "regressions" in the keyword system over - previous systems: - * Users wish to view the "dependency forest" of a keyword. While a - dependency tree is of one bug, a dependency forest is of a bug - list, and consists of a dependency tree for each member of the bug - list. Users can work around this with tracking bugs by creating a - tracking bug and viewing the dependency tree of that tracking bug. - * Users wish to specify the keywords that initially apply to a bug, - but instead they must edit the bug once it has already been - submitted. They can work around this with summary designators, - since they specify the summary at reporting time. - * Users wish to store or share a bug list that contains a keywords - column. Hence they wish to be able to specify what columns appear - in the bug list URL, as mentioned earlier. They can work around - this using summary designators, since almost all bug lists have a - summary column. - * Users wish to be able to view keywords on a bug list. However - often they are only interested in a small number of keywords. - Having a bug list with a keywords column means that all keywords - will appear on a bug list. This can take a substantial amount of - space where a bug has a lot of keywords, since the table columns - in Bugzilla adjust to the largest cell in that column. Hence - users wish to be able to specify which keywords should appear in - the bug list. In a very real sense, each keyword is a field unto - itself. Users can work around this by using summary designators, - since they keywords will share the space in the summary column. - * Users wish to know when bugs with a specific issue are resolved. - Hence they wish to be able to receive notifications on all the - bugs with a specific keyword. The introduction a generic watching - facility (also for things like watching all bugs in a component) - would achieve this. Users can work around this by using tracking - bugs, as dependencies have an existing way of detecting fixes to - bug a bug was blocked by. - - Dealing With The Keyword Overload - - At the time of writing, the mozilla.org installation has approximately - 100 keywords, and many more would be in use if the keywords system - didn't have the problems it does. - - Such a large number of keywords introduces logistical problems: - * It must be easy for someone to learn what a keyword means. If a - keyword is buried within a lot of other keywords, it can be - difficult to find. - * It must be easy to see what keywords are on a bug. If the number - of keywords is large, then this can be difficult. - - These lead some people to feel that there are "too many keywords". - - These problems are not without solutions however. It is harder to - find a list of designators or tracking bugs than it is a list of - keywords. - - The essential problem is it needs to be easy to find the keywords - we're interested in through the mass of keywords. - - Keyword Applicability - - As has been previously mentioned, it is desirable for fields to be - able to adapt to the values of other fields. This is certainly true - for keywords. Many keywords are simply not relevant because of the - bugs product, component, etc. - - Hence, by introducing keyword applicability, and not displaying - keywords that are not relevant to the current bug, or clearly - separating them, we can make the keyword overload problem less - significant. - - Currently when you click on "keywords" on a bug, you get a list of all - bugs. It would be desirable to introduce a list of keywords tailored - to a specific bug, that reports, in order: - * the keywords currently on the bug - * the keywords not currently on the bug, but applicable to the bug - * optionally, the keywords not applicable to the bug - - This essentially orders the keywords into three groups, where each - group is more important than the previous, and therefore appears - closer to the top. - - Keyword Grouping & Ordering - - We could further enhance both the global and bug specific keyword list - by grouping keywords. We should always have a "flat" view of - keywords, but other ways of viewing the keywords would be useful too. - - If keyword applicability was implemented, we could group keywords - based on their "applicability condition". Keywords that apply to all - bugs could be separated from keywords that apply to a specific - product, both on the global keyword list and the keyword list of a bug - that is in that product. - - We could specify groups of our own. For example, many keywords are in - a mutually exclusive group, essentially like radio buttons in a user - interface. This creates a natural grouping, although other groupings - occur (which depends on your keywords). - - It is possible that we could use collapsing/expanding operations on - "twisties" to only should the groups we are interested in. - - And instead of grouping keywords, we could order them on some metric - of usefulness, such as: - * when the keyword was last added to a bug - * how many bugs the keyword is on - * how many open bugs the keyword is on - - Opting Out Of Keywords - - Not all people are going to care about all keywords. Therefore it - makes sense that you may wish to specify which keywords you are - interested in, either on the bug page, or on notifications. - - Other keywords will therefore not bother users who are not interested - in them. - - Keyword Security - - Currently all keywords are available and editable to all people with - edit bugs access. This situation is clearly suboptimal. - - Although relying on good behaviour for people to not do what they - shouldn't works reasonably well on the mozilla.org, it is better to - enforce that behaviour - it can be breached through malice, accident - or ignorance. - - And in the situation where it is desirable for the presence or absence - of a keyword not to be revealed, organisations either need to be - content with the divulgence, or not use keywords at all. - - In the situation where they choose to divulge, introducing the ability - to restrict who can see the keyword would also reduce keyword - overload. - - Personal Keywords - - Keywords join together a set of bugs which would otherwise be - unrelated in the bug system. - - We allow users to store their own queries. However we don't allow - them to store their own keywords on a bug. This reduces the - usefulness of personal queries, since you cannot join a set of - unrelated bugs together in a way that you wish. Lists of bug numbers - can work, by they can only be used for small lists, and it is - impossible to share a list between multiple queries. - - Personal keywords are necessary to replace personal tracking bugs, as - they would not pollute the keyword space. Indeed, on many - installations this could remove some keywords out of the global - keyword space. - - In a similar vein and with similar effects, group keywords could be - introduced that are only available to members of a specific group. - - Keyword Restrictions - - Keywords are not islands unto themselves. Along with their potential - to be involved in the inter-field relationships mentioned earlier, - keywords can also be related to other keywords. - - Essentially, there are two possibilities: - * a set of keywords are mutually exclusive - * the presence of a keyword implies another keyword must be present - - Introduction of the ability to specify these restrictions would have - benefits. - - If mutually exclusive keywords were present on a bug, their removal - would fix up the database, as well as reducing the number of keywords - on that bug. - - In the situation where a keyword implies another keyword, there are - two possiblities as to how to handle the situation. - - The first is automatically add the keyword. This would fix up the - database, but it would increase the number of keywords on a bug. - - The second is to automatically remove the keyword, and alter queries - so they pick up the first keyword as well as the removed keyword. - This would fix up the database and reduce the number of keywords on a - bug, but it might confuse users who don't see the keyword. - Alternatively, the implied keywords could be listed separately. - -Notifications - - Every time a bug gets changed notifications get sent out to people - letting them know about what changes have been made. This is a - significant feature, and all sorts of questions can be raised, but - they mainly boil down to when they should be sent and what they should - look like. - - Changes You're Interested In - - As of version 2.12 users can specify what sort of changes they are - interested in receiving notifications for. However, this is still - limited. As yet there is no facility to specify which keywords you - care about, and whether you care about changes to fields such as the - QA contact changes. - Furthermore, often an unnecessary comment will go along with a change, - either because it is required, or the commenter is ignorant of how the - new system works. While explaining why you did something is useful, - merely commenting on what you did is not because that information is - already accessible view "Bug Activity". - - Because of this unnecessary comment, a lot of changes that would - otherwise not generate notifications for certain people do so, because - few people are willing to turn off comments. One way to deal with - this problem is to allow people to specify that their comments are - purely explanatory, and that anyone who is not interested in the - change will not be interested in the comment. - - Furthermore, one possible rationale for unnecessary comments is that - the bug activity does not display on the normal page and hence it is - difficult to cross reference comments and actions. Hence, it would be - beneficial to be able to do this. - - Bugs You're Watching - - Currently to receive a notification about a bug you need to have your - name on it. This is suboptimal because you need to know about a bug - before you can receive notifications on it. Often you are interested - in any bug with a field set to a specific value. For example, you - might be interested in all bugs with a specific product, component or - keyword. - - If someone could automatically receive notifications about these bugs, - it would make everyone's lives easier. Currently the default assignee - and QA contact for a component will automatically receive - notifications for - - Question: This moves half way to a BCC. - - Bulk Changes - - A very useful feature of Bugzilla is the ability to perform an action - on multiple bugs at once. However, this means that similar - notifications are currently generated for each bug modified. - - This can result in a torrent of notifications that can annoy. - - Furthermore, since the bugs are all changed close to each other in - time, it is easy for someone to mass delete all the notifications - generated by a bulk change and miss an unrelated notification in the - middle. - - These factors can lead to a tendency for people to delay bulk changes, - or avoid them entirely. This is suboptimal. - - It would be better if a bulk change generated only one notification - mail. This would vastly reduce the annoyance factor, and prevent - accidental deletion of notifications. - - One problem with this change is that some people separate out - notifications using filtering. This means that they would no longer - be match parts of a bulk change under different filtering rules. - - One possibility to resolve this is to allow people to specify groups - of bugs. All bugs within a group would go into the same - notification. The filters could then distinguish the different bug - groups. - - In any case, it is likely there would need to be a transition period - to allow people to alter their filters. - -Nominations - - ? - -Linking Bugzilla Installations - - The first example of linking Bugzilla installations together has is - the introduction of bug moving in version 2.12. However, it would be - useful to be able to link installations in more ways. - * Dependencies and other relationships between bugs in other - installations. This is difficult because dependencies are - synchronised on both bugs, so the installation that changes - dependencies would need to communicate the new state to the other - installation. It would also mean that relationships and - notifications that refer to other bugs would need to communicate - with the other installation. - * References to bugs in other installations. Currently if you type - "bug XXX" or "bug #XXX" where XXX is a number, you get an - automatic hyperlink to that bug. It would be useful if you could - say "YYY bug #XXX" where YYY is the name of another installation. - -Retirement - - ? - -Whiny Reports - - ? - - Group Redesign - - ? - - Hard Wrapping Comments - - Currently Bugzilla "hard wraps" its comments to a specific line size, - similar to E-Mail. This has various problems: - * The way it currently works, wrapping is done in the browser at - submission time using a non-standard HTML extension not supported - by some (uncommon) browsers. These browsers generate comments - that scroll off the right side of the screen. - * Because comments are of fixed width, when you expand your browser - window, the comments do not expand to fit available space. - - It would be much better to move to a world of soft wrapping, where the - browser wraps the text at display time, similar to a world processor. - And as in a word processor, soft wrapping does not preclude the - insertion of newlines. - - Hard wrapping is too entrenched into text E-Mail to fix, but we can - fix Bugzilla without causing any problems. The old content will still - be wrapped too early, but at least new content will work. - </literallayout> - </para> -</chapter> - -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-always-quote-attributes:t -sgml-auto-insert-required-elements:t -sgml-balanced-tag-edit:t -sgml-exposed-tags:nil -sgml-general-insert-case:lower -sgml-indent-data:t -sgml-indent-step:2 -sgml-local-catalogs:nil -sgml-local-ecat-files:nil -sgml-minimize-attributes:nil -sgml-namecase-general:t -sgml-omittag:t -sgml-parent-document:("Bugzilla-Guide.sgml" "book" "chapter") -sgml-shorttag:t -sgml-tag-region-if-active:t -End: ---> - |