Hi James, > This was also stated in what I said. If the problem is NOT a regression, then > we recategorize the problem. If it truely is a regression, then the category > should remain regression and the triage process is applied as to the impact > of the regression and is it a 'show stopper' problem.
Not sure if we're on the same track here. I am not sure whether the line can always be drawn exactly, but I think a intentional change should not be a "regression" in IZ. However, perhaps keeping the regression keyword for category-1 issues (intentional changes claimed to be bad) isn't really a problem. The intention behind the whole proposal is to clearly separate "regression" from "blocker", since people tend to think the former implies the latter, which isn't the case. If we separate the two, then "regression" loses some of its importance. In this case, it would perhaps not hurt to have "regression" for all 3 classes. Do others have opinions here? >>Of course discussing a change before actually doing it is better. This >>alrady happens a lot (read [email protected] to be >>up-to-date with what is planned to be changed, and join the respective >>discussions.). > > Ok. I can do this. This is not really the best-known channel in OOo, but in theory, every change should beforehand be announced there, with room for discussions. Perhaps we should more spread the word about this. > As a real world software tester, I can state that if issues are marked > "fix later" they don't get fixed. If you place a target version on the > problem, it gets looked at and considered. Not every problem targeted > for a certain version will get fixed in that version. I realize this and we > can always retarget a problem to a later version (and this happens all > the time with OpenOffice.org.) Well, I hope that at the moment the targeting happens, the problem is looked at and considered. At this point in time, I'd consider it valid to say that the issue, though it describes a regression, is for "Later". Yes, effectively this means that the problem is fixed <whenever>, but in this respect, I don't think it's necessary/justified to handle regression issues different than other issues. > This is true for all software. There are more problems found than can > be fixed for a given release. Can all of them be fixed? No. However, > you set a goal and try to make it. If I pick up an issue, I try to at least > discover where it the system is broken and identify it. This makes it easier > for the developers to fix it. But the workflow usually is different. Usually, an issue is examined for severity, long before it's examined for the place where the system is broken. That is, it's up to impossible to look into every issue, and then decide whether a quick fix can be applied for one of the next releases, even if the issue's severity would not justify it. In fact, history has proven (for this very particular product OpenOffice.org) that this attitude - fix a lot of small issues - does not really make the product any better, it just usually introduces new regressions. Thus, currently the rule (which I'd think is reasonable) to mainly judge an issue for severity, and not for "easiness to fix". (though this doesn't hinder individual developers to grab and fix an issue which they consider easy.) >>If we would have a "blocker" keyword, both problems would vanish: Wrong >>retargeting would be less probable, and finding those wrongly retargeted >>issues would be a matter of a simple query. > > Yes. However, where is this going to go? Sorry, I don't get you here ...? > Yes, this is true. This is why we have triage teams. A user can state, "I > cannot > use OpenOffice.org because of this problem" but in the big picture this is > the only > user affected. Would you expend a large amount of effort to fix the problem? > No. > However, if 100 users were affected or a large installation of OpenOffice.org > were, > you would fix the problem quickly. Yes. >>We should establish a policy that "release_blocker" is to be set by >>certain (class of) users only, but we cannot technically enforce it. >>However, I don't consider this a real problem: We would use queries for >>all "release_blocker" issues on a regular basis, and here (at the >>latest), it would be noticed if somebody wrongly set that keyword. > > Ok. I know that policies are difficult to enforce when the underlying > software cannot support them. However, this does not stop the triage > team from correcting improperly prioritized issues. Yes, and I hope that it will continue to do, as it did in the past. Finally, the problem we get here is not new: There have been cases in the past where people set the target milestone to whatever they thought they want to have the fix in. This is against the policy, too, but it wasn't a real problem to the community, since those cases were corrected quickly. I expect the same - both the misuse and the correction - to happen with the release_blocker keyword. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
