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