Driving towards Bugzilla 3

Matty mattyt at tpg.com.au
Sat Dec 11 12:08:14 UTC 2004


On Tue, 2004-12-07 at 22:22 +0200, Vlad Dascalu wrote:

> Currently there is no plan for 3.0, no roadmap and no schedule, no 
> features and no steps planned in getting there. While sometimes this is 
> suitable, especially when dealing with volunteers, I think this is not 
> the case here; we should focus in the long-term goals of the Bugzilla 
> development process.

Custom fields was the most important feature of 3.0, and would be a
requirement in my books, although it wouldn't have to dictate a switch,
but it's probably likely custom fields will appear a bit at a time
anyway so it's still a good question.

To me 3.0 would be more of a breaking-with-the-past release, where we'd
possibly drop some kinds of backward compatibility.

The obvious thing to drop would be the checksetup schema massaging,
where we could say you need to upgrade 2.X->2.last->3.0->3.X or some
such as 3.X wouldn't need to worry about upgrading 2.X installations.

I would presume we would not want to ever break CGI compatibility, so
that's not an issue.  And APIs are broken as often as people eat
breakfast nowadays, so that's not an issue either.

So, how about we agree that 3.X is when we have the following features:

- basic custom bug fields (numeric, text, url, enumeration, account,
allocation, relationship)
- extensible custom fields, where you can insert a module to define a
new field type, for bugs, users, accounts
- all fields can be specified as global, product specific, etc
- custom resolutions/statuses
- full support for transactions, referential constraints
- complete separation of all reusable code such as
bug/account/attachment processing, checksetup, reports etc and
exhaustive testing suites for all this functionality
- all pages converted to XHTML doctype
- support for mod_perl
- support all standard authentication methods, and a few non-standard
ones as well
- email interfaces and bugmail available as XHTML, XML, XUL, IM and SMS
- GPG support on all emails
- support for every database in existence
- threaded reply support on every bug
- full integration between installations, including but not limited to,
comment reference linkifying, dependencies, duplicate marking to other
installations, shared accounts/preferences across installations,
cross-installation reporting, etc
- new "really-simple" query format that just asks the question "Huh?"
- AI for automatically finding and kicking to the kurb any dupes, test
bugs and otherwise misplaced bugs
- Klingon language packs
- electro shock therapy functionality for slack reviewers, with easy to
use XHTML configuration interface, neatly integrated into the rest of
the administration functionality
- auto update functionality by default so we're not bothered by pesky
administrators submitting bugs reports in versions of Bugzilla from 10
years ago
- out of the box support for M68K, Amigas, Playstations and C64s
- Bayesian AI for scanning comments and automatically nuking obnoxious
users from orbit
- ability to expand our base of input by piggy backing the voting system
on existing national electoral and referendum systems
- Trusted Computing support preventing administrators from making
changes to code without first receiving a "Certificate of Apparent
Competence" from the project leader (or blessed delegate).
- extend the whining system so it actively hunts down non-Bugzilla
tracking systems and send their administrators reminder emails about how
Bugzilla will make their penis longer
- when there are no known bugs left

I think this is reasonable starting point for a set of hard requirements
for Bugzilla 3.0.  When this is complete we can discuss this again.

OK?





More information about the developers mailing list