death to "x.y.z" version is now inevitable

woo hoo!  a lot of local testing and a tiny few lines diff
to  
issue.inc (now applied to drupal.org), and the
"x.y.z" version is  
hereby doomed to eventual extinction...

a) it's gone from the list of options when submitting a new
issue


b) if you try to reply to an issue already marked as x.y.z,
you  
immediately get a validation error:

"x.y.z is not a valid version, please select a
different value."

and once more, "x.y.z" is gone from the list of
choices.


c) you can still see issues marked as "x.y.z" in
the issue queue when  
doing regular queries, so it's not invisible or impossible
to find  
them[1].  they just can't stay this way. ;)


to re-iterate -- if you're dealing with an "x.y.z"
issue, you should  
re-assign it to:
6.x-dev -- feature request
5.x-dev -- bug report/task for 5.x
4.7.x-dev bugs/tasks for 4.7.5 and beyond (now exists, for
the  
DRUPAL-4-7 snapshot releases)
4.6.10 -- bugs only relevant in 4.6.10  (i'm assuming we
don't want  
do do DRUPAL-4-6 snapshot builds)

won't fix/closed for anything else. ;)
(although, i guess it forces you to select a different
version, so  
just use your best judgement about what old version that
issue was  
from, doesn't really matter that much...)

is everyone happy with this?

thanks,
-derek

[1] http://drupal.org/project/issues?projects=3060&
amp;versions=94702

On 14-Nov-06, at 12:27 PM, Derek Wright wrote:

> to re-iterate -- if you're dealing with an
"x.y.z" issue, you  
> should re-assign it to:
> 6.x-dev -- feature request
> 5.x-dev -- bug report/task for 5.x
> 4.7.x-dev bugs/tasks for 4.7.5 and beyond (now exists,
for the  
> DRUPAL-4-7 snapshot releases)
> 4.6.10 -- bugs only relevant in 4.6.10  (i'm assuming
we don't want  
> do do DRUPAL-4-6 snapshot builds)
>
> <snip>
>
> is everyone happy with this?

Pretty much.

6.x-dev vs. 5.x-dev is great, as it clearly defines
"this is  
something that should get fixed in this release" vs.
"this is  
something we should put off until the next release."

Where things get sticky for me are things like 5.0-beta1 vs.
5.x-dev  
and 4.7.4 vs. 4.7-dev.

Should things only get filed against 5.0-beta1 / 4.7.4 if
they were  
fixed in that version? Or should they be filed in that
version if  
they were originally spotted in that version? Are 5.0-beta1
/ 4.7.4  
for "end users" to report bugs as opposed to
5.x-dev /4.7-dev which  
are for "developers" to report bugs? Or..?

To be fair, this wasn't clear to me before the new release
system  
either, but as long you invited people to ask. ;)

-Angie

Derek Wright wrote:
> to re-iterate -- if you're dealing with an
"x.y.z" issue, you should 
> re-assign it to:
> 6.x-dev -- feature request
> 5.x-dev -- bug report/task for 5.x
This seemed suspicious to me, because it makes 6.x-dev
redundant with 
the feature request category.  So I took another look at the
tracker, 
and realized that you can't limit the search to a specific
version or 
set of versions (not even on the advanced search page),
though you can 
sort the results by version.  You can limit a search to just
feature 
requests.

In any event, the version number for feature requests is
sort of 
irrelevant - there's no guarantee that it will make it into
6.  I'd hate 
to think that when 6 is feature-frozen and 7.x-dev opened,
the remaining 
feature requests will need to be bumped to the new version. 
That would 
be a waste of time.  I'd rather just say that the version
number on an 
open feature request is meaningless, so don't sweat it; use
the date to 
figure out how long the request has been outstanding.  When
the request 
is finally implemented and closed, then the version number
becomes 
meaningful and should be the version in which it first
appears.

Gary

> > to re-iterate -- if you're dealing with an
"x.y.z" issue, you
> > should re-assign it to:
> > 6.x-dev -- feature request
> > 5.x-dev -- bug report/task for 5.x

These seem odd to me too (I've read the docs and still
puzzled). Isn't
6.x-dev the HEAD of TRUNK? If it isn't, where's it gone,
what's called? Not
6.x-dev surely?

5.x-dev seems reasonable, it's the HEAD of the 5 branch,
yes?

> > 4.7.x-dev bugs/tasks for 4.7.5 and beyond (now
exists, for the

And 4.7-dev?  We doing devel work on 4.7? I would have
thought bug and
security fixes are only going into the 4.7 branch.

I would have thought 4.7-stable would be a better name for
the head of the
4.7 branch. Then when the d,o release engineers (killes, et
al?) drop tags
onto this when doing a release (e.g. DRUPAL-4-7-4) at
appropriate times
(such as a security fix or many bug fixes / important
fixes).

With regards to filing bug reports. If someone wants to say
report a bug in
4-7-2 (and the latest release is 4-7-4) isn't the response
"have you updated
to 4-7-4 to see if the bug is still there?". Basically,
as it stands at the
moment, to do this you (we in fact, developers) have to look
in 4-7-4
ourselves and then say "doh, this was fixed at 4-7-3,
please upgrade". That
just makes more work for us the developers as we have to
look to see if an
old bug is fixed or not when end users can do this
themselves by upgrading
(that's what upgrading is often about). That's probably one
of the reasons
why we have 1000s of old issues hanging around the bug
queue. Most of these
can probably be wiped (or put into a status of swept under
the carpet as
it's almost impossible to go over them this late in the day,
given many will
probably have been fixed). As it stands now, the
"duplicate" status only
gets done when a developer sees a dup, otherwise the issue
gets left behind
in the bug queue.

Think that's my 2p worth

--Andy (AjK)

p.s. We did discuss archiving old issues, say before 4.6
release to dampen
down the bug queue on IRC recently. Many seemed in favour so
long as it was
a controlled "tidy up". That conversation never
reached the mailing list so
I'm bringing it up here. If you want answer this point on
the list, please
change the email subject appropriately to start a new
thread.

> 6.x-dev vs. 5.x-dev is great, as it clearly defines
"this is something 
> that should get fixed in this release" vs.
"this is something we should 
> put off until the next release."

isn't that basically what status=postponed means? we should
remove 6.x-dev 
or postponed, IMO.

On 14-Nov-06, at 10:02 PM, Moshe Weitzman wrote:

>> 6.x-dev vs. 5.x-dev is great, as it clearly defines
"this is  
>> something that should get fixed in this
release" vs. "this is  
>> something we should put off until the next
release."
>
> isn't that basically what status=postponed means? we
should remove  
> 6.x-dev or postponed, IMO.

Hm. Maybe. I like 6.x-dev because then it's already logged
against  
the correct version; I don't need to go back and re-activate
feature  
requests when HEAD un-thaws again.

"postponed" I like to think of as a "this
change is way too big, and  
needs more thinking, so let's postpone it until we can focus
on it  
properly" vs. "It won't get in this release, but
it's a relatively  
minor change so people might want to conceivably work on it
before  
HEAD formally un-thaws." Further, the
"postponed" status can also be  
useful for other, non-core issue queues (I use it in my
modules'  
issue queues to mark issues either that I don't plan to fix
right  
away but will entertain the idea at some point in the
future, or  
those that I don't can't fix until I fix some other blocker
bug).

So basically, both seem like they have their place.

-Angie

Moshe Weitzman wrote:
>> 6.x-dev vs. 5.x-dev is great, as it clearly defines
"this is something 
>> that should get fixed in this release" vs.
"this is something we 
>> should put off until the next release."
> 
> isn't that basically what status=postponed means? we
should remove 
> 6.x-dev or postponed, IMO.

postponed is a wasteland that no one will ever look at
except when there isn't 
enough to do already. postponed can mean a lot of things,
and in general means 
"it isn't that important."

On 11/14/06, Earl Miles <merlinlogrus.com> wrote:
> Moshe Weitzman wrote:
> > isn't that basically what status=postponed means?
we should remove
> > 6.x-dev or postponed, IMO.
>
> postponed is a wasteland that no one will ever look at
except when there isn't
> enough to do already. postponed can mean a lot of
things, and in general means
> "it isn't that important."

I've taken to thinking of it as a polite synonym for won't
fix. I'm a
bit ashamed to admit that I don't think I've ever re-opened
an issue
on any of my modules once I've marked postponed. I've taken
to either
closing them or marking them as feature requests for the
next version.

andrew

On Tuesday 14 November 2006 23:26, andrew morton wrote:
> On 11/14/06, Earl Miles <merlinlogrus.com> wrote:
> > Moshe Weitzman wrote:
> > > isn't that basically what status=postponed
means? we should remove
> > > 6.x-dev or postponed, IMO.
> >

> I've taken to thinking of it as a polite synonym for
won't fix. I'm a
> bit ashamed to admit that I don't think I've ever
re-opened an issue
> on any of my modules once I've marked postponed. I've
taken to either
> closing them or marking them as feature requests for
the next version.
>
> andrew

I've actually used this as a note to myself to adopt a
feature request in Core 
while Core is frozen.  It's a note to myself "hey, you
adopted this feature 
but got it out of the way for the other queues, come back to
it later".  I 
think I do over 75% of the time, too... 

-- 
Larry Garfield			AIM: LOLG42
larrygarfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than
all others of 
exclusive property, it is the action of the thinking power
called an idea, 
which an individual may exclusively possess as long as he
keeps it to 
himself; but the moment it is divulged, it forces itself
into the possession 
of every one, and the receiver cannot dispossess himself of
it."  -- Thomas 
Jefferson

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 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 that's specific to our policy, not
something  
inherent in issue tracking.  late in the 6.x development
cycle we'll  
still accept small features for 6.x, but some feature
requests will  
be considered too big, and we'll want to bump those to
7.x...

> So I took another look at the tracker, and realized
that you can't  
> limit the search to a specific version or set of
versions (not even  
> on the advanced search page), though you can sort the
results by  
> version.  You can limit a search to just feature
requests.

http://d
rupal.org/project/issues/search/3060
advanced issue search lets you filter by Versions (and the
often  
requested filtering on Components).

http://drupal.o
rg/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"...

you can also construct URLs to filter exactly what you want:
http://drupal.org/p
roject/issues? 
projects=3060&versions=94737,94702,96923

> 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. ;)

> - there's no guarantee that it will make it into 6. 
I'd hate to  
> think that when 6 is feature-frozen and 7.x-dev opened,
the  
> remaining feature requests will need to be bumped to
the new version.

we could certainly make an admin interface to automatically 

reclassify issues based on a query to do this operation en
masse.

> I'd rather just say that the version number on an open
feature  
> request is meaningless, so don't sweat it; use the date
to figure  
> out how long the request has been outstanding.  When
the request is  
> finally implemented and closed, then the version number
becomes  
> meaningful and should be the version in which it first
appears.

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].  short of
that, i agree  
that the single version field for feature requests isn't
worth  
sweating over.  since you can always change an issue's
version in a  
follow-up, i say you set it to whatever version you'd like
to see it  
in, and if it ever gets implemented, it can be reset to the
version  
it was fixed in.

-derek


[1] http://drupal.org/node/6
6484 i'd like to someday have the version  
be a multi-select to indicate bugs that exist in multiple
branches  
(though adding a "port" category would also help
that, and would be a  
lot less code to change: http://drupal.org/node/9
7571).  in theory,  
if we had 2 fields, they could both be N versions.  we
should look  
into issue relationships, and sub-issues for each particular
version  
and patch (which would be great if the UI was good enough to
make it  
easy to keep track of everything).  all OT from the current
x.y.z  
debates, however...