From kde-core-devel Sun Nov 14 23:08:11 2004 From: Philippe Rigault Date: Sun, 14 Nov 2004 23:08:11 +0000 To: kde-core-devel Subject: Re: Auto-WONTFIX for old UNCONFIRMED wishlist items Message-Id: <200411141808.11859.prigault () oricom ! ca> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110047406612362 Hello KDE core developers, I would like to comment on Stephan's automatic WONTFIX proposal. I fully support cleanup efforts and am willing to help as others, but I think that this proposal has the potential to do more harm than good. I also think WONTFIX is already a bad way of resolving bugs (let alone having an automated system to resolve them in a bad way), and would like to explain why. Please bear in mind that this is the point of view of a (long time) KDE user who, as many do, contributes to it, partly by diligently packaging, testing, filing and analyzing bugs and sending patches whenever possible . I am convinced that there are many people outside KDE core developers that are also willing to help get rid of the clutter, and that sometimes they are in a good, if not better position to make a call about the bug (for example, only they have access to the platform or configuration where the problem is). First, WONTFIX is already is the *worse* resolution for a bug/wish, because it combines irrevocability (WONTFIX = will never be fixed) with subjectivity (I, as a developer, can't fix it, therefore it cannot be fixed by others) and is intrinsically inconsistent (somebody else might fix it in the future, but I decide to bar that option at the time I mark WONTFIX). This resolution is essentially more about one developer's opinion at one point in time, rather than the nature of the bug in itself, and it really means "GOAWAY" to the submitter (a sure way to make him happy to contribute again). I can understand "Won't fix for release X", but not "Will never fix" (unless the bug/wish is invalid of course, but that is another resolution). To further illustrate how self-contradictory and unhelpful WONTFIX is, consider this situation: I have a bug/wish that I want to report, and this bug has been reported before. If it is in a state of anything but WONTFIX, I know what state it is in. I can add to it, or just wait. But if I see that it has been closed as WONTFIX at some time in the past by some developer, what should I do ? Maybe there is a developer who *now* can implement it ? So it has truly become a *NEW* wish in today's context, and the legitimate action in this case is to file it as a *NEW* bug. This would really clutter the system. So I think greater care should be given when marking reports as WONTFIX, and I can't think of any situation where WONTFIX helps as a blanket statement. Those I can understand: - WORKAROUND (there is a --suboptimal-- way to get the desired behaviour) - PLEASE_HELP (helpful, means: I can't or won't fix myself, you'll have to help to get it resolved). - NO_FIX_FOR_NOW - WONTFIX_FOR_RELEASE=X (helpful to people watching the bug, so they don't expect it in release X) > Please have a look at http://bugs.kde.org/expired.cgi - I would like to > give the listed wishlists a WONTFIX automatically after having the link > online on dot.kde.org for a while. What do you think? It is bad enough when a developer closes your bugs with WONTFIX (he is one of the maintainers for now, but who says no other developer will implement it now or in the future ?). Having arbitrary rules to close wishes as WONTFIX is just about the best way to discourage people motivated enough to submit bugs. Worse, I think it will greatly encourage cheating, because as soon as an automated system to make these calls is in place, creative ways to get around it begin. > The current limits are ID < 64000 (roughly 15 months old) and less than 60 > votes (remember at 80 they become auto-confirmed for most products). How come http://bugs.kde.org/show_bug.cgi?id=33282 (0 vote) doesn't show up then ? Is it because it is NEW and not UNCONFIRMED ? This bug also illustrates another way to improve the cleanup system IMO. In this case, somebody without bugzilla write access (myself) looks at a bug, spends some time to analyze it and thinks it is invalid. Because most of the work is already done (if that call is right), there should be a fast track to the assigned developers to either validate that judgement (and closing the bug immediately), or saying something else about it ("No, I think it it valid", "Not sure, leaving as is"). This kind of pre-filtering ("Reviewed by"), if correctly organized, would result in *many* invalid/duplicate bugs going away quickly, and many old wishes being better characterized in the context of today's KDE. > So the kmail team is going to implement all the 800 wishes - that to a > good share are only wanted by single persons? Neat idea. you make two assumptions that are not entirely true: 1. People submitting wishes understand that there is no promise to implement them. It is therefore fine for a legitimate wish to stay forever (i.e as long as it s not fixed). 2. The fact that a bug/wish only has votes or comments from one person does NOT mean that it is wanted by a single person. Currently, when I see a bug/wish already reported, and I agree to it without anything to add, I consider the wish registered, and I specifically refrain from adding to the clutter out of respect fot the KDE developer, who might not be happy to see tons of comments like "Yeah, I agree!". Your proposal beaks both those principles, and would force people to: a) never trust the state of the systen, because legitimate reports close themselves automatically after some time. b) spend some time to --artificially-- clutter the systen to influence some kind of bug "score" if they want to enhance the chances for a wish to stay alive. Cheers, Philippe Rigault -------------------------------------------------------