Driving towards Bugzilla 3
vladd at bugzilla.org
Tue Dec 7 20:22:26 UTC 2004
The story with Bugzilla 3 is as it follows: Ian wanted it to be a
rewrite; he dropped the ball some time ago; the rewrite got canceled, so
currently Bugzilla 3 is considered something that will magically happen
when Dave decides to rename 2.xx to 3.0.
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
(While we're having some difficulties with the short term plans, like
2.24 and so, I think we can reasonable manage those, since we have some
left-overs like templatization and DB abstraction layer, which I don't
see "done" completely in the following year.)
So the main issue is that when the rewrite idea dropped, the 3.0 idea
dropped as well. Due to the 6 months release cycle, there will be no
other pair of releases with a considerable feature set difference in
them that will be greater than the 2.16 versus 2.18 thing (those covered
2 years of development). Since Dave rejected 2.18 as 3.0, we're back
where we started.
The feature set for 3.0 seemed reasonable ok. The issue is that we kinda
dropped those aims when we dropped the rewrite thing. The question now
is how to make a roadmap that will allow us to have the 3.0 feature set
without doing the 3.0 rewrite thing.
Another issue will be to try to lay out a plan that will include how
many 2.xx we will actually need before getting to the 3.0 feature set.
That sounds like playing at the lottery, but it might be an useful
The bigger picture might be: are we still considering the 3.0 feature
set in the long term, without having to do a rewrite this time? How do
we plan to achieve that with the current code-base? On what steps/bugs
should we focus in order to improve modularity/abstractization layers
needed for the 3.0 goals?
More information about the developers