Derek Wright wrote:
On Nov 14, 2006, at 12:09 PM, Gary Feldman wrote:
This seemed suspicious to me, because it makes 6.x-dev redundant with the feature request category. only in the short term. in a few months, people will be reporting bugs against the new menu system chx will be building for D6. ;) don't confuse Well, yes, but that changes the premise of your original note, which said that 6.x-dev should only be used for feature requests. I thought it was implicit that my comment only applied to that situation, and not after 6.x-dev becomes appropriate for bugs. the type (feature vs. task vs. bug) with the version. by convention we only accept feature requests for a specific version at any given time, but What does this convention mean? My guess is that you mean features are only committed to CVS for one specific version at any time, since clearly someone can submit a feature request with no idea of when it will get done. More specifically, what does it mean to say that a feature request has version 6.x-dev? Does that mean there's agreement that it belongs in version 6? Somebody has agreed to implement it for 6? The way I read your original note, reinforced by your remark above, is that all it means is that the feature request happened to be submitted during the 5.x feature freeze. That doesn't seem like useful information; it's implicit in the date.
Here's another way of looking at it: A person submitting a bug report should be able to identify a specific version that exhibits the bug, but a person submitting a feature request may not have a clue as to when it will be implemented. In the bug case, the meaning of the version number is well defined and in theory should never change. In the feature request case, the submitter may not know enough to choose a meaningful version, and hence we can't assume it has any significance at all. (Mozilla gets around this by only using the public tracking system for bugs, with feature requests going into forums. I don't know how they then select features for implementation. They're obviously a much more structured group, so this is just an observation, not a suggestion.) I'm coming from the idea that at the point in time that you're ready to consider feature requests for a new version, you review all open feature requests. At that point in time, all of the version and priority information is subject to change. That's why I don't see a use for a version number in a feature request until there's an actual commitment to a version.
... http://drupal.org/project/issues/3060 it's lame that this default issue query UI doesn't let you filter on those, too, and i definitely plan to fix this (http://drupal.org/node/65336). but there's only 1 of me, and i've kinda been busy recently. ;) it does at least provide a link to "advanced search"... This looks really nice. Will it become the default issue UI soon? you can also construct URLs to filter exactly what you want: http://drupal.org/project/issues?projects=3060&versions=94737,94702,96923 Shame, shame :-) Given the desire to improve Drupal's usability, ideas such as typing explicit, obscure data into the URL shouldn't be in anyone's repertoire anymore. :-) But I appreciate the suggestion. In any event, the version number for feature requests is sort of irrelevant
perhaps. i personally think it's still useful info. again, you just need the right tools to filter and manipulate all the data. i'm not saying all our tools are perfect yet, but they're getting better. ;) Yes, they are getting better all the time; I don't wish to disparage all the work that's gone into them. merlin and i were talking about (and webchick's question also raises) the issue of needing 2 version fields "reported for" and "resolved in". that's a whole other discussion[1]. In the For What It's Worth department, both Trac and Bugzilla have a version field and a target field (called milestone by Trac). Sourceforge doesn't have any version number fields, and uses a separate database for feature request. And as indicated above, Mozilla doesn't use Bugzilla for feature requests. So there's a spectrum of approaches. Personally, I like having the target date, with "unknown" a suitable initial default for feature requests. [1] http://drupal.org/node/66484 i'd like to someday have the version be a multi-select to indicate bugs that exist in multiple branches (though There are projects for which that makes sense, but I don't see Drupal ever maintaining so many branches that this becomes necessary.
Regards, Gary