Bugzilla:Roadmap

Bugzilla Roadmap

Introduction

The trunk will be open for development again in the coming days, and for the next 6 months, we will again accept bug fixes, enhancements, new features and risky code changes. But 6 months is a short period and if we want something to be done on time when we freeze again on Sept 15, 2006 for the release of Bugzilla 2.24 (maybe the last release of the 2.x serie), some coordination is required.

This roadmap below is an attempt to outline what the objectives of the core Bugzilla team are for 2.24. We will probably be late and we will probably be too optimistic, but this will give enough work to everyone who wants to contribute.

A very important note is that both the User Interface (UI) and the code need some cleanup, and so even if you are not familiar with Bugzilla in general or with Perl in particular, there is still enough work for you here.

So why this roadmap?

Well, to quickly summarize the main reasons, we could say:

• There is nothing more frustrating than working on a patch which will get no attention and will remain in the review queue for months, if not for years. Having clear objectives about what we want in the coming months will permit us to avoid such unfortunate situations. If we want something, we won't let it in the queue for months.
• Everyone is busy, but everyone wants to see things being done, and if possible as quickly as possible. We all know that, and maybe you are one of them. Having clear objectives will make our work more efficient, as we know where the few free hours we have for writing patches will be useful. This is very close from the previous point, except we mention here how to use our so precious free time efficiently.
• Having deadlines and assigned developers will also offer a better coordination between developers. Working on some fields which conflict with someone else work is again a waste of time, and having to unbitrot patches may be as long as writing the patch for the first time. Also, having an assigned developer per field should help in getting the work done, especially if this developer is a reviewer too. Indeed, assigned doesn't mean that he has to do the job alone, but that he is the person to contact when someone is interested in helping. He will be able to say what has to be done left, and where we are in the process.

The Roadmap

Note

This list is subject to change at any time, depending on progress we will made and on people working on the different fields.

Our priorities

Here is what you were waiting for. Objectives described in the table are not ordered by priority as some of them may be relatively independent.

Task	Related Bugs	Estimated deadline	Assigned developer	Requirements
Removing versioncache	Bug 110503	April, 2006	mkanat	none
Removing deprecated SQL routines (SendSQL, SqlQuote, ...)	Bug 278017	May, 2006	mkanat	none
Removing globals.pl	Bug 87411	June, 2006	mkanat	Removing versioncache