[development] death to "x.y.z" version is now inevitable
dpal_gaf_devel at marsdome.com
Wed Nov 15 22:06:56 UTC 2006
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
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.
> 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:
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
> 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.
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.
>  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.
More information about the development