Design and Architecture Bugzilla 3 is being designed from the ground up using a Perl based technology that has been developed explicitly for the purpose of developing UI agnostic applications. This technology is called PLIF and will soon be available as an open source resource from mozilla.org. PLIF has been developed over the course of the last couple of months by 1 (talented?) developer. PLIF provides the structure necessary to facilitate the development of web, IRC, command line and other applications by combining not only a large collection of useful code, but a model in which to develop these applications. In addition to using PLIF, we will also be using COSES as the template language for providing an environment where the HTML/XUL/text/whatever is completely abstracted from the business logic of the application. We are aware that people often claim that their applications provide this, so we have worked hard to insure that this is a reality. We choose Perl for a few reasons. The first is that the current Bugzilla 2.x developers are primarily interested in Perl for developing web applications. Perl has many advantages over other technologies. It's fast, stable, portable and easy to write. There are other languages such as Python and Java that are also popular and we hope that people will choose to use Bugzilla-3-compatible ideas as the basis for developing their own front end applications. Just because we have chosen Perl does not mean that we are adverse to seeing Bugzilla 3 implemented in multiple different environments, it is just we needed to make a decision and our first decision and priority is Perl. :-) We are not interested at this point in getting into language wars. We chose Perl because it is a widely used technology that has been proven to work in large scale systems. As stated above, we feel that designing a solid foundation will allow anyone to port the UI front end of Bugzilla to any other language. In fact, we are encouraging this. One goal of Bugzilla 3 is to be able to translate from a Bugzilla 2.x schema to a Bugzilla 3 schema. Given this requirement, the functionality within the 2.x schema will remain available in Bugzilla 3's schema. For instance, the Milestone field in Bugzilla will become a generic field called "Milestone" in Bugzilla 3. The only primary differences between the two will be additional features that are required by Bugzilla 3 and a more thought out and normalized database and code design. Features Bugzilla 3's initial goal is to have equal feature functionality to Bugzilla 2.x, because Bugzilla 2.x is the most used issue tracking system for OSS projects. While Bugzilla 2.x is a great step forward from other systems (like GNATS), it is still missing out on a good UI design, code design and database schema design. So, what we have done is start with the concepts in Bugzilla 2.x's database schema and identified areas where it can be improved through better design and additional database normalization. Since we are using a web application framework (PLIF) and back end technology (Perl), we will also kill the code and design problems inherent in Bugzilla with one stone. A major problem with Bugzilla 2.x is that it is implemented in such a fashion that security is not taken into consideration and this has resulted in being a catalyst for high profiles sites being hacked into (including apache.org). The fact of the matter is that Bugzilla was never meant to be used outside of Netscape and the code shows. When Mozilla.org was created, there was a great hurry to provide some sort of issue tracking system for people to use. Bugzilla was available internally at Netscape and there were people at Netscape that knew how to install and use it. To Mozilla.org's credit (and the contributors to the project), Bugzilla has grown quite a bit, the TCL/TK dependencies were removed, the code has been cleaned up quite a bit, bugs have been fixed and features added. The problem is that this has been done on top of a poorly designed base which is not only hard to setup and configure (the first thing you have to do is change the path to the Perl executable in each and every file!), but also hard to customize the look and feel of because much of the look and feel is hard coded in Perl code. It is time to start over with something new that is designed from the ground up to scale to other people's needs. Processes There are some well defined process's within Bugzilla 2.x that we do appreciate. For example, the Anatomy of a Bugs Life is a terrific example of how the whole process of dealing with an issue should work. However, some people do not wish to use this model, and so duplicating these rules within Bugzilla 3 is not a priority. Instead, we instead to make everything customisable and generic. The point we are trying to convey is that we are encouraging the idea of taking the good pieces and dropping the bad. With apologies to the Scarab people [1]. [1] http://scarab.tigris.org/scarab-design.html