[development] Confusion by too many issue queues

[Derek Wright]

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