in my last post i stated that we fixed over 900 bugs since designer 2.0m2. after posting i realized that i probably painted an inaccurate picture of what 2.0m2 was and what the overall product quality was. at least for people who are not familiar with the way we use bugs to manage the designer project it may be difficult to correctly interpret my statement. designer is high quality, extremely customer focused and constantly evolving.
most of novell engineering uses bugzilla as a development process, problem and enhancement tracking tool. bugzilla holds records – referred to as bugs – that are assigned to a responsible person and categorized into products and feature areas per product. each of these records (or bugs) has a severity and a priority assigned. the severity is set by the reporting party and is meant to indicate how important the record is where as the priority is assigned internally and determines the attention (importance) the record gets.
the severity field divides the records into two different groups: problems and enhancement requests. if a record’s severity is set to “enhancement” it describes a non-existing but desired functionality. all other levels assume a problem and indicate the importance of the problem.
now what makes the difference between an enhancement request and a bug? at first this seams obvious but very often it is not: designer does not currently provide any team enablement features like version control. a record (bug?) which asks for team enablement and version control would thus be given a severity of “enhancement”. if designer during a deploy was going to destroy data, a record (bug?) reporting this issue would probably be assigned a severity level of “major” or “critical”. but there is a lot of space between these two examples. imagine designer behaves in a way that is unexpected (wrong?) for you. if you reported this and requested a change of behavior would that be an enhancement request or a problem report? difficult to say.
we in the designer team use bugs for release planning, too. whoever has an idea enters a bug. often the severity level doesn’t even matters. then, when we get loaded to do our next milstone, we pull up all the open bugs and prioritize them. this way we make sure no idea is being forgotten. you as a customer can do the same. our bugzilla system is open for you. you have an idea or a problem? go to bugzilla.novell.com and tell us about it.
back to my original post: over 900 bug fixes does not mean we had 900 critical problems we fixed. it means that we worked down a queue of over 900 records in our bugzilla database who describe our current release. from the over 900 bugs approx. 110 were marked as enhancement requests right away. this leaves us with over 790 records. most of these are bugs reported by our internal test team. they try every day to break our code and report every success they have. this way we make sure what we ship is of shipping quality. so 2.0m2 was not a milestone that had over 900 problems, but 1.2 (2.0m3) is a release with loads of new features and many, many adoptions requested by you and many, many, many problems fixed before they even were able to hit you, the customer, because they were found by our internal test team.