Danny, > > > I have just added 2.1a1 as a version. > > > > -1. Please revert this. > > > > This is something I didn't request. > > Perhaps not, but everything is not up to you alone.
Of course not, but as I'm the one who made the original Bugzilla request, I think the content of that request is significant. There's a tacit acceptance of the situation in request. I wanted to express that I did not request this situation. Others are free to disagree. > > Alphas, betas, and release candidates > > should not be specified as part of the major version number in a > > bug system. > > Says whom? and why? if rc's are released in order for testing it makes > perfect sense to include them in the bug system. Absolutely, include the alpha, beta, and release candidate. Just do it separately from the major version. It's precisely this confusion on version numbers that led to the recent discussion where it was seriously proposed that our final gold release be labeled 2.1.1. We can't even seem to figure out whether third digits in version #s should be used for rcs or not. Indicates a bit of confusion IMHO. And I say. This is my opinion, both as an active committer on this project and as a software professional. You are welcome to dissent. You are even welcome to veto. But I'm certainly not going to feel constrained in expressing my opinion. As to why, that's explained both in the previous emails and in this one. > I don't know where you've worked but ever release I've participated in, on > whichever side of the fence, has had alpha beta and rc's in the bug system > because the versions change quickly and so we can know which version the > tester was using. Well, among other jobs, I managed the Continuing Engineering department for an enterprise security product with three APIs and approximately thirty different product components (three servers, three web server agents, two app server agents, five platforms with mixed coverage). In my time in that role I and my team handled several hundred bug reports (some valid, some not), often from clients requiring fixes in hours/days. We issued 40+ patches on a variety of versions/components and produced four or five roll-up bug fix releases. I used Bugzilla constantly, both I worked closely with release management throughout my time in that role, coordinating version numbers on those patches. I also worked with core engineering to help them integrate pre-release bug tracking and testing with the bug system. So I feel I've got some relevant experience. As I made clear in my previous email, I've got no objection to recording alpha, beta, and rc data in the bug system. I think it's valuable. But preserving the ability to simply query and organize bugs by major version dictates that the two be kept apart. It also simplifies milestone, alpha, and beta release since by using a product of several fields ( major version (2.1, 3.0) * minor version (a1, a2, a3, a4, a5, b1, b2, b3, b4, b5, rc1, rc2, rc3, rc4, rc5, 0, 1, 2, 3, 4, 5)) it no longer becomes necessary to alter the bug system everytime an alpha, beta, or milestone is released. > > Aside from simply increasing the number of values for an important field > > (hence making searches/categorization more onerous), it doesn't serve > any > > useful purpose. > > It serves to allow develoeprs to identify the codebase in which the bug > has > been identified, surely. Uh, no it doesn't. Does 2.1a1 refer to the code in July (pre-FetchPOP) or in late August (post-FetchPOP)? Who knows? No one does. Why? Because there has been no effective labeling/tracking of said versions. We released two milestone builds and i) didn't label them correctly and ii) didn't even update the web site to refer correctly to the release candidate. I'd say the release management needs a little work. And part of that work is separating major versions from minor versions. > > > Do we want to add 2.1 and 3.0 before they are released? It could make > > > life confusing for bug reporters and for us. > > > I suggest we add new versions to Bugzilla as part of the release > cycle. > > Yes 2.1 and 3.0 > > and 3.0 as a milestone. it is also IMO reasonable to have point versions > specified in milestones too. What milestone? You have no idea at this point what milestones, alphas, and betas are going to be released for 3.0. All you know is that we are going to be working towards a 3.0 version. How do you handle bugs in features that are introduced after one version and fixed before the next? Again, not in 2.1a1, not in 2.1a2. But it is in 2.1, because that's a global container for the process. One of the big problems with 2.1 bug tracking was the introduction of a 2.1a1 build.xml label essentially instantaneously after 2.0a3. This is an error. It meant that 2.1a1-cvs was a catch-all for anything that's been found in the last several months. It gives the illusion of specificity, while giving nothing of the kind. > > Right now the bug system is effectively useless for accurately recording > > James bugs. > > A bit of unneccessary hyperbole there I think. Not really. How many bugs were fixed in 2.1? How many of those bugs were recorded in Bugzilla? Maybe 10%? Tops. Doesn't sound very useful to me. Part of this is cultural, but a lot of it is that the bug system is confusing and lacks fields that describe the current situation. > > Ask yourself the following question. How would I have recorded a > > bug found > > in FetchPOP in September? Version unspecified? Not very useful. > Version > > 2.0a3? This feature wasn't even present in that version. The correct > > answer was (and should've been) 2.1, > > Or even 2.1a1 to give us even more precision, by your standards it may > have > been fixed by chance in 2.1rc1, and you'd have no way of telling. And this is precisely the error I'm trying to avoid. There is no such animal as 2.1a1. Point to the CVS tag for 2.1a1. Tell me exactly which files go in the source. You can't. It doesn't exist. It is an erroneous artifact of bad build management. How do you tell? Specify the bug is in 2.1. It would be nice if we had a fixed in field (as per the suggestion in my last email) but we don't. That would make things trivial. But let's assume we have the current situation. Before release, there is a review of open bugs. Bugs that are being fixed for the particular release will be fixed, tested, and closed before that release goes gold. They will be marked with a date/time stamp and the (now-known) next alpha, beta, rc, or minor version in the comments. Bugs that are not fixed will be left open, making it clear that they haven't been fixed with an appropriate comment indicating they were reviewed and passed over. Done. Now it's exactly clear (and recorded) what bugs are fixed when. It's clear what version the bugs were found in, as well as what version they were resolved in. Aaron's recent comments on release management, while a bit strong, are most well taken. A conversation on proper version/release control is probably in order shortly. The conclusions of such a discussion should be recorded for future reference, so conversations like this and the earlier version number discussion become unnecessary. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
