“after moratorium” will most probably go. “gsoc” has been asked for by Tarek, to tag issues to be done during a GSoC (one in progress, or ideas for a future one).

I have now retired these two keywords.

26backport can definitely go. 64bits is marginally used and can go as well, IMO.

And I look forward to the checkbox experiment as I suspect it will work out nicely.

Here are some updated stats about some of the keywords:
* 26backports:  8 issues
* 64bits     :  4 issues [0]
* after mor. :  2 issues

Since "[26backport] was clearly intended to tag backporting of py3
features to py2 (and thus misnamed to start with)" and now it's too late to add any features to 2.x, I think it could be already removed.
I would remove 64bits too, since it doesn't seem really used and I don't think anyone needs to search 64bits-related issues (see also [0]).
The "easy" and "buildbot" keyword are useful; the "after moratorium" and "gsoc" will probably be removed at some point anyway.

Regarding needs/has test/patch/doc, I think that check-boxes would be a good idea. I'll try to do some experiment and see how it works.

[0]: I'm not sure why #6673 has the 64bits keyword, and #8482 is a problem on 32 machines too (see last message), #1789 is just a doc patch now.

I don't know if anyone has taken the time to gather the stats, but doing a simple search where you sort on activity (descending order), don't care about the status, and choose the keyword you care about, and you can find out how useful the keyword has been.

For instance, 26backport has been set on 72 issues ever and the last use was yesterday, but with usage only once every week or two recently, and then spanning up to two months with no usage.

Does anybody have stats for keyword usage?

> The way I have always viewed it is if a test is needed, then a test is
> needed regardless of whether there is a patch. And if a test is missing
> then the patch is not ready to be reviewed anyway so it isn't quite as
> big of a deal that it exists yet. Otherwise the stage field should be
> trimmed down such that the need for a unit test, a patch, and doc
> changes are more checkboxes/keywords that they are completed than a
> stage where one of them needs to be done.

The patch keyword must remain. It indicates that one of the attachments
to the issue is a patch, and is automatically set when such an
attachment is made.

On Fri, Mar 20, 2009 at 17:14, Daniel (ajax) Diniz <ajaksu@gmail.com> wrote:

> Brett C. wrote:
> > The "needs review" and "patch"are outdated thanks to the stage field
> > and should be removed once there are no issues in the tracker with them
> set but
> > not stage.
>
> I find 'test needed' + 'patch' pretty informative, can't see a way to
> express that based on stages only.

The way I have always viewed it is if a test is needed, then a test is
needed regardless of whether there is a patch. And if a test is missing then
the patch is not ready to be reviewed anyway so it isn't quite as big of a
deal that it exists yet. Otherwise the stage field should be trimmed down
such that the need for a unit test, a patch, and doc changes are more
checkboxes/keywords that they are completed than a stage where one of them
needs to be done.

-Brett

Brett C. wrote:
> The "needs review" and "patch"are outdated thanks to the stage field
> and should be removed once there are no issues in the tracker with them set but
> not stage.

I find 'test needed' + 'patch' pretty informative, can't see a way to
express that based on stages only.

> I think part of the question is whether we feel the need to flag things
> for backporting, and if we do should it simply be for 3 to 2, or also
> cover 2.x backporting (e.g. 2.7 to 2.6) and 3.x backporting (e.g. 3.1 to
> 3.0). Or should it just be required of committers to simply handle the
> backporting as needed.

This particular keyword was clearly intended to tag backporting of py3
features to py2 (and thus misnamed to start with).

On Fri, Mar 20, 2009 at 16:42, <"\"Martin v. Löwis\"
<metatracker@psf.upfronthost"@psf.upfronthosting.co.za> wrote:

>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> > Martin> As for 26backport - it might be that the problem (porting back
> >     Martin> features from 3.0 to 2.x) should not exist anymore....
> >
> > Maybe it should be renamed to something more generic like 3to2backport?
>
> That could be done. Should it?

I think part of the question is whether we feel the need to flag things for
backporting, and if we do should it simply be for 3 to 2, or also cover 2.x
backporting (e.g. 2.7 to 2.6) and 3.x backporting (e.g. 3.1 to 3.0). Or
should it just be required of committers to simply handle the backporting as
needed.

On Fri, Mar 20, 2009 at 16:41, <"\"Martin v. Löwis\"
<metatracker@psf.upfronthost"@psf.upfronthosting.co.za> wrote:

>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> > Sure, but I thought the keyword was simply to help when there was all of
> > that 64-bit work being done a while back.
>
> I think you misremember. It was created on 2007-11-06 by Guido. The
> Py_ssize_t branch (assuming this is what you refer to as "64-bit work")
> was merged to Python on 2006-02-15. Not sure why Guido created the
> keyword; maybe we should ask.
>

If Guido created I can almost guarantee he doesn't care about it anymore.

>
> > Yes, I would not want to ditch a label until it was no longer needed.
>
> Ok, so there should be no action right now, right?

Right. I created this issue partially to remind me and others that at some
point we should deal with this.

> Martin> As for 26backport - it might be that the problem (porting back
>     Martin> features from 3.0 to 2.x) should not exist anymore....
> 
> Maybe it should be renamed to something more generic like 3to2backport?

That could be done. Should it?

> Sure, but I thought the keyword was simply to help when there was all of
> that 64-bit work being done a while back.

I think you misremember. It was created on 2007-11-06 by Guido. The
Py_ssize_t branch (assuming this is what you refer to as "64-bit work")
was merged to Python on 2006-02-15. Not sure why Guido created the
keyword; maybe we should ask.

> Yes, I would not want to ditch a label until it was no longer needed.

Ok, so there should be no action right now, right?

Martin> As for 26backport - it might be that the problem (porting back
    Martin> features from 3.0 to 2.x) should not exist anymore....

Maybe it should be renamed to something more generic like 3to2backport?

Skip

On Thu, Mar 19, 2009 at 22:52, <"\"Martin v. Löwis\"
<metatracker@psf.upfronthost"@psf.upfronthosting.co.za> wrote:

>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> Why is 64bit an outdated keywords? Is it not possible anymore that some
> issues
> only occur on 64-bit systems? Currently, 1202, 4506, 1008086 use this
> keyword.
>

Sure, but I thought the keyword was simply to help when there was all of
that 64-bit work being done a while back.

>
> As for 26backport - it might be that the problem (porting back features
> from 3.0
> to 2.x) should not exist anymore. However, apparently, it still *does*
> exist. 16
> issues are tagged with this keyword. Some are marked critical. I would be
> happier removing the keyword if the issues somehow got resolved first.

Yes, I would not want to ditch a label until it was no longer needed.

-Brett

Why is 64bit an outdated keywords? Is it not possible anymore that some issues
only occur on 64-bit systems? Currently, 1202, 4506, 1008086 use this keyword.

As for 26backport - it might be that the problem (porting back features from 3.0
to 2.x) should not exist anymore. However, apparently, it still *does* exist. 16
issues are tagged with this keyword. Some are marked critical. I would be
happier removing the keyword if the issues somehow got resolved first.

The keywords "26backport" and "64bit" are no longer needed and should simply be
removed. The "needs review" and "patch"are outdated thanks to the stage field
and should be removed once there are no issues in the tracker with them set but
not stage.