Confusion by too many issue queues
Hi there, as much as I am pleased with the outcome of Derek's efforts, I'd like to reduce the number of issue queues for Drupal again. We currently have three queues for what used to be HEAD. IMO it doesn't make sense to have a 6-dev queue /and/ a x.y.z queue _on_ _top_ of a 5-dev queue and a 5.1-beta queue. While you can find all sorts of academic reasoning why you must have this or that queue this wide array of choices is going to confuse bug reporters and we'll get more and more issues filed in the wrong queues. I suggest to remove 5-dev and 6-dev and to replace x.y.z by "Development version". Cheers, Gerhard
On Nov 14, 2006, at 3:23 AM, Gerhard Killesreiter wrote:
IMO it doesn't make sense to have a 6-dev queue /and/ a x.y.z queue _on_ _top_ of a 5-dev queue and a 5.1-beta queue.
i totally agree. it's a work-in-progress, and help is on the way...
I suggest to remove 5-dev and 6-dev and to replace x.y.z by "Development version".
sorry, but with all due respect, this means you don't fully appreciate the motivation for and implications of my push to get core to use 2 digit version numbers and for how the new release system works. ;) in particular, you should (re)read the "Motivation" section at the top of: http://drupal.org/node/85943 -- New version number convention for core IMHO, the far better solution to this problem would be to first remove "x.y.z" as a valid choice in the issue queue when submitting new issues or replying to existing ones. in fact, i had just been thinking about exactly this when i got up to start hacking this morning. i'd like to do this generically and nicely (http:// drupal.org/node/97568), but in the meantime, i might just add a 3 line hack to the version of project_issue.module running on d.o to special-case this. briefly: - "HEAD", "cvs", "Development version", etc is a *moving target*. issues filed against something like this are useless, since in 6 months "HEAD" is different and the issue isn't necessarily still valid. - all issues should be filed against a *specific* version. if the new system was in place, all those old "cvs" (or now "x.y.z") issues would have been filed against the appropriate 4.5.x-dev, 4.6.x-dev, 4.7.x-dev, etc versions. we'd know immediately which issues matter and which don't. as it stands, there are something like 2000 issues (haven't asked the DB recently) classified against this ambiguous version, and it requires lots of human effort to sort through the "cvs" queue. so, there's no way i'm going to see us continue down this evil path now that we have better tools in place. instead, i'll keep trying to make the tools even better so that the remaining problem (too many queues) is easier to deal with. 1 possible approach: the releases are all tagged with a taxonomy term for the core release "series" they belong to (4.7.x, 5.x, 6.x, etc). it'd be a simple INNER JOIN to allow you to view the issue queue for all issues from all versions that match one of these terms. so, instead of: http://drupal.org/project/issues? projects=3060&versions=94737,94702,96923 you could do something like: http://drupal.org/project/issues?projects=3060&series=5.x see http://drupal.org/node/97569 for progress on this. thanks, -derek
On Tue, 2006-11-14 at 06:11 -0800, Derek Wright wrote:
On Nov 14, 2006, at 3:23 AM, Gerhard Killesreiter wrote:
IMO it doesn't make sense to have a 6-dev queue /and/ a x.y.z queue _on_ _top_ of a 5-dev queue and a 5.1-beta queue.
i totally agree. it's a work-in-progress, and help is on the way...
I suggest to remove 5-dev and 6-dev and to replace x.y.z by "Development version".
sorry, but with all due respect, this means you don't fully appreciate the motivation for and implications of my push to get core to use 2 digit version numbers and for how the new release system works. ;) in particular, you should (re)read the "Motivation" section at the top of:
http://drupal.org/node/85943 -- New version number convention for core
<snip>
- "HEAD", "cvs", "Development version", etc is a *moving target*. issues filed against something like this are useless, since in 6 months "HEAD" is different and the issue isn't necessarily still valid.
Doesn't change the fact that an issue filed against 'HEAD' will probably remain in HEAD as HEAD moves forward until closed. Creating a release doesn't make the bugs in head disappear. Releasing a major version doesn't make the bugs in head go away. Do we have a system for keeping the moving target/head issues attached to head. I understand and appreciate having dev versions for each release, I'm frustrated that I'm too busy to get to use them at the moment.
On Nov 14, 2006, at 9:33 AM, Darrel O'Pry wrote:
Doesn't change the fact that an issue filed against 'HEAD' will probably remain in HEAD as HEAD moves forward until closed. Creating a release doesn't make the bugs in head disappear. Releasing a major version doesn't make the bugs in head go away.
i still think there's value in knowing what version the bug was reported against in the first place. if we want to say "show me all the still-open bugs that were submitted for 4.7.x" we still can, but we'd know that those are a different class of urgency than the new bugs reported for 5.x (critical vs. normal vs. minor aside). it's easy to query for what you want to know if you have a more specific classification system. if you just lump everything together into something called "HEAD", it's impossible to usefully filter the stuff back out again depending on what you want to know. that's how i see it... -derek
if you just lump everything together into something called "HEAD", it's impossible to usefully filter the stuff back out again depending on what you want to know.
that's how i see it...
in my eyes, we are optimizing for exotic queries and not for people who casually enter issues, and casually review issue queues for their installed modules. if we think hard enough, we can probably make both audiences happy.
Moshe Weitzman wrote:
if you just lump everything together into something called "HEAD", it's impossible to usefully filter the stuff back out again depending on what you want to know.
that's how i see it...
in my eyes, we are optimizing for exotic queries and not for people who casually enter issues, and casually review issue queues for their installed modules. if we think hard enough, we can probably make both audiences happy.
No way. I want to know which version of the software someone was using when they report a bug. In Drupal 5, it won't be a huge challenge figuring out which version an issue is being posted against; and dww was talking about fixing it so that the default is the current version (it kind of is now) on the project anyhow, so users not paying attention will know. As it is, it's a total mess. Half the users don't even understand what version they're running because we didn't offer version information, but we've just changed that. The new system will offer a much more information rich environment, and we can utilize that information.
On 14 Nov 2006, at 20:12, Derek Wright wrote:
Doesn't change the fact that an issue filed against 'HEAD' will probably remain in HEAD as HEAD moves forward until closed. Creating a release doesn't make the bugs in head disappear. Releasing a major version doesn't make the bugs in head go away.
i still think there's value in knowing what version the bug was reported against in the first place. if we want to say "show me all the still-open bugs that were submitted for 4.7.x" we still can, but we'd know that those are a different class of urgency than the new bugs reported for 5.x (critical vs. normal vs. minor aside).
it's easy to query for what you want to know if you have a more specific classification system.
if you just lump everything together into something called "HEAD", it's impossible to usefully filter the stuff back out again depending on what you want to know.
I can't talk for the others, but I haven't had much problems with the filtering/querying in the old system, or with figuring out the version information. Figuring out what version someone is running, has not been a big issue for me. +1 for removing x.y.z and optimizing for ease of use. 5.0-dev and 6.0-dev are useful. -- Dries Buytaert :: http://www.buytaert.net/
participants (6)
-
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Earl Miles -
Gerhard Killesreiter -
Moshe Weitzman