From metatracker at psf.upfronthosting.co.za  Thu Apr  2 06:18:27 2009
From: metatracker at psf.upfronthosting.co.za (Sean Reifschneider)
Date: Thu, 02 Apr 2009 04:18:27 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1238645907.01.0.476155405014.issue16@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

r71035 adds a pending -> open auditor.

----------
nosy: +jafo

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Apr  2 06:24:00 2009
From: metatracker at psf.upfronthosting.co.za (Senthil)
Date: Thu, 02 Apr 2009 04:24:00 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I doubt if auto-closing if issue after a 14 day non-activity period is a good 
idea. The good way to analyze this change is, looking at the current issue 
tracker and seeing how many of the tickets have non-activity beyond 14 days. If 
there is a huge number, that would give us an idea of churn it will create. This 
churn could be for good or bad. Looking the bad side, if the reporter did not 
get anyone in the nosy list,his bug will get lost and he may not care again.

My sf.net bugs are open for months.

My suggestion would be to send a remainder email with issue age in days,months 
or years to catch attention.

----------
nosy: +orsenthil

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Apr  2 07:46:55 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Thu, 02 Apr 2009 05:46:55 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
Message-ID: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>


Brett C. <brett at python.org> added the comment:

On Wed, Apr 1, 2009 at 21:24, Senthil
<metatracker at psf.upfronthosting.co.za>wrote:

>
> Senthil <orsenthil at gmail.com> added the comment:
>
> I doubt if auto-closing if issue after a 14 day non-activity period is a
> good
> idea. The good way to analyze this change is, looking at the current issue
> tracker and seeing how many of the tickets have non-activity beyond 14
> days. If
> there is a huge number, that would give us an idea of churn it will create.
> This
> churn could be for good or bad. Looking the bad side, if the reporter did
> not
> get anyone in the nosy list,his bug will get lost and he may not care
> again.
>
> My sf.net bugs are open for months.
>
> My suggestion would be to send a remainder email with issue age in
> days,months
> or years to catch attention.

The closing of the issue should catch their attention. And commenting will
re-open it so it isn't hard to change the state. I still think that closing
a pending issue after 14 days is a good idea.

----------
nosy: +brett.cannon

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090402/8c7aaf55/attachment.htm>

From tleeuwenburg at gmail.com  Thu Apr  2 07:49:25 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Thu, 2 Apr 2009 16:49:25 +1100
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
Message-ID: <43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>

2009/4/2 Brett C. <metatracker at psf.upfronthosting.co.za>

>
> Brett C. <brett at python.org> added the comment:
>
> On Wed, Apr 1, 2009 at 21:24, Senthil
> <metatracker at psf.upfronthosting.co.za>wrote:
>
> >
> > Senthil <orsenthil at gmail.com> added the comment:
> >
> > I doubt if auto-closing if issue after a 14 day non-activity period is a
> > good
> > idea. The good way to analyze this change is, looking at the current
> issue
> > tracker and seeing how many of the tickets have non-activity beyond 14
> > days. If
> > there is a huge number, that would give us an idea of churn it will
> create.
> > This
> > churn could be for good or bad. Looking the bad side, if the reporter did
> > not
> > get anyone in the nosy list,his bug will get lost and he may not care
> > again.
> >
> > My sf.net bugs are open for months.
> >
> > My suggestion would be to send a remainder email with issue age in
> > days,months
> > or years to catch attention.
>
> The closing of the issue should catch their attention. And commenting will
> re-open it so it isn't hard to change the state. I still think that closing
> a pending issue after 14 days is a good idea.


I would suggest the period be a month. I don't there there is really a lot
that would be solved by using 14 days instead of a month, whereas I can see
that a lot of people might not always get around to responding to an issue
in 14 days.

Regards,
-Tennessee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090402/e9e936a4/attachment.htm>

From rdmurray at bitdance.com  Thu Apr  2 07:55:46 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 2 Apr 2009 01:55:46 -0400 (EDT)
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>

On Thu, 2 Apr 2009 at 16:49, Tennessee Leeuwenburg wrote:
>> The closing of the issue should catch their attention. And commenting will
>> re-open it so it isn't hard to change the state. I still think that closing
>> a pending issue after 14 days is a good idea.
>
> I would suggest the period be a month. I don't there there is really a lot
> that would be solved by using 14 days instead of a month, whereas I can see
> that a lot of people might not always get around to responding to an issue
> in 14 days.

The exact time probably doesn't matter.  I think there are two cases:
either the OP (or anyone else) is going to respond within a couple days
or not at all, or they will respond after they get back from
vacation...so 14 days probably covers most people's vacations, and
a month ought to cover just about everyone :)

For some reason I can't articulate, though, I like 14 days.

--David

From tleeuwenburg at gmail.com  Thu Apr  2 07:58:03 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Thu, 2 Apr 2009 16:58:03 +1100
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>
	<Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>
Message-ID: <43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>

On Thu, Apr 2, 2009 at 4:55 PM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Thu, 2 Apr 2009 at 16:49, Tennessee Leeuwenburg wrote:
>
>> The closing of the issue should catch their attention. And commenting will
>>> re-open it so it isn't hard to change the state. I still think that
>>> closing
>>> a pending issue after 14 days is a good idea.
>>>
>>
>> I would suggest the period be a month. I don't there there is really a lot
>> that would be solved by using 14 days instead of a month, whereas I can
>> see
>> that a lot of people might not always get around to responding to an issue
>> in 14 days.
>>
>
> The exact time probably doesn't matter.  I think there are two cases:
> either the OP (or anyone else) is going to respond within a couple days
> or not at all, or they will respond after they get back from
> vacation...so 14 days probably covers most people's vacations, and
> a month ought to cover just about everyone :)
>
> For some reason I can't articulate, though, I like 14 days.


I think 14 days probably covers active developers/contributors, but will
many individuals do not fall in this category. I think it's important to
pick up as much as possible.

Cheers,
-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090402/6da6a9f5/attachment-0001.htm>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Thu Apr  2 07:58:09 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Thu, 02 Apr 2009 05:58:09 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
Message-ID: <49D453E2.7060501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I doubt if auto-closing if issue after a 14 day non-activity period is a good 
> idea.

And indeed, we will not do that. What we will do instead is to close the
issue after 14 day non-activity IF THE STATUS IS PENDING.

So it is up to the reviewer to decide whether setting the state to
pending is the right thing.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Apr  2 07:59:58 2009
From: metatracker at psf.upfronthosting.co.za (Senthil)
Date: Thu, 02 Apr 2009 05:59:58 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <49D453E2.7060501@v.loewis.de>
Message-ID: <7c42eba10904012259w33dddaa7t52a4f9adbfdace47@mail.gmail.com>


Senthil <orsenthil at gmail.com> added the comment:

> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> So it is up to the reviewer to decide whether setting the state to
> pending is the right thing.

Then it could just be Open and Close states.
What if the issue is Open for more than 14 days.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From rdmurray at bitdance.com  Thu Apr  2 08:07:34 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 2 Apr 2009 02:07:34 -0400 (EDT)
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za> 
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com> 
	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com> 
	<Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>
	<43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0904020204190.26362@kimball.webabinitio.net>

On Thu, 2 Apr 2009 at 16:58, Tennessee Leeuwenburg wrote:
>> The exact time probably doesn't matter.  I think there are two cases:
>> either the OP (or anyone else) is going to respond within a couple days
>> or not at all, or they will respond after they get back from
>> vacation...so 14 days probably covers most people's vacations, and
>> a month ought to cover just about everyone :)
>>
>> For some reason I can't articulate, though, I like 14 days.
>
>
> I think 14 days probably covers active developers/contributors, but will
> many individuals do not fall in this category. I think it's important to
> pick up as much as possible.

What I'm saying is that in general, if one does not respond to an email
within one or at most two days after reading it (so maybe three or
four total depending on how often you check your email), one is not
going to respond at all.  I think this applies to anyone, developer
or not.

In fact, I think a user reporting a bug is more likely to respond quickly
to an issue email than a developer (who deals with many more of them)
is likely to.

I'm not invested in a particular length of time, though.

--David

From tleeuwenburg at gmail.com  Thu Apr  2 08:18:39 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Thu, 2 Apr 2009 17:18:39 +1100
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <Pine.LNX.4.64.0904020204190.26362@kimball.webabinitio.net>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>
	<Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>
	<43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>
	<Pine.LNX.4.64.0904020204190.26362@kimball.webabinitio.net>
Message-ID: <43c8685c0904012318j437cce68o500901dadb13a739@mail.gmail.com>

On Thu, Apr 2, 2009 at 5:07 PM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Thu, 2 Apr 2009 at 16:58, Tennessee Leeuwenburg wrote:
>
>> The exact time probably doesn't matter.  I think there are two cases:
>>> either the OP (or anyone else) is going to respond within a couple days
>>> or not at all, or they will respond after they get back from
>>> vacation...so 14 days probably covers most people's vacations, and
>>> a month ought to cover just about everyone :)
>>>
>>> For some reason I can't articulate, though, I like 14 days.
>>>
>>
>>
>> I think 14 days probably covers active developers/contributors, but will
>> many individuals do not fall in this category. I think it's important to
>> pick up as much as possible.
>>
>
> What I'm saying is that in general, if one does not respond to an email
> within one or at most two days after reading it (so maybe three or
> four total depending on how often you check your email), one is not
> going to respond at all.  I think this applies to anyone, developer
> or not.


I would agree in general, but not 100% of people operate this way. For
example, *I* don't operate this way. I frequently respond to issues a week,
two weeks, or even a month later. I accept I'm probably unusual in this
regard, but I have at any one time probably 5 or 6 significant emails which
are not going to get an immediate response but are still in my inbox as a
placeholder for getting round to them when I can. The difference between 14
days and a month is huge to me. I would respond to 80% of emails within 12
hours, 80% of the rest within 3 days and 80% of the rest within a month.
There's some optimal period of time beyond which the proportion of
unresponded emails is sufficiently small which is balanced against the
benefit of closing issues more frequently and thereby processing a larger
total number. I'm just arguing that a month should still increase throughput
by a lot, while still giving people very adequate time to respond.

In fact, I think a user reporting a bug is more likely to respond quickly
> to an issue email than a developer (who deals with many more of them)
> is likely to.


I would agree with this in general, vacations excepted.

I'm not invested in a particular length of time, though.


Then I suggest a month ;)

Cheers,
-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090402/9c906977/attachment.htm>

From martin at v.loewis.de  Thu Apr  2 08:27:17 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 02 Apr 2009 01:27:17 -0500
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <43c8685c0904012318j437cce68o500901dadb13a739@mail.gmail.com>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>	<Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>	<43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>	<Pine.LNX.4.64.0904020204190.26362@kimball.webabinitio.net>
	<43c8685c0904012318j437cce68o500901dadb13a739@mail.gmail.com>
Message-ID: <49D45AC5.80100@v.loewis.de>


> I would agree in general, but not 100% of people operate this way. For
> example, *I* don't operate this way. I frequently respond to issues a
> week, two weeks, or even a month later. 

Ok, so when you respond, you will have to reopen the issue. No big deal.

> Then I suggest a month ;)

Changing it now is more effort than not changing it. This is bikeshedding.

Regards,
Martin

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Thu Apr  2 08:27:29 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Thu, 02 Apr 2009 06:27:29 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <43c8685c0904012318j437cce68o500901dadb13a739@mail.gmail.com>
Message-ID: <49D45AC5.80100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would agree in general, but not 100% of people operate this way. For
> example, *I* don't operate this way. I frequently respond to issues a
> week, two weeks, or even a month later. 

Ok, so when you respond, you will have to reopen the issue. No big deal.

> Then I suggest a month ;)

Changing it now is more effort than not changing it. This is bikeshedding.

Regards,
Martin

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From tleeuwenburg at gmail.com  Thu Apr  2 08:32:44 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Thu, 2 Apr 2009 17:32:44 +1100
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <49D45AC5.80100@v.loewis.de>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<43c8685c0904012249y108886a0vab9e5a9520664e0a@mail.gmail.com>
	<Pine.LNX.4.64.0904020152120.26362@kimball.webabinitio.net>
	<43c8685c0904012258r37f4154boad84bd6a7d4d5401@mail.gmail.com>
	<Pine.LNX.4.64.0904020204190.26362@kimball.webabinitio.net>
	<43c8685c0904012318j437cce68o500901dadb13a739@mail.gmail.com>
	<49D45AC5.80100@v.loewis.de>
Message-ID: <43c8685c0904012332w214f5763hde05d2e342e32bf5@mail.gmail.com>

On Thu, Apr 2, 2009 at 5:27 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

>
> > I would agree in general, but not 100% of people operate this way. For
> > example, *I* don't operate this way. I frequently respond to issues a
> > week, two weeks, or even a month later.
>
> Ok, so when you respond, you will have to reopen the issue. No big deal.


Fair enough.


>  > Then I suggest a month ;)
>
> Changing it now is more effort than not changing it. This is bikeshedding.


I hadn't realised it was already in place, I was responding to Senthil's
comments which appeared to be saying that auto-closing was an inherently bad
idea. I thought I'd just help workshop the appropriate closing time. If it's
already implemented then I'm all for calling it done. I still think a month
is better than 14 days, but so what -- done is great!

Cheers,
-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090402/f9291539/attachment.htm>

From metatracker at psf.upfronthosting.co.za  Thu Apr  2 17:38:15 2009
From: metatracker at psf.upfronthosting.co.za (Sean Reifschneider)
Date: Thu, 02 Apr 2009 15:38:15 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1238686695.05.0.848014623312.issue16@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

r71050 adds "scripts/close-pending" script, which I am asking Martin to run a
dry-run against the live database so I can verify the results.  At that point it
should be ready to set up as a cron job.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From skip at pobox.com  Thu Apr  2 20:46:18 2009
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 2 Apr 2009 13:46:18 -0500
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
References: <1238646240.83.0.97154819774.issue16@psf.upfronthosting.co.za>
	<bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
Message-ID: <18901.2042.732024.331634@montanaro.dyndns.org>


    Brett> I still think that closing a pending issue after 14 days is a
    Brett> good idea.

Auto-close seems reasonable, but 14 days is too short, even if the submitter
can reopen by adding a new comment.  Consider the past week.  Lots of
experienced core developers were probably distracted from bug triage for at
least a week, what with tutorials, the conference and the sprints.  It will
take many of them a a few days just to get caught back up at work once they
return home, putting tickets they might have expressed interest perilously
close to being automatically closed.  Browsing recent open but unassigned
tickets won't show up such auto-closed tickets.

If I recall correctly, basic search (that which most people will use) is
restricted to open tickets.  If searching for a problem they've encountered,
they may well miss that other people are having the same problem.  What's
the extra cost of bumping the auto-close interval to, say, two months?  It
will take awhile longer to fill the pipeline of dormant tickets, but once
filled it will empty at roughly the same rate as a shorter pipeline, right?

Skip

From metatracker at psf.upfronthosting.co.za  Thu Apr  2 20:46:25 2009
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Thu, 02 Apr 2009 18:46:25 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
Message-ID: <18901.2042.732024.331634@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Brett> I still think that closing a pending issue after 14 days is a
    Brett> good idea.

Auto-close seems reasonable, but 14 days is too short, even if the submitter
can reopen by adding a new comment.  Consider the past week.  Lots of
experienced core developers were probably distracted from bug triage for at
least a week, what with tutorials, the conference and the sprints.  It will
take many of them a a few days just to get caught back up at work once they
return home, putting tickets they might have expressed interest perilously
close to being automatically closed.  Browsing recent open but unassigned
tickets won't show up such auto-closed tickets.

If I recall correctly, basic search (that which most people will use) is
restricted to open tickets.  If searching for a problem they've encountered,
they may well miss that other people are having the same problem.  What's
the extra cost of bumping the auto-close interval to, say, two months?  It
will take awhile longer to fill the pipeline of dormant tickets, but once
filled it will empty at roughly the same rate as a shorter pipeline, right?

Skip

----------
nosy: +montanaro

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From stephen at xemacs.org  Fri Apr  3 07:43:05 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 03 Apr 2009 14:43:05 +0900
Subject: [Tracker-discuss]  [issue16] Automatic issue expiration
In-Reply-To: <18901.2042.732024.331634@montanaro.dyndns.org>
References: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<18901.2042.732024.331634@montanaro.dyndns.org>
Message-ID: <87wsa2thqu.fsf@xemacs.org>

Skip Montanaro writes:
 > 
 > Skip Montanaro <skip at pobox.com> added the comment:
 > 
 > Brett> I still think that closing a pending issue after 14 days is a
 >     Brett> good idea.
 > 
 > Auto-close seems reasonable, but 14 days is too short, even if the submitter
 > can reopen by adding a new comment.  Consider the past week.  Lots of
 > experienced core developers were probably distracted from bug triage for at
 > least a week, what with tutorials, the conference and the sprints.  It will
 > take many of them a a few days just to get caught back up at work once they
 > return home, putting tickets they might have expressed interest perilously
 > close to being automatically closed.

Suggestion: I think a better way to handle this apparent problem would
be to document that "pending" should be used with care, only when the
requested information really is necessary to implement a resolution of
the issue.

Suggestion: I don't think an unassigned ticket should be classed as
"pending".  If the triager doesn't feel competent, and wants to act as
a "secretary" for the competent developer, they should assign to
themselves, then reassign to a competent developer when sufficient
information is available.  Ideally, no ticket should be closed without
a human being taking responsibility for it.

Thing is, what *pending* means is that a developer has *already*
"expressed interest", and found themselves *blocked* for lack of
information.  Why would a second developer be interested in that
ticket?  Sure, there will be one-of-a-kind reasons, but mostly I would
expect that during triage sweeps developers will ignore -- as best
they can, some things will just catch the eye, of course -- "pending"
tickets.  And they *should* ignore them, otherwise why have a
"pending" status?

 > What's the extra cost of bumping the auto-close interval to, say,
 > two months?

Having four times as many tickets that developers with little time to
spare have to skip over.  (Thus further decreasing the chance that
they'll look at any one of them.)

Also, although there may be some submitters like Tennessee who
actually do systematically respond to requests for information a month
later, I personally would do much better with a shorter deadline (for
me a 10-day deadline would be optimal).  And I would think the
majority of submitters aren't going to be doing anything "systematic",
they want a fix a.s.a.p., so they will respond as quickly as they can,
if only to say "er, how do I get the information you need?"

What's the benefit to keeping it open longer?  The only thing I can
see is that a second developer will look at it despite the "not enough
info" judgment of the first developer, and see something that the
first didn't.  How likely is that conjunction of events?  Isn't it
more likely that the second developer will go, "yup, a waste of my
time as expected: can't do anything without that information"?  And it
doesn't help the submitter, they've already been notified that
somebody responsible needs more information from them.  If they search
for "my bugs" it *should* show up (if not, I'd consider that a tracker
bug).

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 07:37:11 2009
From: metatracker at psf.upfronthosting.co.za (Stephen Turnbull)
Date: Fri, 03 Apr 2009 05:37:11 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <18901.2042.732024.331634@montanaro.dyndns.org>
Message-ID: <87wsa2thqu.fsf@xemacs.org>


Stephen Turnbull <stephen at xemacs.org> added the comment:

Skip Montanaro writes:
 > 
 > Skip Montanaro <skip at pobox.com> added the comment:
 > 
 > Brett> I still think that closing a pending issue after 14 days is a
 >     Brett> good idea.
 > 
 > Auto-close seems reasonable, but 14 days is too short, even if the submitter
 > can reopen by adding a new comment.  Consider the past week.  Lots of
 > experienced core developers were probably distracted from bug triage for at
 > least a week, what with tutorials, the conference and the sprints.  It will
 > take many of them a a few days just to get caught back up at work once they
 > return home, putting tickets they might have expressed interest perilously
 > close to being automatically closed.

Suggestion: I think a better way to handle this apparent problem would
be to document that "pending" should be used with care, only when the
requested information really is necessary to implement a resolution of
the issue.

Suggestion: I don't think an unassigned ticket should be classed as
"pending".  If the triager doesn't feel competent, and wants to act as
a "secretary" for the competent developer, they should assign to
themselves, then reassign to a competent developer when sufficient
information is available.  Ideally, no ticket should be closed without
a human being taking responsibility for it.

Thing is, what *pending* means is that a developer has *already*
"expressed interest", and found themselves *blocked* for lack of
information.  Why would a second developer be interested in that
ticket?  Sure, there will be one-of-a-kind reasons, but mostly I would
expect that during triage sweeps developers will ignore -- as best
they can, some things will just catch the eye, of course -- "pending"
tickets.  And they *should* ignore them, otherwise why have a
"pending" status?

 > What's the extra cost of bumping the auto-close interval to, say,
 > two months?

Having four times as many tickets that developers with little time to
spare have to skip over.  (Thus further decreasing the chance that
they'll look at any one of them.)

Also, although there may be some submitters like Tennessee who
actually do systematically respond to requests for information a month
later, I personally would do much better with a shorter deadline (for
me a 10-day deadline would be optimal).  And I would think the
majority of submitters aren't going to be doing anything "systematic",
they want a fix a.s.a.p., so they will respond as quickly as they can,
if only to say "er, how do I get the information you need?"

What's the benefit to keeping it open longer?  The only thing I can
see is that a second developer will look at it despite the "not enough
info" judgment of the first developer, and see something that the
first didn't.  How likely is that conjunction of events?  Isn't it
more likely that the second developer will go, "yup, a waste of my
time as expected: can't do anything without that information"?  And it
doesn't help the submitter, they've already been notified that
somebody responsible needs more information from them.  If they search
for "my bugs" it *should* show up (if not, I'd consider that a tracker
bug).

----------
nosy: +stephen

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From skip at pobox.com  Fri Apr  3 16:14:33 2009
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 3 Apr 2009 09:14:33 -0500
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87wsa2thqu.fsf@xemacs.org>
References: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<18901.2042.732024.331634@montanaro.dyndns.org>
	<87wsa2thqu.fsf@xemacs.org>
Message-ID: <18902.6601.488971.297303@montanaro.dyndns.org>


    >> Auto-close seems reasonable, but 14 days is too short, even if the
    >> submitter can reopen by adding a new comment....

    Stephen> Suggestion: I don't think an unassigned ticket should be
    Stephen> classed as "pending"....

Which, I must apologize, I completely missed since I came late to the party
and all I was doing was reading individual messages as they arrived in my
inbox.  In particular, I hadn't read through the entire chain of messages.
I sent my response thinking we were discussing a new ticket, not one which
had been completely through the mill and was just waiting for the original
requestor (or someone else) to say, "yeah, this is fixed - please close".
Once in the "pending close" state I agree two weeks should be plenty of time
for someone to respond.

So, mea very culpa.  Sorry for the noise.

Skip

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 16:14:41 2009
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Fri, 03 Apr 2009 14:14:41 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87wsa2thqu.fsf@xemacs.org>
Message-ID: <18902.6601.488971.297303@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> Auto-close seems reasonable, but 14 days is too short, even if the
    >> submitter can reopen by adding a new comment....

    Stephen> Suggestion: I don't think an unassigned ticket should be
    Stephen> classed as "pending"....

Which, I must apologize, I completely missed since I came late to the party
and all I was doing was reading individual messages as they arrived in my
inbox.  In particular, I hadn't read through the entire chain of messages.
I sent my response thinking we were discussing a new ticket, not one which
had been completely through the mill and was just waiting for the original
requestor (or someone else) to say, "yeah, this is fixed - please close".
Once in the "pending close" state I agree two weeks should be plenty of time
for someone to respond.

So, mea very culpa.  Sorry for the noise.

Skip

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From rdmurray at bitdance.com  Fri Apr  3 19:23:09 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 3 Apr 2009 13:23:09 -0400 (EDT)
Subject: [Tracker-discuss] [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <20090403160659.1AB6278590@psf.upfronthosting.co.za>
References: <20090403160659.1AB6278590@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0904031233310.26362@kimball.webabinitio.net>

On Fri, 3 Apr 2009 at 18:06, Python tracker wrote:
> ACTIVITY SUMMARY (03/27/09 - 04/03/09)
> Python tracker at http://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue
> number.  Do NOT respond to this message.
>
>
> 2272 open (+59) / 15229 closed (+39) / 17501 total (+98)
>
> Open issues with patches:   857
>
> Average duration of open issues: 647 days.
> Median duration of open issues: 388 days.
>
> Open Issues Breakdown
>   open  2222 (+57)
> pending    50 ( +2)
>
> Issues Created Or Reopened (103)
> ________________________________
>
[...]
>
> Issues Now Closed (233)
> _______________________
>

Let's see if I understand this.  So there were 98 new issues opened,
of which 39 were closed in the reporting period and 50 were left open.
Then in a disjoint reporting, 103 items become opened either by being
created or by being reopened, and 233 bugs in total went from some open
state to closed during the reporting period.

OK.  But that first line is _really discouraging_.  I suggest we change
this report to provide statistics that are designed to encourage people
using the tracker when they make progress on reducing the total number
of outstanding bugs, or at least make it clear that the open bug count
isn't increasing as fast as the above report format makes it seem.

(An aside: I don't think I care how many total bugs there are.  IMO that's
just noise in a report like this.)

I'd like to see something more like:

     New issues this week:            98
     Old issues reopened:              5
                                     ---
     Additional open this week:      103

     New issues closed this week:     39
     New issues set close pending:     2
     Old issues closed this week:    194
                                     ---
     Total issues closed this week:  233


     Open issue count on 03/27:     2353
     Open issue count on 04/03:     2222
                                    ----
     Net decrease in open issues:    131

Presumably there is also an 'old issues set pending' line to add
in the second set.

Would this be possible?  Any other suggestions for clearer and/or more
moral building reporting?

--David

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 21:48:20 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 03 Apr 2009 19:48:20 +0000
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there are
	open dependencies
In-Reply-To: <1238788100.06.0.566028612767.issue256@psf.upfronthosting.co.za>
Message-ID: <1238788100.06.0.566028612767.issue256@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This patch reactivates the bit of statusauditor.py that checks for dependencies
on close. 

Before the patch, it used to disallow closing if there were any dependencies, as
the idea was that once a dependency/blocker was closed, it would be removed from
the dependency list. I changed that to block closing if any non-closed
dependencies exist.

----------
files: no_open_dependencies.diff
messages: 1289
nosy: ajaksu2, gbrandl
priority: feature
status: unread
title: Forbid closing an issue if there are open dependencies

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue256>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_open_dependencies.diff
Type: text/x-diff
Size: 1404 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090403/e5eb1b04/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 21:49:58 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 03 Apr 2009 19:49:58 +0000
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there are
	open dependencies
In-Reply-To: <1238788100.06.0.566028612767.issue256@psf.upfronthosting.co.za>
Message-ID: <1238788198.17.0.543490750963.issue256@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Same patch as before, with a new feature I'm not sure would be so useful: on
close, set stage to 'committed/rejected'; on 'committed/rejected', close the issue.

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue256>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: on_close_dependencies.diff
Type: text/x-diff
Size: 2108 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090403/54473ca5/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 21:52:34 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 03 Apr 2009 19:52:34 +0000
Subject: [Tracker-discuss] [issue257] Allow issue creator to set resolution
In-Reply-To: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>
Message-ID: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Since we allow users to close issues they created, allowing to set Resolution
makes sense too. If the 'on close' patch is accepted, closing would also
automatically set Stage to 'committed/rejected'.

----------
files: own_resolution.diff
messages: 1291
nosy: ajaksu2
priority: feature
status: unread
title: Allow issue creator to set resolution

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue257>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: own_resolution.diff
Type: text/x-diff
Size: 619 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090403/5b85bede/attachment-0001.diff>

From rdmurray at bitdance.com  Fri Apr  3 22:04:39 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 3 Apr 2009 16:04:39 -0400 (EDT)
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there
 are	open dependencies
In-Reply-To: <1238788198.17.0.543490750963.issue256@psf.upfronthosting.co.za>
References: <1238788198.17.0.543490750963.issue256@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0904031600460.26362@kimball.webabinitio.net>

On Fri, 3 Apr 2009 at 19:49, Daniel Diniz wrote:
> Daniel Diniz <ajaksu at gmail.com> added the comment:
>
> Same patch as before, with a new feature I'm not sure would be so useful: on
> close, set stage to 'committed/rejected'; on 'committed/rejected', close the issue.

The latter I would recommend against.  I often set stage to
'committed/rejected' when I set a ticket to pending, and I think that
provides useful information since it differentiates it from a ticket set
to pending because the submitter hasn't provided a reproducible test case.

But that's IMO, of course :), especially considering that I have
at least once set the stage and forgotten to set close.

--David

From rdmurray at bitdance.com  Fri Apr  3 22:08:24 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 3 Apr 2009 16:08:24 -0400 (EDT)
Subject: [Tracker-discuss] [issue257] Allow issue creator to set
	resolution
In-Reply-To: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>
References: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0904031604580.26362@kimball.webabinitio.net>

On Fri, 3 Apr 2009 at 19:52, Daniel Diniz wrote:
> New submission from Daniel Diniz <ajaksu at gmail.com>:
>
> Since we allow users to close issues they created, allowing to set Resolution
> makes sense too. If the 'on close' patch is accepted, closing would also
> automatically set Stage to 'committed/rejected'.

Hmm.  Except that if it is the submitter doing the close,
that would be a lie :)

Maybe it would be better to have a new resolution "closed by
submitter" that gets set automatically if the submitter
closes the ticket and resolution hasn't otherwise been set?

--David

From ajaksu at gmail.com  Fri Apr  3 22:57:09 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 3 Apr 2009 17:57:09 -0300
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there
	are open dependencies
In-Reply-To: <Pine.LNX.4.64.0904031600460.26362@kimball.webabinitio.net>
References: <1238788198.17.0.543490750963.issue256@psf.upfronthosting.co.za> 
	<Pine.LNX.4.64.0904031600460.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904031357k70511dbeude3fb868ef8240ae@mail.gmail.com>

R. David Murray wrote:
> On Fri, 3 Apr 2009 at 19:49, Daniel Diniz wrote:
>>
>> Daniel Diniz <ajaksu at gmail.com> added the comment:
>>
>> Same patch as before, with a new feature I'm not sure would be so useful:
>> on
>> close, set stage to 'committed/rejected'; on 'committed/rejected', close
>> the issue.
>
> The latter I would recommend against. ?I often set stage to
> 'committed/rejected' when I set a ticket to pending, and I think that
> provides useful information since it differentiates it from a ticket set
> to pending because the submitter hasn't provided a reproducible test case.

Yeah, felt a bit too restrictive to me too.  It's not a major issue
nor a RFE I'd argue about, so much so I already submitted a patch
without this part :)

> But that's IMO, of course :), especially considering that I have
> at least once set the stage and forgotten to set close.

I usually do opposite, forgetting to set stage on closing. But it
causes no real issues, so let's drop the auto-thing.

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 22:57:26 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 03 Apr 2009 20:57:26 +0000
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there are
	open dependencies
In-Reply-To: <Pine.LNX.4.64.0904031600460.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904031357k70511dbeude3fb868ef8240ae@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

R. David Murray wrote:
> On Fri, 3 Apr 2009 at 19:49, Daniel Diniz wrote:
>>
>> Daniel Diniz <ajaksu at gmail.com> added the comment:
>>
>> Same patch as before, with a new feature I'm not sure would be so useful:
>> on
>> close, set stage to 'committed/rejected'; on 'committed/rejected', close
>> the issue.
>
> The latter I would recommend against. ?I often set stage to
> 'committed/rejected' when I set a ticket to pending, and I think that
> provides useful information since it differentiates it from a ticket set
> to pending because the submitter hasn't provided a reproducible test case.

Yeah, felt a bit too restrictive to me too.  It's not a major issue
nor a RFE I'd argue about, so much so I already submitted a patch
without this part :)

> But that's IMO, of course :), especially considering that I have
> at least once set the stage and forgotten to set close.

I usually do opposite, forgetting to set stage on closing. But it
causes no real issues, so let's drop the auto-thing.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue256>
_______________________________________________________

From ajaksu at gmail.com  Fri Apr  3 22:59:42 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 3 Apr 2009 17:59:42 -0300
Subject: [Tracker-discuss] [issue257] Allow issue creator to set
	resolution
In-Reply-To: <Pine.LNX.4.64.0904031604580.26362@kimball.webabinitio.net>
References: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za> 
	<Pine.LNX.4.64.0904031604580.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904031359k4502d4edk835ab42eb165a0c4@mail.gmail.com>

R. David Murray wrote:
> On Fri, 3 Apr 2009 at 19:52, Daniel Diniz wrote:
>>
>> New submission from Daniel Diniz <ajaksu at gmail.com>:
>>
>> Since we allow users to close issues they created, allowing to set
>> Resolution
>> makes sense too. If the 'on close' patch is accepted, closing would also
>> automatically set Stage to 'committed/rejected'.
>
> Hmm. ?Except that if it is the submitter doing the close,
> that would be a lie :)

Oops, you're right :)

> Maybe it would be better to have a new resolution "closed by
> submitter" that gets set automatically if the submitter
> closes the ticket and resolution hasn't otherwise been set?

Nah, let's leave it as 'not selected'. It's a nop, more accurate and
we wouldn't gain much from an extra stage.

From metatracker at psf.upfronthosting.co.za  Fri Apr  3 22:59:58 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 03 Apr 2009 20:59:58 +0000
Subject: [Tracker-discuss] [issue257] Allow issue creator to set resolution
In-Reply-To: <Pine.LNX.4.64.0904031604580.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904031359k4502d4edk835ab42eb165a0c4@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

R. David Murray wrote:
> On Fri, 3 Apr 2009 at 19:52, Daniel Diniz wrote:
>>
>> New submission from Daniel Diniz <ajaksu at gmail.com>:
>>
>> Since we allow users to close issues they created, allowing to set
>> Resolution
>> makes sense too. If the 'on close' patch is accepted, closing would also
>> automatically set Stage to 'committed/rejected'.
>
> Hmm. ?Except that if it is the submitter doing the close,
> that would be a lie :)

Oops, you're right :)

> Maybe it would be better to have a new resolution "closed by
> submitter" that gets set automatically if the submitter
> closes the ticket and resolution hasn't otherwise been set?

Nah, let's leave it as 'not selected'. It's a nop, more accurate and
we wouldn't gain much from an extra stage.

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue257>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Apr  4 03:58:40 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 04 Apr 2009 01:58:40 +0000
Subject: [Tracker-discuss] [issue258] Auto add users as nosy based on
	components
In-Reply-To: <1238810320.41.0.116804859177.issue258@psf.upfronthosting.co.za>
Message-ID: <1238810320.41.0.116804859177.issue258@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This patch allows users to be added to the nosy list in a similar way
auto-assigning works.

Given that the current UI isn't great for adding auto-nosy users, I think we
should do that sparingly :)

----------
files: auto_nosy.diff
messages: 1294
nosy: ajaksu2
priority: feature
status: unread
title: Auto add users as nosy based on components

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue258>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto_nosy.diff
Type: text/x-diff
Size: 1496 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090404/6adf588e/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Sat Apr  4 05:08:59 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 04 Apr 2009 03:08:59 +0000
Subject: [Tracker-discuss] [issue259] Add an IO component
In-Reply-To: <1238814539.15.0.999943581075.issue259@psf.upfronthosting.co.za>
Message-ID: <1238814539.15.0.999943581075.issue259@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Antoine and Benjamin want an IO component, and would like to be auto-added as
nosy to issues with that component set (#258).

----------
messages: 1295
nosy: ajaksu2
priority: feature
status: unread
title: Add an IO component

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue259>
_______________________________________________________

From georg at python.org  Sat Apr  4 15:52:27 2009
From: georg at python.org (Georg Brandl)
Date: Sat, 04 Apr 2009 15:52:27 +0200
Subject: [Tracker-discuss] Issue tags
Message-ID: <49D7661B.7070509@python.org>

Hi,

at PyCon, the question came up whether to reorganize the components list
and replace most of them by a new comma-separated list of (arbitrary) tags.

These should contain the module name, if the report refers to one.  It can
also take additional values which we'd have to define.

Georg

From martin at v.loewis.de  Sat Apr  4 19:42:03 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 04 Apr 2009 19:42:03 +0200
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87wsa2thqu.fsf@xemacs.org>
References: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>	<18901.2042.732024.331634@montanaro.dyndns.org>
	<87wsa2thqu.fsf@xemacs.org>
Message-ID: <49D79BEB.2060900@v.loewis.de>

> Thing is, what *pending* means is that a developer has *already*
> "expressed interest", and found themselves *blocked* for lack of
> information.

You completely misunderstand. It means something entirely different.

It means that whoever looked at the issue thinks it should be closed,
but on the off-chance that somebody might object, sets it to pending
only. No developer is interested anymore - it's about to be closed.

Regards,
Martin


From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr  4 19:42:55 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 04 Apr 2009 17:42:55 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87wsa2thqu.fsf@xemacs.org>
Message-ID: <49D79BEB.2060900@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thing is, what *pending* means is that a developer has *already*
> "expressed interest", and found themselves *blocked* for lack of
> information.

You completely misunderstand. It means something entirely different.

It means that whoever looked at the issue thinks it should be closed,
but on the off-chance that somebody might object, sets it to pending
only. No developer is interested anymore - it's about to be closed.

Regards,
Martin

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue16>
_______________________________________________________

From martin at v.loewis.de  Sat Apr  4 20:28:16 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 04 Apr 2009 20:28:16 +0200
Subject: [Tracker-discuss] Issue tags
In-Reply-To: <49D7661B.7070509@python.org>
References: <49D7661B.7070509@python.org>
Message-ID: <49D7A6C0.8090006@v.loewis.de>

> at PyCon, the question came up whether to reorganize the components list
> and replace most of them by a new comma-separated list of (arbitrary) tags.
> 
> These should contain the module name, if the report refers to one.  It can
> also take additional values which we'd have to define.

I think this isn't trivial to implement. I also wonder whether we want
to keep auto-assignment for these tags.

Martin

From tleeuwenburg at gmail.com  Sun Apr  5 07:39:47 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Sun, 5 Apr 2009 15:39:47 +1000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <49D79BEB.2060900@v.loewis.de>
References: <bbaeab100904012246he44c90kc97e42eddadc79a@mail.gmail.com>
	<18901.2042.732024.331634@montanaro.dyndns.org>
	<87wsa2thqu.fsf@xemacs.org> <49D79BEB.2060900@v.loewis.de>
Message-ID: <43c8685c0904042239wc970120q7c290ff878b00cd3@mail.gmail.com>

I would just like to repeat that the name "pending" is apparently a frequent
cause of confusion. I think perhaps it should be renamed to "pending
closure" in order to make its purpose more clear.

On Sun, Apr 5, 2009 at 3:42 AM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> > Thing is, what *pending* means is that a developer has *already*
> > "expressed interest", and found themselves *blocked* for lack of
> > information.
>
> You completely misunderstand. It means something entirely different.
>
> It means that whoever looked at the issue thinks it should be closed,
> but on the off-chance that somebody might object, sets it to pending
> only. No developer is interested anymore - it's about to be closed.
>
> Regards,
> Martin
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>



-- 
--------------------------------------------------
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090405/b08565b0/attachment.htm>

From stephen at xemacs.org  Sun Apr  5 14:32:47 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 05 Apr 2009 21:32:47 +0900
Subject: [Tracker-discuss]  [issue16] Automatic issue expiration
In-Reply-To: <49D79BEB.2060900@v.loewis.de>
References: <87wsa2thqu.fsf@xemacs.org>
	<49D79BEB.2060900@v.loewis.de>
Message-ID: <87bprbth5c.fsf@xemacs.org>

"Martin v. L?wis" writes:

 > It means that whoever looked at the issue thinks it should be closed,
 > but on the off-chance that somebody might object, sets it to pending
 > only. No developer is interested anymore - it's about to be closed.

Sorry for the confusion.

But what's the point of "pending", then?  It seems something that
would be rarely useful.  Somebody with presumably good judgment has
decided it's not interesting, and people who know they care about the
issue will be in the nosy list in "most" cases.  If you must keep it,
then it should be renamed as Tennessee says.

Something like "resolved" would be fine.  At least native speakers who
ask "what's the difference between 'resolved' and 'closed'?" who are
told "resolved issues are displayed in lists by default, closed issues
are hidden" should never need to ask again.  I bet most non-natives
will catch on to that distinction quickly, too.

But I would just nuke the whole status as an unnecessary complexity.

From martin at v.loewis.de  Sun Apr  5 20:05:57 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 05 Apr 2009 20:05:57 +0200
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87bprbth5c.fsf@xemacs.org>
References: <87wsa2thqu.fsf@xemacs.org>	<49D79BEB.2060900@v.loewis.de>
	<87bprbth5c.fsf@xemacs.org>
Message-ID: <49D8F305.5030102@v.loewis.de>

> But what's the point of "pending", then?  It seems something that
> would be rarely useful.

On SourceForge, I have used it quite often. I use it in cases like
a) "I assume (although you didn't say) you did this and that,
    which cannot work because of such and such. Will close the
   issue soon."
b) "It's been a long time. If you are still interesting in pursuing
   the issue, please let us know."

>  Somebody with presumably good judgment has
> decided it's not interesting, and people who know they care about the
> issue will be in the nosy list in "most" cases.  If you must keep it,
> then it should be renamed as Tennessee says.

I'm not a native speaker of English; it doesn't mean much to me.
It's called Pending in roundup because that's what it was called
on SF.


From metatracker at psf.upfronthosting.co.za  Sun Apr  5 20:15:21 2009
From: metatracker at psf.upfronthosting.co.za (Gregory P. Smith)
Date: Sun, 05 Apr 2009 18:15:21 +0000
Subject: [Tracker-discuss] [issue260] Consider using a nice editor for the
	Comment: field -	CodeMirror javascript
In-Reply-To: <1238955321.66.0.216012375046.issue260@psf.upfronthosting.co.za>
Message-ID: <1238955321.66.0.216012375046.issue260@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

The Comment: field of the python bug tracker could be made nicer by using

http://marijn.haverbeke.nl/codemirror/

instead of a plan text box.

----------
messages: 1297
nosy: greg
priority: feature
status: unread
title: Consider using a nice editor for the Comment: field - CodeMirror javascript

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue260>
_______________________________________________________

From georg at python.org  Sun Apr  5 20:48:55 2009
From: georg at python.org (Georg Brandl)
Date: Sun, 05 Apr 2009 20:48:55 +0200
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <49D8F305.5030102@v.loewis.de>
References: <87wsa2thqu.fsf@xemacs.org>	<49D79BEB.2060900@v.loewis.de>	<87bprbth5c.fsf@xemacs.org>
	<49D8F305.5030102@v.loewis.de>
Message-ID: <49D8FD17.6040804@python.org>

Martin v. L?wis schrieb:
>> But what's the point of "pending", then?  It seems something that
>> would be rarely useful.
> 
> On SourceForge, I have used it quite often. I use it in cases like
> a) "I assume (although you didn't say) you did this and that,
>     which cannot work because of such and such. Will close the
>    issue soon."
> b) "It's been a long time. If you are still interesting in pursuing
>    the issue, please let us know."

FWIW, from me also a strong +1 for "pending" with the discussed semantics.

Georg



From metatracker at psf.upfronthosting.co.za  Sun Apr  5 21:18:58 2009
From: metatracker at psf.upfronthosting.co.za (R David Murray)
Date: Sun, 05 Apr 2009 19:18:58 +0000
Subject: [Tracker-discuss] [issue261] copyright dates need updating
In-Reply-To: <1238959138.85.0.247437190711.issue261@psf.upfronthosting.co.za>
Message-ID: <1238959138.85.0.247437190711.issue261@psf.upfronthosting.co.za>


New submission from R David Murray <rdmurray at bitdance.com>:

I just noticed the copyright date range on the bottom of the tracker pages says
'1990-2006'.  Shouldn't that be updated to '-2009'?

----------
messages: 1298
nosy: r.david.murray
priority: bug
status: unread
title: copyright dates need updating

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue261>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 01:23:07 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 05 Apr 2009 23:23:07 +0000
Subject: [Tracker-discuss] [issue261] copyright dates need updating
In-Reply-To: <1238959138.85.0.247437190711.issue261@psf.upfronthosting.co.za>
Message-ID: <2d75d7660904051622n783cb0c7h60499a5013db2d67@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Yep, here's a patch :)

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue261>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2009.diff
Type: text/x-diff
Size: 767 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090405/ef85453c/attachment.diff>

From ajaksu at gmail.com  Mon Apr  6 02:41:59 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Sun, 5 Apr 2009 21:41:59 -0300
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <87bprbth5c.fsf@xemacs.org>
References: <87wsa2thqu.fsf@xemacs.org> <49D79BEB.2060900@v.loewis.de> 
	<87bprbth5c.fsf@xemacs.org>
Message-ID: <2d75d7660904051741v79325674g5888ed4d564a4514@mail.gmail.com>

Stephen J. Turnbull wrote:
> "Martin v. L?wis" writes:
>
> ?> It means that whoever looked at the issue thinks it should be closed,
> ?> but on the off-chance that somebody might object, sets it to pending
> ?> only. No developer is interested anymore - it's about to be closed.
>
> Sorry for the confusion.
>
> But what's the point of "pending", then? ?It seems something that
> would be rarely useful.

Here's a sample of how I use it: http://tinyurl.com/ajaksu-pending
(BTW, it seems I've misused it by setting some issues to pending
without a warning or call for feedback). In the set of all pending
issues (http://tinyurl.com/all-pending ), some look like clickos
('closed' intended) and others look like different interpretations of
'pending' (e.g. http://bugs.python.org/issue4751 ).

> ?Somebody with presumably good judgment has
> decided it's not interesting,

Given my usual lack of good judgment, pending is a nice crutch :)

> and people who know they care about the
> issue will be in the nosy list in "most" cases.

Ah, but some of these bugs are six years old, so setting them to
pending bumps them to the top of the activity queue with (supposedly)
a 'this is being considered for closing, voice your opposition if you
care about it' message.

> ?If you must keep it,
> then it should be renamed as Tennessee says.

+0. I'd rather have a tooltip explaining it a bit more, as "pending
closure" isn't that clear to my non-native eyes. +1 on something
unambiguous that makes the tooltip unnecessary  :)

> Something like "resolved" would be fine. ?At least native speakers who
> ask "what's the difference between 'resolved' and 'closed'?" who are
> told "resolved issues are displayed in lists by default, closed issues
> are hidden" should never need to ask again. ?I bet most non-natives
> will catch on to that distinction quickly, too.

-1, IMO 'pending' is almost 'pending a more correct status, tending to
close': if nobody cares (or someone strongly wants the issue closed),
the correct status is closed, if someone opposes, the status should be
open. See:
http://bugs.python.org/issue1569040 - interested party is nosy
http://bugs.python.org/issue1542544 - interested party isn't nosy
http://bugs.python.org/issue5608 - interested party isn't nosy, knows
it should be closed

> But I would just nuke the whole status as an unnecessary complexity.

-1, that would force everyone to change their tracker use and add
stronger meanings to e.g. stage :)

Best regards,
Daniel

From rdmurray at bitdance.com  Mon Apr  6 03:34:33 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 5 Apr 2009 21:34:33 -0400 (EDT)
Subject: [Tracker-discuss] text search results question
Message-ID: <Pine.LNX.4.64.0904052132110.26362@kimball.webabinitio.net>

I just did a search with 'atheos' in the text box.  It returned a
list of 9 tickets, only two of which actually had the word 'atheos'
anywhere on the page that was displayed by clicking on the ticket.
Is there something I'm not understanding about how search works, or is
this a bug?  (By the way, I closed one of the bugs that was a valid hit,
so there are only 8 results returned now.)

--David

From ajaksu at gmail.com  Mon Apr  6 03:53:08 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Sun, 5 Apr 2009 22:53:08 -0300
Subject: [Tracker-discuss] text search results question
In-Reply-To: <Pine.LNX.4.64.0904052132110.26362@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0904052132110.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904051853w9be8478w283e26408c958a7b@mail.gmail.com>

R. David Murray wrote:
> I just did a search with 'atheos' in the text box. ?It returned a
> list of 9 tickets, only two of which actually had the word 'atheos'
> anywhere on the page that was displayed by clicking on the ticket.
> Is there something I'm not understanding about how search works, or is
> this a bug? ?(By the way, I closed one of the bugs that was a valid hit,
> so there are only 8 results returned now.)

The files/patches attached are included in a 'All text' search. And
yes, it's a PITA. I'll fill a bug report/RFE to add 'All text
excluding files' in a couple of minutes :)

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 05:47:49 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 06 Apr 2009 03:47:49 +0000
Subject: [Tracker-discuss] [issue262] Ignore file content in 'All text'
	search
In-Reply-To: <1238989669.77.0.307325287973.issue262@psf.upfronthosting.co.za>
Message-ID: <1238989669.77.0.307325287973.issue262@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Searching for terms using the top-right searchbox or the "All text" input in the
search page often includes spurious issues where the match is restricted to
attached files.

This patch offers an interface to allow excluding
"class:property,class1:property1" pairs from the results set. It can be used to,
e.g., find issues with 'atheos' anywhere except:
  in attached files ('file:content', the default);
  in issue titles ('issue:title');
  in attached files or in issue titles ('file:content,issue:title').

[1] http://mail.python.org/pipermail/tracker-discuss/2009-April/002058.html

----------
files: ignore_files_template.diff
messages: 1300
nosy: ajaksu2, r.david.murray
priority: feature
status: unread
title: Ignore file content in 'All text' search

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue262>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ignore_files_template.diff
Type: text/x-diff
Size: 1580 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090406/3b0e2af8/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 05:49:16 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 06 Apr 2009 03:49:16 +0000
Subject: [Tracker-discuss] [issue262] Ignore file content in 'All text'
	search
In-Reply-To: <1238989669.77.0.307325287973.issue262@psf.upfronthosting.co.za>
Message-ID: <1238989756.41.0.220126965284.issue262@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This patch adds the ability to ignore "class:property" pairs to Roundup
(templating.py).

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue262>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ignore_files_roundup.diff
Type: text/x-diff
Size: 1702 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090406/07eecc35/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 06:00:34 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 06 Apr 2009 04:00:34 +0000
Subject: [Tracker-discuss] [issue260] Consider using a nice editor for the
	Comment: field -	CodeMirror javascript
In-Reply-To: <1238955321.66.0.216012375046.issue260@psf.upfronthosting.co.za>
Message-ID: <1238990434.62.0.0181205527096.issue260@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

-1 yucky, but I guess I could selectively disable the editor JS and live with it.

If we're to add fancy input/output to the tracker, I'd rather go the other way:
allow a safe subset of ReST, enough to handle source highlighting, lists, etc.,
and render it with Sphinx.

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue260>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 06:03:20 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 06 Apr 2009 04:03:20 +0000
Subject: [Tracker-discuss] [issue244] Any User can hijack other Users'
	Queries
In-Reply-To: <1235599259.83.0.0315928724687.issue244@psf.upfronthosting.co.za>
Message-ID: <1238990600.55.0.919838286703.issue244@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I don't think so, cannot trigger it anymore. I'll reopen it or a new one if I
find otherwise.

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue244>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 06:52:16 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 06 Apr 2009 04:52:16 +0000
Subject: [Tracker-discuss] [issue249] message_count and nosy_count changes
	appear in every mail
In-Reply-To: <1236644335.96.0.047685692214.issue249@psf.upfronthosting.co.za>
Message-ID: <1238993536.87.0.990208205384.issue249@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Here's a cleaner version, I'll submit the roundup part upstream.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue249>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omit_count_instance3.diff
Type: text/x-diff
Size: 3888 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090406/8e6d1e73/attachment-0001.diff>

From martin at v.loewis.de  Mon Apr  6 07:06:01 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 06 Apr 2009 07:06:01 +0200
Subject: [Tracker-discuss] text search results question
In-Reply-To: <2d75d7660904051853w9be8478w283e26408c958a7b@mail.gmail.com>
References: <Pine.LNX.4.64.0904052132110.26362@kimball.webabinitio.net>
	<2d75d7660904051853w9be8478w283e26408c958a7b@mail.gmail.com>
Message-ID: <49D98DB9.9060401@v.loewis.de>

Daniel (ajax) Diniz wrote:
> R. David Murray wrote:
>> I just did a search with 'atheos' in the text box.  It returned a
>> list of 9 tickets, only two of which actually had the word 'atheos'
>> anywhere on the page that was displayed by clicking on the ticket.
>> Is there something I'm not understanding about how search works, or is
>> this a bug?  (By the way, I closed one of the bugs that was a valid hit,
>> so there are only 8 results returned now.)
> 
> The files/patches attached are included in a 'All text' search. And
> yes, it's a PITA. 

I disagree that it is painful. It may be surprising at first, but then
it is useful.

Regards,
Martin

From ajaksu at gmail.com  Mon Apr  6 08:32:59 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 6 Apr 2009 03:32:59 -0300
Subject: [Tracker-discuss] text search results question
In-Reply-To: <49D98DB9.9060401@v.loewis.de>
References: <Pine.LNX.4.64.0904052132110.26362@kimball.webabinitio.net> 
	<2d75d7660904051853w9be8478w283e26408c958a7b@mail.gmail.com> 
	<49D98DB9.9060401@v.loewis.de>
Message-ID: <2d75d7660904052332v36299412v4cba74543dc9c878@mail.gmail.com>

"Martin v. L?wis"  wrote:
> Daniel (ajax) Diniz wrote:
>> The files/patches attached are included in a 'All text' search. And
>> yes, it's a PITA.
>
> I disagree that it is painful. It may be surprising at first, but then
> it is useful.

It can be useful, but when you try to, e.g., list all issues for the
'struct' (or 'errno', or, to a lesser degree, 'socket') module it is a
PITA. Now, one of the GSoC ideas I posted was about the open issues in
the struct module, another was about issues for socket, so I may be
slightly biased here :)

I've filled a RFE that allows choosing whether to include files in
'All text' searches[1] and I think it can be pretty useful. However,
I'm not sure the UI is adequate: text input might be confusing, not
well placed, etc. Also, making 'ignore file content' option the
default is questionable, I did it mostly to have an example in the
ignore text input.

Best regards,
Daniel

http://psf.upfronthosting.co.za/roundup/meta/issue262

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 14:54:02 2009
From: metatracker at psf.upfronthosting.co.za (R David Murray)
Date: Mon, 06 Apr 2009 12:54:02 +0000
Subject: [Tracker-discuss] [issue260] Consider using a nice editor for
	the	Comment: field	-	CodeMirror javascript
In-Reply-To: <1238990434.62.0.0181205527096.issue260@psf.upfronthosting.co.za>
Message-ID: <Pine.LNX.4.64.0904060849080.26362@kimball.webabinitio.net>


R David Murray <rdmurray at bitdance.com> added the comment:

On Mon, 6 Apr 2009 at 04:00, Daniel Diniz wrote:
> Daniel Diniz <ajaksu at gmail.com> added the comment:
>
> -1 yucky, but I guess I could selectively disable the editor JS and live with it.

Agree.  I just pop out to vi when I need to do editing tasks that are
hard in the text box.

> If we're to add fancy input/output to the tracker, I'd rather go the other way:
> allow a safe subset of ReST, enough to handle source highlighting, lists, etc.,
> and render it with Sphinx.

Agree here, as well.  However, I'm not certain that the benefit would be
significant, and there might be issues that naive new users would trip
over, which would be a negative (and is also a negative for the fancy
javascript, IMO...consider that pasting code snippets is an important
part of updating tracker issues).

--David

----------
nosy: +r.david.murray
title: Consider using a nice editor for the Comment: field - CodeMirror javascript -> Consider using a nice editor for the	Comment: field -	CodeMirror javascript

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue260>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr  6 17:17:19 2009
From: metatracker at psf.upfronthosting.co.za (Quentin Gallet-Gilles)
Date: Mon, 06 Apr 2009 15:17:19 +0000
Subject: [Tracker-discuss] [issue263] Email not always sent to
	Python-bugs-list, depending on the user
In-Reply-To: <1239031039.27.0.209933652376.issue263@psf.upfronthosting.co.za>
Message-ID: <1239031039.27.0.209933652376.issue263@psf.upfronthosting.co.za>


New submission from Quentin Gallet-Gilles <qgallet at gmail.com>:

It seems lately that no mail is sent from the tracker to the python-bugs-list
when the message is from Kristj?n Valur J?nsson (userid: krisvale). It's
possible there are other users causing this same behavior, but Kristj?n is the
first user where I noticed the problem happening consistently.

For instance, issue5646 ( http://bugs.python.org/issue5646 ) shows 8 messages,
yet only 4 made it to the list archive (
http://mail.python.org/pipermail/python-bugs-list/2009-April/thread.html ).

----------
messages: 1306
nosy: quentin.gallet-gilles
priority: bug
status: unread
title: Email not always sent to Python-bugs-list, depending on the user

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue263>
_______________________________________________________

From ajaksu at gmail.com  Mon Apr  6 20:37:49 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 6 Apr 2009 15:37:49 -0300
Subject: [Tracker-discuss] Issue tags
In-Reply-To: <49D7A6C0.8090006@v.loewis.de>
References: <49D7661B.7070509@python.org> <49D7A6C0.8090006@v.loewis.de>
Message-ID: <2d75d7660904061137q1463da50h4d89dda49b87da08@mail.gmail.com>

"Martin v. L?wis" wrote:
>> at PyCon, the question came up whether to reorganize the components list
>> and replace most of them by a new comma-separated list of (arbitrary) tags.
>>
>> These should contain the module name, if the report refers to one. ?It can
>> also take additional values which we'd have to define.
>
> I think this isn't trivial to implement. I also wonder whether we want
> to keep auto-assignment for these tags.

A "comma-separated list of (arbitrary) tags" could be trivial,  but
perhaps not very useful, if we make it a String. That would make
auto-assignment (or auto-nosy) harder, but still possible.

To make the tags more useful, we could implement the list as a
Multilink like keywords, with a comma-separated input interface like
those for nosy. Then, the 'arbitrary' part becomes the problem: do we
want users to be able to create arbitrary, tracker-wide tags? (no, we
don't, you might think we do but that'd be mistaken :D).

I think this idea is worth floating in python-dev: if most people want
this I can implement it, but I'd like to keep most components we have
now.

Regards,
Daniel

From stephen at xemacs.org  Tue Apr  7 08:18:32 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 07 Apr 2009 15:18:32 +0900
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <49D8F305.5030102@v.loewis.de>
References: <87wsa2thqu.fsf@xemacs.org> <49D79BEB.2060900@v.loewis.de>
	<87bprbth5c.fsf@xemacs.org> <49D8F305.5030102@v.loewis.de>
Message-ID: <871vs5t29z.fsf@xemacs.org>

"Martin v. L?wis" writes:
 > > But what's the point of "pending", then?  It seems something that
 > > would be rarely useful.
 > 
 > On SourceForge, I have used it quite often. I use it in cases like
 > a) "I assume (although you didn't say) you did this and that,
 >     which cannot work because of such and such. Will close the
 >    issue soon."
 > b) "It's been a long time. If you are still interesting in pursuing
 >    the issue, please let us know."

OK, that's very much the way I would use it.  I guess we're both
talking mostly about situations where the issue can be closed unless
the OP (less likely, some third party) has something to say about it.

 > I'm not a native speaker of English[.]

You keep saying that, but you keep fooling me.  As far as usage, your
usage of the tracker status conforms to my expectation.  I can easily
imagine having an identical conversation with a native speaker.


From metatracker at psf.upfronthosting.co.za  Tue Apr  7 18:48:11 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 07 Apr 2009 16:48:11 +0000
Subject: [Tracker-discuss] [issue264] Mail gateway borks quotes and console
	sessions
In-Reply-To: <1239122891.37.0.849970456048.issue264@psf.upfronthosting.co.za>
Message-ID: <1239122891.37.0.849970456048.issue264@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Antoine Pitrou reported the issue that Roundup borks email responses containing
lines stating with '>' [1][2][3]. I've tracked it down to mailgw.parseContent
wrongly discarding sections bits.

Attached script shows this behavior.

[1] http://bugs.python.org/msg82084
[2] http://bugs.python.org/msg85439
[3] http://bugs.python.org/msg70718

Antoine Pitrou wrote:
The problem I'm having often is that quoted text, or snippets of interpreter
sessions, are lost. Basically, everything which begins with one or more '>'
signs is threatened.

----------
files: pc.py
messages: 1307
nosy: ajaksu2
priority: bug
status: unread
title: Mail gateway borks quotes and console sessions

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue264>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pc.py
Type: text/x-python
Size: 3642 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090407/2be71948/attachment.py>

From metatracker at psf.upfronthosting.co.za  Tue Apr  7 18:50:37 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 07 Apr 2009 16:50:37 +0000
Subject: [Tracker-discuss] [issue264] Mail gateway borks quotes and console
	sessions
In-Reply-To: <1239122891.37.0.849970456048.issue264@psf.upfronthosting.co.za>
Message-ID: <1239123037.29.0.535082782593.issue264@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This patch fixes the symptom, I'll try to find the cause and fix it. This will
probably lead to a lot more noise reaching the tracker if committed as-is.

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue264>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quotes_interactive.diff
Type: text/x-diff
Size: 732 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090407/fca886c7/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Tue Apr  7 19:29:27 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 07 Apr 2009 17:29:27 +0000
Subject: [Tracker-discuss] [issue264] Mail gateway borks quotes and console
	sessions
In-Reply-To: <1239122891.37.0.849970456048.issue264@psf.upfronthosting.co.za>
Message-ID: <1239125367.48.0.455031176497.issue264@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

In the original code, a for-else is used with wrong logic, so that if there was
a response ('no blank line between quoted message and response') in the section,
the loop would break and not execute the else[1]. Unfortunately, the code that
checks whether to include the quoted text verbatim is inside the else clause.

Attached patch fixes this and reorganizes the code a bit.

[1] http://docs.python.org/reference/compound_stmts.html#the-for-statement

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue264>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_quotes.diff
Type: text/x-diff
Size: 2175 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090407/eda64e82/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Wed Apr  8 02:00:42 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 08 Apr 2009 00:00:42 +0000
Subject: [Tracker-discuss] [issue265] Search in the top search box broken
	for empty input
In-Reply-To: <1239148841.99.0.456266039624.issue265@psf.upfronthosting.co.za>
Message-ID: <1239148841.99.0.456266039624.issue265@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Clicking on the top search buttons when the input is empty causes an error. The
patch I submitted to allow entering issue IDs in the search box broke it.

Attached patch fixes this.

----------
files: search_empty.diff
messages: 1310
nosy: ajaksu2
priority: bug
status: unread
title: Search in the top search box broken for empty input

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue265>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search_empty.diff
Type: text/x-diff
Size: 458 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090408/93da6213/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Wed Apr  8 02:12:13 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 08 Apr 2009 00:12:13 +0000
Subject: [Tracker-discuss] [issue266] Buttons to add/remove self from nosy
	list, assign issue to self
In-Reply-To: <1239149532.95.0.77008083815.issue266@psf.upfronthosting.co.za>
Message-ID: <1239149532.95.0.77008083815.issue266@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Makes assigning an issue to self and adding/removing self to/from the nosy list
easier. This patch adds two helper buttons that are hidden by default and set
visible by JS, so users with JS disabled won't see them.

Clicking on the 'Claim' button sets the user as assignee. The nosy button start
values is either 'Add myself' or 'Remove myself', according to whether the user
is already present in the nosy list. Clicking it adds or removes the user
to/from the list, toggling the button value.

My JS is even worse than my Python (even after JSLint), so any feedback is most
welcome.

Thanks Ezio Melotti for the nice RFE :)

----------
files: add_self.diff
messages: 1311
nosy: ajaksu2
priority: feature
status: unread
title: Buttons to add/remove self from nosy list, assign issue to self

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue266>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_self.diff
Type: text/x-diff
Size: 3112 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090408/73351d96/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Wed Apr  8 03:05:19 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 08 Apr 2009 01:05:19 +0000
Subject: [Tracker-discuss] [issue266] Buttons to add/remove self from nosy
	list, assign issue to self
In-Reply-To: <1239149532.95.0.77008083815.issue266@psf.upfronthosting.co.za>
Message-ID: <1239152719.74.0.630948310538.issue266@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Some improvements in the JS code.

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue266>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_self2.patch
Type: text/x-diff
Size: 3009 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090408/a72214f0/attachment.patch>

From metatracker at psf.upfronthosting.co.za  Wed Apr  8 04:47:14 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 08 Apr 2009 02:47:14 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

I've seen many people delete messages by accident. Recently, Guilherme Polo
posted a workaround for re-adding them[1]. I've only added UI and a way to store
the issue ID on unlinking.

This patch adds an auditor to that stores the issue ID on a removed file or
message, and offers a 'restore' button on message or file item pages that allows
re-linking to the original issue.

The restore form is only shown for messages/files the unlink auditor marked with
an issue ID.

I'd also like to add JS guards (confirmations) to the remove buttons, will
provide a patch after most issue.item.html patches land.

[1] http://bugs.python.org/msg84430

----------
files: undo_remove.diff
messages: 1313
nosy: ajaksu2
priority: bug
status: unread
title: Make the 'remove' buttons less annoying

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo_remove.diff
Type: text/x-diff
Size: 3583 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090408/94f729e4/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Wed Apr  8 20:43:21 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Wed, 08 Apr 2009 18:43:21 +0000
Subject: [Tracker-discuss] [issue268] Add contributor agreement and
	committer status information
In-Reply-To: <1239216201.07.0.276549739609.issue268@psf.upfronthosting.co.za>
Message-ID: <1239216201.07.0.276549739609.issue268@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

User accounts should be extended to indicate that the user has signed a
contributor agreement, and what his committer ID is. For the latter, it might be
sensible to allow multiple values: for svn, several committer have used various
names over time (back to CVS days), and for mercurial, it might be necessary to
store mutiple email addresses.

----------
messages: 1314
nosy: loewis
priority: feature
status: unread
title: Add contributor agreement and committer status information

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue268>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Apr  9 01:33:20 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 08 Apr 2009 23:33:20 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239233600.27.0.739808542749.issue267@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Cleaner auditor.

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo_remove2.diff
Type: text/x-diff
Size: 3550 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090408/c53424f1/attachment.diff>

From fwierzbicki at gmail.com  Fri Apr 10 17:34:09 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Fri, 10 Apr 2009 11:34:09 -0400
Subject: [Tracker-discuss] tracker unreachable
Message-ID: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>

Hi all,

It looks like the tracker is unreachable at the moment.  I can't get to

http://psf.upfronthosting.co.za/roundup/meta/
http://bugs.python.org
http://bugs.jython.org

-Frank

From martin at v.loewis.de  Fri Apr 10 18:21:10 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 10 Apr 2009 18:21:10 +0200
Subject: [Tracker-discuss] tracker unreachable
In-Reply-To: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>
References: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>
Message-ID: <49DF71F6.70907@v.loewis.de>

> It looks like the tracker is unreachable at the moment.  I can't get to
> 
> http://psf.upfronthosting.co.za/roundup/meta/
> http://bugs.python.org
> http://bugs.jython.org

Yes, the server is down, and Upfronthosting can't reach anybody in the
data center today.

Regards,
Martin

From metatracker at psf.upfronthosting.co.za  Sat Apr 11 11:50:32 2009
From: metatracker at psf.upfronthosting.co.za (Frank Wierzbicki)
Date: Sat, 11 Apr 2009 09:50:32 +0000
Subject: [Tracker-discuss] [issue269] tracker unreachable
In-Reply-To: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>
Message-ID: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

Hi all,

It looks like the tracker is unreachable at the moment.  I can't get to

http://psf.upfronthosting.co.za/roundup/meta/
http://bugs.python.org
http://bugs.jython.org

-Frank

----------
messages: 1316
nosy: fwierzbicki
status: unread
title: tracker unreachable

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue269>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 11 15:01:42 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 11 Apr 2009 13:01:42 +0000
Subject: [Tracker-discuss] [issue269]  tracker unreachable
In-Reply-To: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>
Message-ID: <49DF71F6.70907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It looks like the tracker is unreachable at the moment.  I can't get to
> 
> http://psf.upfronthosting.co.za/roundup/meta/
> http://bugs.python.org
> http://bugs.jython.org

Yes, the server is down, and Upfronthosting can't reach anybody in the
data center today.

Regards,
Martin

----------
nosy: +loewis
status: unread -> chatting
title: tracker unreachable -> [Tracker-discuss] tracker unreachable

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue269>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Apr 12 23:35:58 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 12 Apr 2009 21:35:58 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

These patches fix some issues introduced in 1.4.7, including:
  - fix action taken in response to invalid GET request
  - fix templates to submit POST requests when appropriate
  - fix bug introduced into CVS export and view (issue 2550529)
  - fix TLS handling with some SMTP servers (issues 2484879 and 1912923)

The fixes_1.4.8.diff patch has only the changes to roundup/*.

----------
files: fixes_1.4.8.diff
messages: 1318
nosy: ajaksu2
priority: bug
status: unread
title: Upgrade to 1.4.8

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixes_1.4.8.diff
Type: text/x-diff
Size: 6660 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090412/06d1dde1/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Sun Apr 12 23:38:21 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 12 Apr 2009 21:38:21 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239572301.78.0.641439809276.issue270@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

upgrade_1.4.8.diff contains both the roundup/* fixes and a bunch of
non-significant changes (e.g. to the classic template, release notes, etc.)

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upgrade_1.4.8.diff
Type: text/x-diff
Size: 18581 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090412/b122804e/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Sun Apr 12 23:47:30 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 12 Apr 2009 21:47:30 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239572850.74.0.592295192643.issue270@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

python-dev_1.4.8.diff updates detectors and HTML templates to new 1.4.8
functionality. Changes are mostly about "roundup.anypy.sets_", the "Retire"
permission for users and using "method='post'" where necessary.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-dev_1.4.8.diff
Type: text/x-diff
Size: 10568 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090412/519c4db8/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr 13 01:24:08 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 12 Apr 2009 23:24:08 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239578648.46.0.992277641139.issue267@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Enhanced auditor to fix a minor security hole: any User can link/unlink files
and messages to/from any issue.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo_and_audit_remove.diff
Type: text/x-diff
Size: 5070 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090412/ec072bc7/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr 13 01:56:41 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 12 Apr 2009 23:56:41 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239580601.61.0.141476547091.issue267@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Fix typo.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo_and_audit_remove.diff
Type: text/x-diff
Size: 5097 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090412/e094ce8f/attachment-0001.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 13 14:39:39 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 13 Apr 2009 12:39:39 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239626379.72.0.882663996307.issue270@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is it necessary to spell the method in lower case?

I don't think we need to 2.3 compatibility, the the anypy import of set is
unnecessary (IMO).

I'd rather see this patch restricted to what is really necessary for 1.4.8
upgrade, so:
- I have already committed the typo in file.index.html (thanks!)
- I wonder why _generic.help now uses "structure"

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 13 14:46:25 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 13 Apr 2009 12:46:25 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239626785.79.0.464626738913.issue267@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's wrong with allowing users to unlink arbitrary files? Anybody who has
write access to the files property should be allowed to do so.

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 13 18:55:35 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 13 Apr 2009 16:55:35 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239626785.79.0.464626738913.issue267@psf.upfronthosting.co.za>
Message-ID: <2d75d7660904130955o6a63fb0bwb1bf8086387087e@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Martin v. L?wis wrote::
> What's wrong with allowing users to unlink arbitrary files? Anybody who has
> write access to the files property should be allowed to do so.

I thought the write access was about adding new files, while removing
files should be restricted to those the user has created. At least the
UI only renders the 'remove button' according to the permission below:

def may_edit_file(db, userid, itemid):
    return userid == db.file.get(itemid, "creator")
p = db.security.addPermission(name='Edit', klass='file', check=may_edit_file,
    description="User is allowed to remove their own files")
db.security.addPermissionToRole('User', p)

However, it's possible to perform the Edit action on any files even if
the remove button isn't shown:
http://localhost:9999/python-dev/issue2169?@action=edit&@remove at files=29

IMO this makes it easier to disrupt tracker work, besides making it
trivial replace valid files/patches with exploit-ish ones.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 13 19:38:26 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 13 Apr 2009 17:38:26 +0000
Subject: [Tracker-discuss] [issue267] Make the 'remove' buttons less annoying
In-Reply-To: <1239158834.9.0.636756137699.issue267@psf.upfronthosting.co.za>
Message-ID: <1239644306.67.0.122834333396.issue267@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This new version forbids re-linking an already linked file or message to
another issues.

If any part of this patch is desirable, maybe it'd be better to split it into
'allow restoring' and 'audit linking/unlinking' detectors?

Also tracked at http://issues.roundup-tracker.org/issue2550536

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue267>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undo_and_audit_remove2.diff
Type: text/x-diff
Size: 5433 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090413/f226332b/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr 13 20:19:53 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 13 Apr 2009 18:19:53 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239626379.72.0.882663996307.issue270@psf.upfronthosting.co.za>
Message-ID: <2d75d7660904131119i1ff329cdu6918419835eda46b@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Martin v. L?wis wrote:
> Why is it necessary to spell the method in lower case?

Not necessary, but it is the correct way for the doctype we use:
http://tinyurl.com/tracker-validation (it's also already in lower case
in page.html). Since I had to add 'method="post"' to some forms (that
wouldn't work without it after the upgrade), I standardized on lower
case and later made all forms use this spelling.

Should I keep this change (lowercasing existing POSTs) out of the 1.4.8 patch?

I want to fix the other validation issues too, before adding some
template RFEs (like anchors for messages in issue view, so you can
link to a message in its context, element ids, etc.).

> I don't think we need to 2.3 compatibility, the the anypy import of set is
> unnecessary (IMO).

I'd like to gradually make our template more general were it doesn't
cause us harm. I'm fine with relying on set() being built-in and I can
edit the patch on that assumption. But the fact that our
nosyreaction.py still uses "import sets [...] sets.Set()" makes me
think that the least we diverge from upstream (without creating more
work for us), the better.

IMHO, both explicitly targeting a specific (set of) version(s) or
using the anypy helper could help us make our detectors better and
less prone to bit-rot. So, what would you prefer: target 2.4 and above
(2.x), target  2.4-2.6, rely on anypy, something else?

> I'd rather see this patch restricted to what is really necessary for 1.4.8
> upgrade, so:
> - I have already committed the typo in file.index.html (thanks!)
> - I wonder why _generic.help now uses "structure"

The patch makes it stop using structure, which fixes some security
issues in the helpers: structure means "do not encode '<' and '>' ",
making it possible to use raw html there. As Richard said, some of our
problems in this area are fixed upstream in the classic template.

I'll re-create the patch based on your feedback, thanks for reviewing!

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 13 20:32:56 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 13 Apr 2009 18:32:56 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <2d75d7660904131119i1ff329cdu6918419835eda46b@mail.gmail.com>
Message-ID: <49E38554.9020104@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Should I keep this change (lowercasing existing POSTs) out of the 1.4.8 patch?

Yes, please. A "it now validates" patch would be better.

> I'd like to gradually make our template more general were it doesn't
> cause us harm. I'm fine with relying on set() being built-in and I can
> edit the patch on that assumption. But the fact that our
> nosyreaction.py still uses "import sets [...] sets.Set()" makes me
> think that the least we diverge from upstream (without creating more
> work for us), the better.

Ok, patching detectors to match more closely the upstream reactors
is good (i.e. if a fragment is in 1.4.8, it has a place in this patch).

Stuff that is *not* in the upstream code does not belong into this
patch. Wrt. 2.3 support, I think any effort in providing it is wasted.

> IMHO, both explicitly targeting a specific (set of) version(s) or
> using the anypy helper could help us make our detectors better and
> less prone to bit-rot. So, what would you prefer: target 2.4 and above
> (2.x), target  2.4-2.6, rely on anypy, something else?

I disagree that the python-dev tracker is the place to start
a generic reusable template. Feel free to contribute it to roundup,
and perhaps talk roundup maintainers into making it a new template,
but leave this project please out of our instances.

The tracker instance is *not* reusable. It is tightly integrated
with the rest of python.org in terms of layout, and it should
stay that way.

>> - I wonder why _generic.help now uses "structure"
> 
> The patch makes it stop using structure, which fixes some security
> issues in the helpers: structure means "do not encode '<' and '>' ",
> making it possible to use raw html there. As Richard said, some of our
> problems in this area are fixed upstream in the classic template.

Ah, ok. That's fine, then.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 13 20:35:08 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 13 Apr 2009 18:35:08 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239647708.06.0.941272564022.issue270@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

BTW, parallel contributions to the Jython tracker would be appreciated (although
we could also defer such tasks to the Jython guys).

Likewise, the meta and setuptools instances might need some care; this should be
easy since they really use the original templates very much.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Tue Apr 14 00:13:27 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 13 Apr 2009 22:13:27 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1239660807.82.0.0876172921423.issue270@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Martin v. L??wis wrote:
>> Should I keep this change (lowercasing existing POSTs) out of the 1.4.8 patch?
>
> Yes, please. A "it now validates" patch would be better.

OK, here's an updated, cleaner patch.

I do have an incomplete "it now validates" local branch, but it always seems to
be better to wait until most template changes land before working on it. I hope
I can include it on a new work plan so I don't block myself with incompatible
patches.

> Ok, patching detectors to match more closely the upstream reactors
> is good (i.e. if a fragment is in 1.4.8, it has a place in this patch).
>
> Stuff that is *not* in the upstream code does not belong into this
> patch. 

OK, new template patch uses this rule, no big changes. I haven't included id
strings and copyright notices from upstream, are they desirable?

The roundup patch has a couple of trunk changes that aren't in 1.4.8, should I
split it in 1.4.8 and 1.4.9a? 

> Wrt. 2.3 support, I think any effort in providing it is wasted.
>
>> IMHO, both explicitly targeting a specific (set of) version(s) or
>> using the anypy helper could help us make our detectors better and
>> less prone to bit-rot. So, what would you prefer: target 2.4 and above
>> (2.x), target  2.4-2.6, rely on anypy, something else?
>
> I disagree that the python-dev tracker is the place to start
> a generic reusable template.

No problem, let's forget the 'more generic template' idea. But having a set of
target versions would make my work easier. A lower bound (2.4?) makes it easier
to decide which features can be used, but an upper bound (2.6? 2.x for x >= 7?)
also helps in coding future-ready code.

> Feel free to contribute it to roundup,
> and perhaps talk roundup maintainers into making it a new template,
> but leave this project please out of our instances.

Stefan Seefeld has already started this, and IIUC has added many desirable
features to his python-dev-based template, like support for tasks and
milestones. When it lands upstream I'll see what we can reuse.

I'm submitting our local roundup-src changes upstream, so they can decide to
integrate them or not. Sometimes (like with the unlink auditor), I'm also
submitting parallel patches for the classic template. 

> The tracker instance is *not* reusable. It is tightly integrated
> with the rest of python.org in terms of layout, and it should
> stay that way.

OK. I'll keep a set of local patches to use in http://bot.bio.br/python-dev (a
test instance) and in the experimental instance when it's live.

> BTW, parallel contributions to the Jython tracker would be appreciated (although
> we could also defer such tasks to the Jython guys).
>
> Likewise, the meta and setuptools instances might need some care; this should be
> easy since they really use the original templates very much.

OK, I'll take a look at each instance to see what and how I contribute to them.
Are we free to update their templates and detectors or should I also ping
someone else?

Expect a tracker-discuss thread with a draft updated roadmap in the week after
GSoC students are announced. That way I can coordinate with any overlapping
projects to avoid conflicts.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-dev_1.4.8_2.diff
Type: text/x-diff
Size: 4367 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090413/e8237898/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Tue Apr 14 04:51:37 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Tue, 14 Apr 2009 02:51:37 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239660807.82.0.0876172921423.issue270@psf.upfronthosting.co.za>
Message-ID: <49E3FA13.3000502@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> OK, here's an updated, cleaner patch.

Thanks. I hope to look at it within a few days.

> The roundup patch has a couple of trunk changes that aren't in 1.4.8, should I
> split it in 1.4.8 and 1.4.9a? 

No, it's fine to include them (hoping you'll provide another such patch
that updates to 1.4.9 when that gets released)

> OK, I'll take a look at each instance to see what and how I contribute to them.
> Are we free to update their templates and detectors or should I also ping
> someone else?

For the Jython tracker, Raghuram Devarakonda should be listening,
anyway. For setuptools, we should restrict ourselves to the most
important changes only (e.g. keeping it in sync with the roundup
installation, and applying security fixes). If they want anything
else, they will let us know.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From martin at v.loewis.de  Tue Apr 14 04:50:59 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 14 Apr 2009 04:50:59 +0200
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239660807.82.0.0876172921423.issue270@psf.upfronthosting.co.za>
References: <1239660807.82.0.0876172921423.issue270@psf.upfronthosting.co.za>
Message-ID: <49E3FA13.3000502@v.loewis.de>

> OK, here's an updated, cleaner patch.

Thanks. I hope to look at it within a few days.

> The roundup patch has a couple of trunk changes that aren't in 1.4.8, should I
> split it in 1.4.8 and 1.4.9a? 

No, it's fine to include them (hoping you'll provide another such patch
that updates to 1.4.9 when that gets released)

> OK, I'll take a look at each instance to see what and how I contribute to them.
> Are we free to update their templates and detectors or should I also ping
> someone else?

For the Jython tracker, Raghuram Devarakonda should be listening,
anyway. For setuptools, we should restrict ourselves to the most
important changes only (e.g. keeping it in sync with the roundup
installation, and applying security fixes). If they want anything
else, they will let us know.

From ajaksu at gmail.com  Wed Apr 15 21:48:06 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Wed, 15 Apr 2009 16:48:06 -0300
Subject: [Tracker-discuss] Issue tags
In-Reply-To: <2d75d7660904061137q1463da50h4d89dda49b87da08@mail.gmail.com>
References: <49D7661B.7070509@python.org> <49D7A6C0.8090006@v.loewis.de> 
	<2d75d7660904061137q1463da50h4d89dda49b87da08@mail.gmail.com>
Message-ID: <2d75d7660904151248q4fa7918ao53450ebafc935daa@mail.gmail.com>

Georg convinced me on IRC, so he now has tags[1] and I've got a brand
new experimental tracker instance[2] up.

Daniel (ajax) Diniz wrote:
> To make the tags more useful, we could implement the list as a
> Multilink like keywords, with a comma-separated input interface like
> those for nosy. Then, the 'arbitrary' part becomes the problem: do we
> want users to be able to create arbitrary, tracker-wide tags? (no, we
> don't, you might think we do but that'd be mistaken :D).

I've gone with this design and tried to distill my paranoia into
content validation. I've set a code review[3] up, any feedback is
welcome.

Some information from a previous message, with answers to some
questions by Georg and [new bits]:

No emails are being sent currently and the db can be reset at any time :)

Any User can create tags and link or unlink them to/from issues. The
helper to pick tags works, but I didn't test for > 20 tags. You can
search for, sort by, display and group by tags. There's a clickable
list of tags in the issue item view (between messages and history),
leads to search results for the linked tag. [You can add or remove
tags to the filter list in the issue list view, with some JS sugar.]

Any given issue has a max number of tags, any tag a max length and a
set of valid chars, currently:
MAXTAGS = 15
MAXLEN = 20
ALLOWED_CHARS = '[a-z_-]+$'

You can see the tags list at http://bot.bio.br/python-dev-exp/tag ,
but I disallowed all editing (only Admin can set descriptions and
change names). I'd have no problem with making them editable by
Developers.

> Georg asked:
>> Deleting a tag will just remove it from all issues it is
linked to, I guess?

A: No, but we could add a Developer link to remove a given tag from
all issues and use the auditor so that removed tags cannot be
recreated.

There's a helper property that generates some noise ('tags_str: yes ->
yes, looks_ok'), but a fix for that is already queued at the meta
tracker (to silence [nosy|message]_count neatly). [I'll apply this
patch and go back to work on Rietveld integration.]

Both auto-assignment and auto-add-as-nosy[1] are trivial to implement
for tags, but I think both should be restricted to Admins only.

>> Do you mean that only admins can change auto-assignment rules, or that
>> only admins can get auto-assigned? I hope it's the former :)

A: Yes, restrict changing the rules to Admins. And until we get a
better UI to work with auto-nosy, I suggest we only allow Developers
to be added to that list.

Now, if this goes in, I'd really like to keep Components as-is for a
while, until we have some strong evidence that trimming some of them
off would be welcome by most users.

</copy'n'paste> :)

Quoting myself:
> I think this idea is worth floating in python-dev: if most people want
> this I can implement it, but I'd like to keep most components we have
> now.

I don't like the idea of changing Components without pinging
python-dev. Lots of discussion on IRC (I'll try to report on that)
shows this shouldn't happen without a great UI for tags and some other
pre-requisites.

Best regards,
Daniel

[1] http://tinyurl.com/roundup-tags
[2] http://bot.bio.br/python-dev-exp/
[3] http://codereview.appspot.com/40100

From metatracker at psf.upfronthosting.co.za  Fri Apr 17 04:03:25 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 02:03:25 +0000
Subject: [Tracker-discuss] [issue268] Add contributor agreement and
	committer status information
In-Reply-To: <1239216201.07.0.276549739609.issue268@psf.upfronthosting.co.za>
Message-ID: <1239933805.65.0.423158389326.issue268@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Should these be editable by Users themselves, Developers (their profiles or
everyone's?), Coordinators or Admins (lowest privilege)?

Also, will we add the option to sign a CA digitally to the tracker? (We could
also show a link for doing that in user profiles when they haven't signed already).

Do you want to detect issues resolved as accepted/fixes that have patches larger
that xKB by someone that hasn't signed an CA?

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue268>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Fri Apr 17 05:10:06 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 03:10:06 +0000
Subject: [Tracker-discuss] [issue258] Auto add users as nosy based on
	components
In-Reply-To: <1238810320.41.0.116804859177.issue258@psf.upfronthosting.co.za>
Message-ID: <1239937806.95.0.750508748419.issue258@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Patch that works correctly for issues that already had nosy users.

Demo at:
http://bot.bio.br/python-dev-exp/component
http://bot.bio.br/python-dev-exp/issue9

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue258>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto_nosy2.diff
Type: text/x-diff
Size: 1587 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/6e1d3eea/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Fri Apr 17 12:10:48 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 10:10:48 +0000
Subject: [Tracker-discuss] [issue155] Add to Python Bug Sys RSS Feeds for
	Bug Reports, with Filters
In-Reply-To: <1189687013.8.0.983775873845.issue155@psf.upfronthosting.co.za>
Message-ID: <1239963048.37.0.775855765707.issue155@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Rough implementation of RSS feeds, filters do work but description (and raw XML)
could use some more polishing.

Per issue: http://bot.bio.br/python-dev-exp/issue5?@template=feed
Global:
http://bot.bio.br/python-dev-exp/issue?@template=feed&@sort=-activity&@pagesize=15
With filters:
http://bot.bio.br/python-dev-exp/issue?@template=feed&@sort=-activity&@filter=assignee&assignee=ajaksu2_exp

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue155>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rss.diff
Type: text/x-diff
Size: 5525 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/8c745c63/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Fri Apr 17 19:32:59 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 17:32:59 +0000
Subject: [Tracker-discuss] [issue246] Allow display of selected issue sets
In-Reply-To: <1236285970.41.0.295107430273.issue246@psf.upfronthosting.co.za>
Message-ID: <1239989579.51.0.319654213411.issue246@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Here's a cleaner, updated patch.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue246>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: display_selected2.diff
Type: text/x-diff
Size: 2949 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/59ee90c7/attachment.diff>

From ajaksu at gmail.com  Fri Apr 17 20:04:45 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 17 Apr 2009 15:04:45 -0300
Subject: [Tracker-discuss] Experimental and Test Tracker instances live
Message-ID: <2d75d7660904171104k3d13427au8e91489132cd2e23@mail.gmail.com>

Hi,
As discussed before, I have put two mock Python Tracker instances online.

The Test[1] instance follows bugs.python.org code, so we can test
bugfixes and procedures without breaking the real tracker. The
Experimental[2] one, aka the cool instance, is where new features are
showcased.

Currently no emails are being sent and the dbs can be reset at any
time. If you'd like to play as a registered user, please email me and
I'll create a user (or activate the one you've started to register).

So far, the new features[3] include:
   * Issue tags [4],[5]
   * Quiet properties [6]
   * Restore removed messages and files [7]
   * Claim ('assign to self') and add/remove self as nosy buttons [8]
   * Don't close issues with open dependencies [9]
   * Auto-add nosy users based on Components [10]
   * "Email me" buttons for messages and issues, "Reply by email" [11]
   * RSS feeds (per issue and global) [12]
   * Display selected issues in the index view [13]

You can subscribe to a RSS feed[14] about the new features.

Thanks to everyone who filled RFEs, there's still time to submit yours :)

Regards,
Daniel

[1] http://bot.bio.br/python-dev/
[2] http://bot.bio.br/python-dev-exp/
[3] http://bot.bio.br/python-dev-exp/issue5
[4] http://mail.python.org/pipermail/tracker-discuss/2009-April/002099.html
[5] http://codereview.appspot.com/40100/show
[6] http://psf.upfronthosting.co.za/roundup/meta/issue249
[7] http://psf.upfronthosting.co.za/roundup/meta/issue267
[8] http://psf.upfronthosting.co.za/roundup/meta/issue258
[9] http://psf.upfronthosting.co.za/roundup/meta/issue266
[10] http://psf.upfronthosting.co.za/roundup/meta/issue258
[11] http://psf.upfronthosting.co.za/roundup/meta/issue245
[12] http://psf.upfronthosting.co.za/roundup/meta/issue155
[13] http://psf.upfronthosting.co.za/roundup/meta/issue246
[14] http://bot.bio.br/python-dev-exp/issue5?@template=feed

From metatracker at psf.upfronthosting.co.za  Sat Apr 18 00:35:20 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 22:35:20 +0000
Subject: [Tracker-discuss] [issue248] Mass-update/batch-editing support
In-Reply-To: <1236374592.31.0.943684755279.issue248@psf.upfronthosting.co.za>
Message-ID: <1240007720.76.0.84981860967.issue248@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Slightly improved version. Still lacking docs, confirmation dialogue and some
permission checks (only to avoid misleading users).

Added:
    * Success and (better) error messages.
    * Entry point from index view.
    * Option to not unset Links ('no change').
    * Nice view of edited issues on success/error.

Changed/fixed:
    * Avoid 'non-indexable' errors when the 'id' form value isn't a list.
    * Reject batch edits without issue IDs
    * Disable the comment field for now

Demo and review:
http://tinyurl.com/batch-edit (looks much better when logged in :)
http://codereview.appspot.com/40130

----------
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue248>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: batch_edit_03.diff
Type: text/x-diff
Size: 20422 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/01192017/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Sat Apr 18 01:04:37 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 23:04:37 +0000
Subject: [Tracker-discuss] [issue248] Mass-update/batch-editing support
In-Reply-To: <1236374592.31.0.943684755279.issue248@psf.upfronthosting.co.za>
Message-ID: <1240009477.85.0.828794643876.issue248@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Fix a problem with the results page not showing issues.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue248>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: batch_edit_04.diff
Type: text/x-diff
Size: 20486 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/4a838980/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Sat Apr 18 02:49:34 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 18 Apr 2009 00:49:34 +0000
Subject: [Tracker-discuss] [issue132] Enable blocker/dependency detector
In-Reply-To: <1187889251.39.0.628325064137.issue132@psf.upfronthosting.co.za>
Message-ID: <1240015774.31.0.784553127825.issue132@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

There's a patch to avoid closing a ticket if it has open dependencies in issue
256. Issues aren't removed from dependency lists on close.

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue132>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Apr 19 00:00:41 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 18 Apr 2009 22:00:41 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

This patch adds a list of 'range(n)' numbered links below the "Messages (n)"
header so that navigating to an arbitrary message is easier. Each message shows
its link number (linked back to the list) left of the msgid link. 

It also adds "m" as an accesskey to the messages list, allowing one to, e.g.,
press "Alt+Shift+m" in Firefox and land at the list again (makes keyboard
navigation for reading much more comfortable IMO).

Demo: http://bot.bio.br/python-dev-exp/issue10

----------
files: message_navigation.diff
messages: 1340
nosy: ajaksu2
priority: feature
status: unread
title: Message navigation links

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: message_navigation.diff
Type: text/x-diff
Size: 1771 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090418/90c7303c/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Sun Apr 19 00:14:42 2009
From: metatracker at psf.upfronthosting.co.za (Georg Brandl)
Date: Sat, 18 Apr 2009 22:14:42 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240092882.88.0.746300599743.issue271@psf.upfronthosting.co.za>


Georg Brandl <g.brandl at gmx.net> added the comment:

I'm not sure this is useful. Why would you want to jump to a message by number?

----------
nosy: +gbrandl
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sun Apr 19 01:51:21 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 18 Apr 2009 23:51:21 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240098681.65.0.547068455335.issue271@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I want something like this whenever the issue has many messages and I visit it
from time to time. Following many issues without being nosy leads to that, but a
single link to the last message would cover this use case.

Having the links with more information than message indexes would clutter the UI
too much IMO.

It seems that less than 1400 issues currently have more than 10 messages, and
less than 300 have more than 20. So the numbers suggest the links list wouldn't
be that useful :)

Still, I'd like to at least include message ids as their anchor ids, we'd be
able to link to messages with a nicer context, compare:
http://bot.bio.br/python-dev-exp/issue10#msg45
          x
http://bugs.python.org/msg58947 (no in-thread link)
          x
RSS feeds, IRC updates and nosy/bugs-list messages that link to issue, not message.

If more people want links, I'd be glad to add them. Otherwise, I'm OK with only
adding IDs.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Apr 18 00:41:51 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 17 Apr 2009 22:41:51 +0000
Subject: [Tracker-discuss] [issue248] Mass-update/batch-editing support
In-Reply-To: <1236374592.31.0.943684755279.issue248@psf.upfronthosting.co.za>
Message-ID: <1240008111.29.0.723557641271.issue248@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Screenshots :)

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue248>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: batch_edit_01.png
Type: image/png
Size: 43482 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090417/f283acb8/attachment-0001.png>

From metatracker at psf.upfronthosting.co.za  Tue Apr 21 20:19:48 2009
From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda)
Date: Tue, 21 Apr 2009 18:19:48 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <1240337988.61.0.935558017122.issue272@psf.upfronthosting.co.za>
Message-ID: <1240337988.61.0.935558017122.issue272@psf.upfronthosting.co.za>


New submission from Raghuram Devarakonda <draghuram at gmail.com>:

I tried to add a new version "25b3" to jython tracker but visiting the url
"http://bugs.jython.org/version" results in the following error:

-----
HTTP_AUTHORIZATION=None
SERVER_PORT=8080
SERVER_NAME=localhost
HTTP_COOKIE=roundup_session_Jythontracker=MTI0MDMzNzQ1MC42MzAuNTMzOTI1ODM2MTgy
HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5
SCRIPT_NAME=
REQUEST_METHOD=GET
HTTP_HOST=localhost:8080
PATH_INFO=version
CONTENT_TYPE=text/plain
TRACKER_NAME=jython
via=1.1 PROXY1, 1.0 bugs.jython.org
accept-language=en-us,en;q=0.5
accept-encoding=gzip,deflate
x-forwarded-host=bugs.jython.org
x-forwarded-for=198.62.239.132
connection=Keep-Alive
accept=text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
user-agent=Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010
Firefox/2.0
accept-charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7
host=localhost:8080
cookie=roundup_session_Jythontracker=MTI0MDMzNzQ1MC42MzAuNTMzOTI1ODM2MTgy
max-forwards=10
x-forwarded-server=bugs.jython.org
user:'draghuram'
Traceback (most recent call last):

 File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/client.py",
line 469, in inner_main
   self.write_html(self.renderContext())

 File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/client.py",
line 997, in renderContext
   result = pt.render(self, None, None, **args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/templating.py",
line 327, in render
   getEngine().getContext(c), output, tal=1, strictinsert=0)()

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 192, in __call__
   self.interpret(self.program)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 666, in do_useMacro
   self.interpret(macro)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
   self.do_optTag(stuff)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
   return self.no_tag(start, program)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
   self.interpret(program)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 689, in do_defineSlot
   self.interpret(slot)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 632, in do_condition
   self.interpret(block)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 411, in do_optTag_tal
   self.do_optTag(stuff)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 396, in do_optTag
   return self.no_tag(start, program)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 391, in no_tag
   self.interpret(program)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 236, in interpret
   handlers[opcode](self, args)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py",
line 486, in do_insertText_tal
   text = self.engine.evaluateText(stuff[0])

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/TALES.py",
line 233, in evaluateText
   text = self.evaluate(expr)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/TALES.py",
line 227, in evaluate
   return expression(self)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 194, in __call__
   return self._eval(econtext)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 189, in _eval
   return render(ob, econtext.vars)

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 95, in render
   ob = ob()

 File
"/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/templating.py",
line 627, in csv
   row.append(str(klass.get(itemid, name)))

NameError: global name 'row' is not defined
-----

----------
messages: 1343
nosy: draghuram
priority: bug
status: unread
title: Unable to add a new version to jython tracker

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Tue Apr 21 22:32:29 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 21 Apr 2009 20:32:29 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <1240337988.61.0.935558017122.issue272@psf.upfronthosting.co.za>
Message-ID: <1240345949.66.0.372609766355.issue272@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This was introduced in Roundup 1.4.7 and fixed in 1.4.8, so the patch in issue
270 covers it. That 'row.append' line is bogus, the attached patch removes it.

I think you can create the new version by visiting
http://bugs.jython.org/version?@action=new&name=25b3 and then edit it at
http://bugs.jython.org/versionxx.

----------
nosy: +ajaksu2
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: class_list.diff
Type: text/x-diff
Size: 1185 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090421/e944ff17/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Tue Apr 21 22:35:12 2009
From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda)
Date: Tue, 21 Apr 2009 20:35:12 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <1240345949.66.0.372609766355.issue272@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0904211335i6901a633kead5ca68444f751b@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Tue, Apr 21, 2009 at 4:32 PM, Daniel Diniz
<metatracker at psf.upfronthosting.co.za> wrote:
> I think you can create the new version by visiting
> http://bugs.jython.org/version?@action=new&name=25b3 and then edit it at

Thanks for looking into the problem. How ever, this link doesn't seem
to work. I get a message that a problem is encountered.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Tue Apr 21 22:36:20 2009
From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda)
Date: Tue, 21 Apr 2009 20:36:20 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <2c51ecee0904211335i6901a633kead5ca68444f751b@mail.gmail.com>
Message-ID: <2c51ecee0904211336p3e6ac299tf88547f6c918fe8d@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Tue, Apr 21, 2009 at 4:35 PM, Raghuram Devarakonda
<draghuram at gmail.com> wrote:
> On Tue, Apr 21, 2009 at 4:32 PM, Daniel Diniz
> <metatracker at psf.upfronthosting.co.za> wrote:
>> I think you can create the new version by visiting
>> http://bugs.jython.org/version?@action=new&name=25b3 and then edit it at
>
> Thanks for looking into the problem. How ever, this link doesn't seem
> to work. I get a message that a problem is encountered.

Looks like the error is slightly different. It is now complaining about 'csv':

-----
File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 182, in _eval
   ob = self._subexprs[-1](econtext)

 File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 138, in _eval
   ob = restrictedTraverse(ob, path, getSecurityManager())

 File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/PageTemplates/Expressions.py",
line 324, in restrictedTraverse
   o = object[name]

 File "/home/roundup/roundup/lib/python2.4/site-packages/roundup/cgi/templating.py",
line 825, in __getitem__
   prop = self._props[items[0]]

KeyError: 'csv'
-----

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Tue Apr 21 22:58:01 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 21 Apr 2009 20:58:01 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <2c51ecee0904211335i6901a633kead5ca68444f751b@mail.gmail.com>
Message-ID: <2d75d7660904211357q1e9fcd6dka60b321cc31fc4cb@mail.gmail.com>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Raghuram Devarakonda wrote:
> Thanks for looking into the problem. How ever, this link doesn't seem
> to work. I get a message that a problem is encountered.

That's expected, sorry for not warning about it. The new version
should still have been created if you had the rights to create it, so
take a look at the options when you create a new issue.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Apr 22 16:32:17 2009
From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda)
Date: Wed, 22 Apr 2009 14:32:17 +0000
Subject: [Tracker-discuss] [issue272] Unable to add a new version to jython
	tracker
In-Reply-To: <2d75d7660904211357q1e9fcd6dka60b321cc31fc4cb@mail.gmail.com>
Message-ID: <2c51ecee0904220732x5139c968tcdeb9c2bf5f7e688@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Tue, Apr 21, 2009 at 4:58 PM, Daniel Diniz
<metatracker at psf.upfronthosting.co.za> wrote:
> That's expected, sorry for not warning about it. The new version
> should still have been created if you had the rights to create it, so
> take a look at the options when you create a new issue.

Indeed. The new version is created. Thanks.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue272>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Thu Apr 23 18:19:17 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 23 Apr 2009 16:19:17 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240503557.41.0.838139321482.issue271@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Everyone on #python-dev agrees the message links and index numbers should go.
They wanted the message numbers to be their 'permalinks' in an issue.

Here's an updated patch that keeps the '(view)' link the same as we have now and
makes the 'msgxxxx' a separated link with 'id="msgxxxx"'.

So http://bot.bio.br/python-dev-exp/issue10#msg45 still works :)

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: message_ids.diff
Type: text/x-diff
Size: 881 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090423/b3abd498/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Thu Apr 23 22:54:26 2009
From: metatracker at psf.upfronthosting.co.za (Kevin Dwyer)
Date: Thu, 23 Apr 2009 20:54:26 +0000
Subject: [Tracker-discuss] [issue273] Incorrect comment attributions
In-Reply-To: <1240520066.1.0.0651594922664.issue273@psf.upfronthosting.co.za>
Message-ID: <1240520066.1.0.0651594922664.issue273@psf.upfronthosting.co.za>


New submission from Kevin Dwyer <kevin.p.dwyer at gmail.com>:

In Python bug 1327971, a number of comments appear to be attributed to my user
(kdwyer); however these comments predate my registering on the issue tracker,
and were not in fact made by me.  It looks as if they should be attributed to
user 	kevindication.historic, who created the original report.

----------
messages: 1350
nosy: kdwyer
priority: bug
status: unread
title: Incorrect comment attributions

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue273>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Fri Apr 24 06:49:16 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Fri, 24 Apr 2009 04:49:16 +0000
Subject: [Tracker-discuss] [issue273] Incorrect comment attributions
In-Reply-To: <1240520066.1.0.0651594922664.issue273@psf.upfronthosting.co.za>
Message-ID: <1240548555.92.0.247804080513.issue273@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So kevindication at users.sourceforge.net is a different Kevin Dwyer?

----------
nosy: +loewis
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue273>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Fri Apr 24 10:01:07 2009
From: metatracker at psf.upfronthosting.co.za (Kevin Dwyer)
Date: Fri, 24 Apr 2009 08:01:07 +0000
Subject: [Tracker-discuss] [issue273] Incorrect comment attributions
In-Reply-To: <1240520066.1.0.0651594922664.issue273@psf.upfronthosting.co.za>
Message-ID: <1240560067.58.0.511726131586.issue273@psf.upfronthosting.co.za>


Kevin Dwyer <kevin.p.dwyer at gmail.com> added the comment:

Yes, he's a different person.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue273>
_______________________________________________________

From stephen at xemacs.org  Fri Apr 24 19:39:51 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 25 Apr 2009 02:39:51 +0900
Subject: [Tracker-discuss] [Python-Dev] Dates in python-dev
In-Reply-To: <200904241837.21090.Arfrever.FTA@gmail.com>
References: <49F1E8E9.60903@mrabarnett.plus.com>
	<200904241837.21090.Arfrever.FTA@gmail.com>
Message-ID: <87skjykl20.fsf@uwakimon.sk.tsukuba.ac.jp>

Followups directed to Tracker-Discuss, where the people who can do
something about it are hanging out.  (They're here too, but I'm pretty
sure they'd rather discuss this issue on that list.)

Arfrever Frehtes Taifersar Arahesis writes:
 > 2009-04-24 18:29:29 MRAB napisa?(a):
 > > Hi,
 > > 
 > > I've recently subscribed to this list and received my first "Summary of
 > > Python tracker Issues". What I find annoying are the dates, for example:
 > > 
 > >      ACTIVITY SUMMARY (04/17/09 - 04/24/09)
 > > 
 > > 3 x double-digits (have we learned nothing from Y2K? :-)) with the
 > > _middle_ ones changing fastest!
 > > 
 > > I know it's the US standard, but Python is global. Could we have an
 > > 'international' style instead, say, year-month-day:
 > > 
 > >      ACTIVITY SUMMARY (2009-04-17 - 2009-04-24)
 > 
 > +1.
 > ISO 8601 should be mandatory.

From metatracker at psf.upfronthosting.co.za  Fri Apr 24 19:47:50 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 24 Apr 2009 17:47:50 +0000
Subject: [Tracker-discuss] [issue274] Change Activity Summary dates to
	year-month-day format
In-Reply-To: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
Message-ID: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Trivial patch that changes
 ACTIVITY SUMMARY (04/17/09 - 04/24/09)
into
 ACTIVITY SUMMARY (2009-04-17 - 2009-04-24)
as requested at http://mail.python.org/pipermail/python-dev/2009-April/088967.html

----------
files: summary_date.diff
messages: 1353
nosy: ajaksu2
priority: bug
status: unread
title: Change Activity Summary dates to year-month-day format

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue274>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: summary_date.diff
Type: text/x-diff
Size: 403 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090424/f5665d4f/attachment.diff>

From ajaksu at gmail.com  Fri Apr 24 19:50:47 2009
From: ajaksu at gmail.com (Daniel Diniz)
Date: Fri, 24 Apr 2009 14:50:47 -0300
Subject: [Tracker-discuss] [Python-Dev] Dates in python-dev
In-Reply-To: <87skjykl20.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <49F1E8E9.60903@mrabarnett.plus.com>
	<200904241837.21090.Arfrever.FTA@gmail.com> 
	<87skjykl20.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <2d75d7660904241050l27665a8ege0aa52f6822375bd@mail.gmail.com>

http://psf.upfronthosting.co.za/roundup/meta/issue274

From ajaksu at gmail.com  Fri Apr 24 20:16:28 2009
From: ajaksu at gmail.com (Daniel Diniz)
Date: Fri, 24 Apr 2009 15:16:28 -0300
Subject: [Tracker-discuss] [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <Pine.LNX.4.64.0904031233310.26362@kimball.webabinitio.net>
References: <20090403160659.1AB6278590@psf.upfronthosting.co.za> 
	<Pine.LNX.4.64.0904031233310.26362@kimball.webabinitio.net>
Message-ID: <2d75d7660904241116n3a2bfa97he27981845cece867@mail.gmail.com>

Hi David,

On Fri, Apr 3, 2009 (sorry about replying this late!) R. David Murray wrote:
> On Fri, 3 Apr 2009 at 18:06, Python tracker wrote:
[...]
>> 2272 open (+59) / 15229 closed (+39) / 17501 total (+98)
>>
[...]
>> Open Issues Breakdown
>> ?open ?2222 (+57)
>> pending ? ?50 ( +2)
>>
>> Issues Created Or Reopened (103)
>> ________________________________
>>
> [...]
>>
>> Issues Now Closed (233)
>> _______________________
>>
>
> Let's see if I understand this. ?So there were 98 new issues opened,
> of which 39 were closed in the reporting period and 50 were left open.
> Then in a disjoint reporting, 103 items become opened either by being
> created or by being reopened, and 233 bugs in total went from some open
> state to closed during the reporting period.
>
> OK. ?But that first line is _really discouraging_.

Yep, I had the same problem[1].

> ?I suggest we change
> this report to provide statistics that are designed to encourage people
> using the tracker when they make progress on reducing the total number
> of outstanding bugs, or at least make it clear that the open bug count
> isn't increasing as fast as the above report format makes it seem.

I'll try to implement this today.

> (An aside: I don't think I care how many total bugs there are. ?IMO that's
> just noise in a report like this.)

I think it helps giving some perspective to newcomers, but it might be
better to move it to the bottom of the report.

> I'd like to see something more like:
>
> ? ?New issues this week: ? ? ? ? ? ?98
> ? ?Old issues reopened: ? ? ? ? ? ? ?5
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---
> ? ?Additional open this week: ? ? ?103
>
> ? ?New issues closed this week: ? ? 39
> ? ?New issues set close pending: ? ? 2
> ? ?Old issues closed this week: ? ?194
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---
> ? ?Total issues closed this week: ?233
>
>
> ? ?Open issue count on 03/27: ? ? 2353
> ? ?Open issue count on 04/03: ? ? 2222
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ----
> ? ?Net decrease in open issues: ? ?131

Looks good, I'll add this to our current report (as opposed to
replacing the corresponding bits) and ping this list and  #python-dev
so we can compare and improve the format.

> Presumably there is also an 'old issues set pending' line to add
> in the second set.

Just to be clear,  'Old issues reopened' includes old issues that were
'pending' and are now 'open', right?

> Would this be possible?

Yes :)

> ?Any other suggestions for clearer and/or more moral building reporting?

I'd like to add line graphs to show how the numbers change during
time, preferably using the Google Chart API[2] (and maybe TinyURLs).
Also, I think we might include a link to Facundo's report[3] (I wish
the activity graph as bigger and started at, say, 2006).

Best regards,
Daniel

[1] http://mail.python.org/pipermail/python-dev/2009-February/086269.html
[2] http://code.google.com/apis/chart/
[3] http://www.taniquetil.com.ar/cgi-bin/pytickets.py

From martin at v.loewis.de  Fri Apr 24 20:28:04 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 24 Apr 2009 20:28:04 +0200
Subject: [Tracker-discuss] [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <2d75d7660904241116n3a2bfa97he27981845cece867@mail.gmail.com>
References: <20090403160659.1AB6278590@psf.upfronthosting.co.za>
	<Pine.LNX.4.64.0904031233310.26362@kimball.webabinitio.net>
	<2d75d7660904241116n3a2bfa97he27981845cece867@mail.gmail.com>
Message-ID: <49F204B4.4050304@v.loewis.de>

> I'd like to add line graphs to show how the numbers change during
> time, preferably using the Google Chart API[2] (and maybe TinyURLs).
> Also, I think we might include a link to Facundo's report[3] (I wish
> the activity graph as bigger and started at, say, 2006).

I think it's possible to recover past activity completely from the
SF export data, if anybody is interested. Our own journals start at
2007-08-23. SF journals go back to 2000.

Regards,
Martin

From stephen at xemacs.org  Fri Apr 24 20:46:22 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 25 Apr 2009 03:46:22 +0900
Subject: [Tracker-discuss] [issue274] Change Activity Summary dates
	to	year-month-day format
In-Reply-To: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
References: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
Message-ID: <87prf1lwjl.fsf@uwakimon.sk.tsukuba.ac.jp>

Daniel Diniz writes:

 >  # Date format per time.strftime
 > -dateFormat="%x"   #locale-appropriate
 > +dateFormat="%F"   #locale-appropriate

The comment should be changed to "ISO 8601".

From metatracker at psf.upfronthosting.co.za  Fri Apr 24 20:37:22 2009
From: metatracker at psf.upfronthosting.co.za (Stephen Turnbull)
Date: Fri, 24 Apr 2009 18:37:22 +0000
Subject: [Tracker-discuss] [issue274] Change Activity Summary dates to
	year-month-day format
In-Reply-To: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
Message-ID: <87prf1lwjl.fsf@uwakimon.sk.tsukuba.ac.jp>


Stephen Turnbull <stephen at xemacs.org> added the comment:

Daniel Diniz writes:

 >  # Date format per time.strftime
 > -dateFormat="%x"   #locale-appropriate
 > +dateFormat="%F"   #locale-appropriate

The comment should be changed to "ISO 8601".

----------
nosy: +stephen
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue274>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Fri Apr 24 20:57:50 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 24 Apr 2009 18:57:50 +0000
Subject: [Tracker-discuss] [issue274] Change Activity Summary dates to
	year-month-day format
In-Reply-To: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
Message-ID: <1240599470.28.0.551112899246.issue274@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Stephen Turnbull wrote:
> The comment should be changed to "ISO 8601"

Changed to "ISO 8601: yyyy-mm-dd" so people can readily get what the format is.

Thanks for the feedback!

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue274>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: summary_date2.diff
Type: text/x-diff
Size: 406 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090424/dd4ccae4/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 10:43:02 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 08:43:02 +0000
Subject: [Tracker-discuss] [issue269]  tracker unreachable
In-Reply-To: <4dab5f760904100834v4c466968t386ba470e32174df@mail.gmail.com>
Message-ID: <1240648982.96.0.931585289895.issue269@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This was fixed a while ago

----------
priority:  -> critical

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue269>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 10:45:26 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 08:45:26 +0000
Subject: [Tracker-discuss] [issue274] Change Activity Summary dates to
	year-month-day format
In-Reply-To: <1240595270.96.0.454812708553.issue274@psf.upfronthosting.co.za>
Message-ID: <1240649126.9.0.63545638269.issue274@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r71864.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue274>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 10:55:16 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 08:55:16 +0000
Subject: [Tracker-discuss] [issue273] Incorrect comment attributions
In-Reply-To: <1240520066.1.0.0651594922664.issue273@psf.upfronthosting.co.za>
Message-ID: <1240649716.56.0.987192542726.issue273@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, I have restored the attribution.

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue273>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 11:05:53 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 09:05:53 +0000
Subject: [Tracker-discuss] [issue270] Upgrade to 1.4.8
In-Reply-To: <1239572158.5.0.250388646924.issue270@psf.upfronthosting.co.za>
Message-ID: <1240650353.11.0.765973217943.issue270@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patches. Committed as r71865 and r71866

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue270>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 11:08:00 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 09:08:00 +0000
Subject: [Tracker-discuss] [issue261] copyright dates need updating
In-Reply-To: <1238959138.85.0.247437190711.issue261@psf.upfronthosting.co.za>
Message-ID: <1240650480.33.0.277542352867.issue261@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r71867.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue261>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 11:12:27 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 09:12:27 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240650747.35.0.193155787961.issue271@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There should be a way for a coordinator to quickly get to the message's page, as
that has the Ham/Spam buttons.

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 11:17:00 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 09:17:00 +0000
Subject: [Tracker-discuss] [issue258] Auto add users as nosy based on
	components
In-Reply-To: <1238810320.41.0.116804859177.issue258@psf.upfronthosting.co.za>
Message-ID: <1240651020.84.0.295996285338.issue258@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r71868.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue258>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 11:21:20 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 09:21:20 +0000
Subject: [Tracker-discuss] [issue266] Buttons to add/remove self from nosy
	list, assign issue to self
In-Reply-To: <1239149532.95.0.77008083815.issue266@psf.upfronthosting.co.za>
Message-ID: <1240651280.08.0.419275036807.issue266@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the reason for putting the JavaScript into strings for tal:content,
instead of putting them into the content in the first place?

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue266>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Apr 25 13:58:25 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 25 Apr 2009 11:58:25 +0000
Subject: [Tracker-discuss] [issue275] Issue creation broken by autonosy
In-Reply-To: <1240660705.04.0.0633544307073.issue275@psf.upfronthosting.co.za>
Message-ID: <1240660705.04.0.0633544307073.issue275@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

The autonosy detector is broken for new issues with selected components, as it
tries to fetch a property from nodeid == None. This patch fixes it.

----------
files: fix_autonosy.diff
messages: 1364
nosy: ajaksu2
priority: bug
status: unread
title: Issue creation broken by autonosy

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue275>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_autonosy.diff
Type: text/x-diff
Size: 604 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090425/dcaba59f/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 14:52:21 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 12:52:21 +0000
Subject: [Tracker-discuss] [issue275] Issue creation broken by autonosy
In-Reply-To: <1240660705.04.0.0633544307073.issue275@psf.upfronthosting.co.za>
Message-ID: <1240663941.17.0.6233677644.issue275@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks, committed as r71883

----------
nosy: +loewis
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue275>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Sat Apr 25 18:14:16 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 25 Apr 2009 16:14:16 +0000
Subject: [Tracker-discuss] [issue276] RE for matching SVN paths needs fixing
In-Reply-To: <1240676056.5.0.556496742683.issue276@psf.upfronthosting.co.za>
Message-ID: <1240676056.5.0.556496742683.issue276@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Some paths aren't correctly linked to ViewVC, like:
  - the first link in http://bugs.python.org/msg86170
  - the second link in http://bugs.python.org/msg80020

Ezio Melotti provided this patch to fix it, demo at
http://bot.bio.br/python-dev/issue7

----------
files: svn_links2.diff
messages: 1366
nosy: ajaksu2
priority: bug
status: unread
title: RE for matching SVN paths needs fixing

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue276>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svn_links2.diff
Type: text/x-diff
Size: 1143 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090425/1f0bacc7/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Apr 25 18:37:29 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sat, 25 Apr 2009 16:37:29 +0000
Subject: [Tracker-discuss] [issue276] RE for matching SVN paths needs fixing
In-Reply-To: <1240676056.5.0.556496742683.issue276@psf.upfronthosting.co.za>
Message-ID: <1240677449.96.0.598983890021.issue276@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r71905.

----------
nosy: +loewis
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue276>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sun Apr 26 22:13:42 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sun, 26 Apr 2009 20:13:42 +0000
Subject: [Tracker-discuss] [issue259] Add an IO component
In-Reply-To: <1238814539.15.0.999943581075.issue259@psf.upfronthosting.co.za>
Message-ID: <1240776822.16.0.5636355124.issue259@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Done, it's component23

----------
nosy: +loewis
status: unread -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue259>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sun Apr 26 22:25:59 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sun, 26 Apr 2009 20:25:59 +0000
Subject: [Tracker-discuss] [issue256] Forbid closing an issue if there are
	open dependencies
In-Reply-To: <1238788100.06.0.566028612767.issue256@psf.upfronthosting.co.za>
Message-ID: <1240777559.55.0.232608770525.issue256@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patches. I have now applied no_open_dependencies.diff as r71982.

In the future, please remove patches that you don't longer consider relevant
from the issue.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue256>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sun Apr 26 22:27:10 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sun, 26 Apr 2009 20:27:10 +0000
Subject: [Tracker-discuss] [issue257] Allow issue creator to set resolution
In-Reply-To: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>
Message-ID: <1240777630.08.0.109243026588.issue257@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What kind of action is needed on this issue?

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue257>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sun Apr 26 22:32:23 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Sun, 26 Apr 2009 20:32:23 +0000
Subject: [Tracker-discuss] [issue260] Consider using a nice editor for
	the	Comment: field	-	CodeMirror javascript
In-Reply-To: <1238955321.66.0.216012375046.issue260@psf.upfronthosting.co.za>
Message-ID: <1240777943.33.0.502763725087.issue260@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree that this is feature creep, and not really needed in day-to-day usage of
the tracker. If this were contributed, it should be contributed upstream, i.e.
to roundup itself, rather than to this installation of roundup.

Rejecting the request.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue260>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 00:43:58 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 26 Apr 2009 22:43:58 +0000
Subject: [Tracker-discuss] [issue277] Line wrapping in comment box is
	annoying
In-Reply-To: <1240785838.71.0.559804829512.issue277@psf.upfronthosting.co.za>
Message-ID: <1240785838.71.0.559804829512.issue277@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Kurt B. Kaiser reports problems with text wrapping in the comment box[1][2].
Needs confirmation.


[1] http://bugs.python.org/msg85319
[2] http://bugs.python.org/issue2704

----------
messages: 1372
nosy: ajaksu2
priority: bug
status: unread
title: Line wrapping in comment box is annoying

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue277>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 01:00:27 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 26 Apr 2009 23:00:27 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240786827.84.0.588779692168.issue271@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

The message_ids patch keeps '(view)' as a link to the message's page. Maybe it
could be made more obvious by moving this link to the right side of the header?

Removed the outdated patch with internal links.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 01:00:52 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 26 Apr 2009 23:00:52 +0000
Subject: [Tracker-discuss] [issue257] Allow issue creator to set resolution
In-Reply-To: <1238788354.58.0.0603592187467.issue257@psf.upfronthosting.co.za>
Message-ID: <1240786852.68.0.0886809013301.issue257@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

It's OK to commit.

The on_close patch from issue 256 was rejected.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue257>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 01:40:26 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 26 Apr 2009 23:40:26 +0000
Subject: [Tracker-discuss] [issue266] Buttons to add/remove self from nosy
	list, assign issue to self
In-Reply-To: <1239149532.95.0.77008083815.issue266@psf.upfronthosting.co.za>
Message-ID: <1240789226.32.0.981961753781.issue266@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

I started with 'hardcoded' usernames in JS (set from TAL), and forgot to clean
this up when it became unnecessary. 

This new version removes the TAL setting of username on the buttons, doing it
once in a <input type="hidden"> and using JS to get the value.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue266>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_self3.diff
Type: text/x-diff
Size: 3210 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090426/b17846a7/attachment-0001.diff>

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 01:51:10 2009
From: metatracker at psf.upfronthosting.co.za (Kurt B. Kaiser)
Date: Sun, 26 Apr 2009 23:51:10 +0000
Subject: [Tracker-discuss] [issue277] Line wrapping in comment box is
	annoying
In-Reply-To: <1240785838.71.0.559804829512.issue277@psf.upfronthosting.co.za>
Message-ID: <1240789870.08.0.843991774207.issue277@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

What I see is the size of the comment box and the frames changing as I work on 
the bug.  If I just type into the comment box and submit, there's no problem. 
But if I type and then make entries in, say, the Nosy List, or switch to 
another tab to check something and come back, I see frames resizing.  When that 
happens, the comment wrapping get screwed because there are hard cr inserted.

Right now I'm using Opera 9.64 on XP Home Sp 3 and not seeing the problem 
entering this particular Issue277.  I usually use an older version of Opera on 
various Linux distros.  The key thing to look for is frames resizing. With my 
current setup, I can't make them do that.

But I'm not alone, see Terry Reedy's msg on the referenced page or several 
people having problems at

http://bugs.python.org/issue5559

----------
nosy: +kbk
status: unread -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue277>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 02:48:22 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Mon, 27 Apr 2009 00:48:22 +0000
Subject: [Tracker-discuss] [issue278] 1.4.8 fixes for other PSF trackers
In-Reply-To: <1240793302.05.0.121079776163.issue278@psf.upfronthosting.co.za>
Message-ID: <1240793302.05.0.121079776163.issue278@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

Due to security fixes in 1.4.8, removing files and messages and retiring users
is broken for the meta, board, jython, security, and setuptools instances. User
retiring is broken for the jobs instance. The python-dev-spambayes-integration
code is also affected, but I don't know whether there is a live instance based
on it.

The attached patch fixes these. I can easily provide one patch per instance if
it would be better.

----------
files: 1.4.8_instances.diff
messages: 1377
nosy: ajaksu2
priority: bug
status: unread
title: 1.4.8 fixes for other PSF trackers

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue278>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.4.8_instances.diff
Type: text/x-diff
Size: 23144 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090427/7b47ef1a/attachment-0001.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 27 07:26:27 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 27 Apr 2009 05:26:27 +0000
Subject: [Tracker-discuss] [issue271] Message navigation links
In-Reply-To: <1240092041.68.0.735986553807.issue271@psf.upfronthosting.co.za>
Message-ID: <1240809987.17.0.976770337696.issue271@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r71997.

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue271>
_______________________________________________________

From martin at v.loewis.de  Mon Apr 27 07:32:24 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Apr 2009 07:32:24 +0200
Subject: [Tracker-discuss] [issue277] Line wrapping in comment box is
 annoying
In-Reply-To: <1240789870.08.0.843991774207.issue277@psf.upfronthosting.co.za>
References: <1240789870.08.0.843991774207.issue277@psf.upfronthosting.co.za>
Message-ID: <49F54368.8090503@v.loewis.de>

> What I see is the size of the comment box and the frames changing as I work on 
> the bug.  If I just type into the comment box and submit, there's no problem. 
> But if I type and then make entries in, say, the Nosy List, or switch to 
> another tab to check something and come back, I see frames resizing.

Do they resize as you type, or do they resize only when you submit changes?

> When that happens, the comment wrapping get screwed because 
> there are hard cr inserted.

By whom? Did you hit cr yourself?

> Right now I'm using Opera 9.64 on XP Home Sp 3 and not seeing the problem 
> entering this particular Issue277.  I usually use an older version of Opera on 
> various Linux distros.  The key thing to look for is frames resizing. With my 
> current setup, I can't make them do that.

Neither can I, with firefox (i.e. the frames don't resize only by
switching tabs). Sounds like a browser bug to me.

> But I'm not alone, see Terry Reedy's msg on the referenced page or several 
> people having problems at
> 
> http://bugs.python.org/issue5559

Can you kindly refer to the specific message? I can't see any complaints
about the tracker in this report.

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 27 07:32:30 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 27 Apr 2009 05:32:30 +0000
Subject: [Tracker-discuss] [issue277] Line wrapping in comment box is
	annoying
In-Reply-To: <1240789870.08.0.843991774207.issue277@psf.upfronthosting.co.za>
Message-ID: <49F54368.8090503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> What I see is the size of the comment box and the frames changing as I work on 
> the bug.  If I just type into the comment box and submit, there's no problem. 
> But if I type and then make entries in, say, the Nosy List, or switch to 
> another tab to check something and come back, I see frames resizing.

Do they resize as you type, or do they resize only when you submit changes?

> When that happens, the comment wrapping get screwed because 
> there are hard cr inserted.

By whom? Did you hit cr yourself?

> Right now I'm using Opera 9.64 on XP Home Sp 3 and not seeing the problem 
> entering this particular Issue277.  I usually use an older version of Opera on 
> various Linux distros.  The key thing to look for is frames resizing. With my 
> current setup, I can't make them do that.

Neither can I, with firefox (i.e. the frames don't resize only by
switching tabs). Sounds like a browser bug to me.

> But I'm not alone, see Terry Reedy's msg on the referenced page or several 
> people having problems at
> 
> http://bugs.python.org/issue5559

Can you kindly refer to the specific message? I can't see any complaints
about the tracker in this report.

----------
nosy: +loewis

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue277>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Mon Apr 27 16:51:45 2009
From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda)
Date: Mon, 27 Apr 2009 14:51:45 +0000
Subject: [Tracker-discuss] [issue276] RE for matching SVN paths needs fixing
In-Reply-To: <1240676056.5.0.556496742683.issue276@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0904270751h6ae62847ve5f742d543959761@mail.gmail.com>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

On Sat, Apr 25, 2009 at 12:14 PM, Daniel Diniz
<metatracker at psf.upfronthosting.co.za> wrote:

> Some paths aren't correctly linked to ViewVC, like:
>  - the first link in http://bugs.python.org/msg86170
>  - the second link in http://bugs.python.org/msg80020

I posted a patch for this in issue 196. Please compare the current
(committed) patch with the one there and close that issue if it is not
required any more.

Thanks,
Raghu

ps. For some reason, "Your Issues" on the left pane didn't show any
while "Search" of "created by me" issues did list few (including 196).

----------
nosy: +draghuram
status: resolved -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue276>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 27 21:55:08 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 27 Apr 2009 19:55:08 +0000
Subject: [Tracker-discuss] [issue196] RE for matchig revision id's needs
	tweaking
In-Reply-To: <1204917161.88.0.0844926023843.issue196@psf.upfronthosting.co.za>
Message-ID: <1240862108.59.0.801599420252.issue196@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Superseded by issue 276.

----------
nosy: +loewis
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue196>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 27 21:57:05 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 27 Apr 2009 19:57:05 +0000
Subject: [Tracker-discuss] [issue196] RE for matchig revision id's needs
	tweaking
In-Reply-To: <1204917161.88.0.0844926023843.issue196@psf.upfronthosting.co.za>
Message-ID: <1240862225.61.0.696507944843.issue196@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Actually, reopening. The r* at the beginning is still not supported. However, I
assume that your patch is out of date - sorry about that.

----------
status: resolved -> chatting

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue196>
_______________________________________________________

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Mon Apr 27 21:58:44 2009
From: =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za (=?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za)
Date: Mon, 27 Apr 2009 19:58:44 +0000
Subject: [Tracker-discuss] [issue276] RE for matching SVN paths needs fixing
In-Reply-To: <1240676056.5.0.556496742683.issue276@psf.upfronthosting.co.za>
Message-ID: <1240862324.7.0.853462634124.issue276@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Your patch in issue 196 is actually more comprehensive - the revision name at
the beginning of the message is still not hyperlinked.

"Your issues" is only the issues assigned to you - not the issues submitted by you.

----------
status: chatting -> resolved

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue276>
_______________________________________________________

From metatracker at psf.upfronthosting.co.za  Wed Apr 29 01:13:45 2009
From: metatracker at psf.upfronthosting.co.za (Kurt B. Kaiser)
Date: Tue, 28 Apr 2009 23:13:45 +0000
Subject: [Tracker-discuss] [issue277] Line wrapping in comment box is
	annoying
In-Reply-To: <1240785838.71.0.559804829512.issue277@psf.upfronthosting.co.za>
Message-ID: <1240960425.26.0.569213497691.issue277@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

The comment box won't resize while I'm typing in 
it, but 
will if I click away from 
it and return.

What I just did above was to click on the Title field, then 
the Nosy List, and repeated several times.  That caused the 
Change Note box to narrow in increments by about 1/3 its 
earlier width, causing the text to wrap and extra cr to be 
added, even though the text would easily fix in the resized 
field without changing the original wrapping. Once the field 
is narrowed, the situation is stable. 

The browser is apparently inserting extra CR in the pre block 
when that happens.  I typed the first paragraph w/o returns.

I'm with you at this point - it's probably a browser issue.  
Right now, I'm running Opera 9.02 Build 434 on Linux.

As far as my last comment on issue5559, that's my error - I 
had my bookmark panel set a little wide and the <pre> blocks 
wrapped.  Strictly a local display issue, the 'extra' cr 
weren't in the webpage itself, so ignore that last comment.

I'll check this on Linux with a later version of Opera.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue277>
_______________________________________________________