[development] Confusion by too many issue queues
drupal at dwwright.net
Tue Nov 14 14:11:31 UTC 2006
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
- "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
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,
you could do something like:
see http://drupal.org/node/97569 for progress on this.
More information about the development