From metatracker at psf.upfronthosting.co.za  Sun Mar  1 18:26:50 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 01 Mar 2009 17:26:50 +0000
Subject: [Tracker-discuss] [issue87] add # of comments to default issue list
In-Reply-To: <1173534188.93.0.690515473058.issue87@psf.upfronthosting.co.za>
Message-ID: <1235928410.69.0.158695100135.issue87@psf.upfronthosting.co.za>


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

Here's a simple patch that adds two (Number() -> float!) columns to issue, to
track the counts of messages and nosy user on a given issue. Updates
(add/delete)  work fine and displaying it is also easy.

I'll choose between Number and String for these columns after I try to implement
searching on them. I want to allow comparisons ('less than 5 nosy users', 'more
than 2 messages') and that's a bigger RFE :)

IMHO the number of nosy users an issue has is slightly more interesting than how
many unique users have commented (thanks Ezio for suggesting this). I can
implement both or either if anyone has a strong preference on this. 

Any feedback greatly appreciated :)

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  1 18:28:00 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 01 Mar 2009 17:28:00 +0000
Subject: [Tracker-discuss] [issue87] add # of comments to default issue list
In-Reply-To: <1173534188.93.0.690515473058.issue87@psf.upfronthosting.co.za>
Message-ID: <1235928480.75.0.709122836742.issue87@psf.upfronthosting.co.za>


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

A detector that updates the count columns.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue87>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: countauditor.py
Type: text/x-python
Size: 507 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090301/52d21d33/attachment.py>

From metatracker at psf.upfronthosting.co.za  Sun Mar  1 18:28:23 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 01 Mar 2009 17:28:23 +0000
Subject: [Tracker-discuss] [issue87] add # of comments to default issue list
In-Reply-To: <1173534188.93.0.690515473058.issue87@psf.upfronthosting.co.za>
Message-ID: <1235928503.89.0.0712932555506.issue87@psf.upfronthosting.co.za>


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

Screenshot :)

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  1 18:52:53 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 01 Mar 2009 17:52:53 +0000
Subject: [Tracker-discuss] [issue4] Provide prev/next/show list links when
	going through a list of bugs
Message-ID: <1235929973.15.0.678761296563.issue4@psf.upfronthosting.co.za>


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

I think this one can be implemented mostly in template-land, so I'll give it a try. 

The paging trick would be to store an equivalent pseudo-query (like
id=1,2,3,4,5,6,7&@filter=id, either in a cookie or hidden input) and a
positional pointer in a cookie.

----------
assignedto:  -> ajaksu2
nosy: +ajaksu2

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

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 02:11:02 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 01:11:02 +0000
Subject: [Tracker-discuss] [issue123] Have issue ID search work from "search
	tracker" box
In-Reply-To: <1186618913.24.0.852272975879.issue123@psf.upfronthosting.co.za>
Message-ID: <1236215462.77.0.491839056315.issue123@psf.upfronthosting.co.za>


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

Here's an Action-based patch to allow IDs in quick search.

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

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 03:14:34 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 02:14:34 +0000
Subject: [Tracker-discuss] [issue245] Add 'Mail me' button to messages and
	issues
In-Reply-To: <1236219274.3.0.00153659409124.issue245@psf.upfronthosting.co.za>
Message-ID: <1236219274.3.0.00153659409124.issue245@psf.upfronthosting.co.za>


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

A template + extension hack that adds a "Mail me" button to messages and issues.
Their effect is similar to becoming nosy retroactively, by getting a past
message after the fact. This (supposedly) allows one to reply to any message in
an issue from email.

The issue summary is still pretty rough, but this is a WIP :)

----------
files: mailme.diff
messages: 1198
nosy: ajaksu2
priority: wish
status: unread
title: Add 'Mail me' button to messages and issues

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

From ajaksu at gmail.com  Thu Mar  5 05:12:27 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 01:12:27 -0300
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
Message-ID: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>

Hi,
Does anyone want a shortcut for helping code review creation? It could
either populate Rietveld's "Create New Issue" form or put a pre-filled
command-line template for upload.py in a textarea.

I don't have much experience with Rietveld, so (if there is demand for
this feature) any suggestions on how to proceed would be useful.

Regards,
Daniel

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 16:17:23 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 15:17:23 +0000
Subject: [Tracker-discuss] [issue230] Failed logins do not produce an error
	message
In-Reply-To: <1228923671.45.0.654540731742.issue230@psf.upfronthosting.co.za>
Message-ID: <1236266243.78.0.137605446531.issue230@psf.upfronthosting.co.za>


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

Steve,
This patch adds a 'Login as %(user) successful' green-banner on successful
logins. Does this meet your request?

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

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

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 16:24:23 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 15:24:23 +0000
Subject: [Tracker-discuss] [issue160] Can't make a query private once it's
	been made public
In-Reply-To: <1190680823.03.0.264914740135.issue160@psf.upfronthosting.co.za>
Message-ID: <1236266663.08.0.605935098054.issue160@psf.upfronthosting.co.za>


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

Actually, it *is* possible to make a query private once it's been made public.
In fact, any user can take a private query from you and make it private for him,
as well as making public queries private and vice-versa: issue 244.

----------
nosy: +ajaksu2

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

From draghuram at gmail.com  Thu Mar  5 16:24:23 2009
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Thu, 5 Mar 2009 10:24:23 -0500
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
Message-ID: <2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>

On Wed, Mar 4, 2009 at 11:12 PM, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:
> Hi,
> Does anyone want a shortcut for helping code review creation? It could
> either populate Rietveld's "Create New Issue" form or put a pre-filled
> command-line template for upload.py in a textarea.
>
> I don't have much experience with Rietveld, so (if there is demand for
> this feature) any suggestions on how to proceed would be useful.

Automatic creation of Rietveld issue from python's tracker may not be
possible because creation of issue requires a google login. Perhaps, a
user id can be registered for python's tracker and that can be used to
automatically create an issue. How ever, this still requires all the
reviewers to be added explicitly (either by themselves or by others).
It also  means that Rietveld mails show up in Roundup. I am not sure
if this is acceptable to every one.

Thanks,
Raghu

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 16:27:39 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 15:27:39 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1236266859.01.0.305549143256.issue16@psf.upfronthosting.co.za>


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

While this seems simple to implement, IMO the benefit is small and might
surprise/get in the way of tracker users.

Closing as won't fix suggested, will work on a patch if people still want this :)

----------
nosy: +ajaksu2

_______________________________________________________
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 Mar  5 16:30:03 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 15:30:03 +0000
Subject: [Tracker-discuss] [issue130] Submitter cannot withdraw issue
In-Reply-To: <1187789563.65.0.610907108426.issue130@psf.upfronthosting.co.za>
Message-ID: <1236267003.17.0.89753091482.issue130@psf.upfronthosting.co.za>


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

IMO we can live with this, closing suggested. Will try to figure a way to
implement it if someone finds this a must have.

----------
nosy: +ajaksu2

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

From ajaksu at gmail.com  Thu Mar  5 16:55:40 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 12:55:40 -0300
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
Message-ID: <2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>

Hi Raghu,
Thanks for the feedback!

Sorry, I was a bit unclear: the idea is to help creating Rietveld
issues on demand, much like is done manually today.

I've seen a few cases where setting the Roundup <-> Rietveld link
didn't work correctly, with e.g. review feedback not landing on the
tracker, new issues being created instead of adding review to the
correct one, etc. I'm still not sure about it being desirable, though
:)

Raghuram Devarakonda wrote:
> On Wed, Mar 4, 2009 at 11:12 PM, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:
>> Hi,
>> Does anyone want a shortcut for helping code review creation? It could
>> either populate Rietveld's "Create New Issue" form or put a pre-filled
>> command-line template for upload.py in a textarea.
>>
>> I don't have much experience with Rietveld, so (if there is demand for
>> this feature) any suggestions on how to proceed would be useful.
>
> Automatic creation of Rietveld issue from python's tracker may not be
> possible because creation of issue requires a google login. Perhaps, a
> user id can be registered for python's tracker and that can be used to
> automatically create an issue.

Yes, completely automatic issue creation isn't possible. Populating
Rietveld's "Create New Issue" form in an already-logged-in user's
browser should be possible. Generating a command for copy and paste
use with upload.py should be doable, too. Do you think that would be
of any use?

It might be too little help and too much complication :)

> How ever, this still requires all the
> reviewers to be added explicitly (either by themselves or by others).

I think it could add reviewers to the form or command-line, but it
would have no way of checking whether given IDs would be valid AFAIK.

> It also ?means that Rietveld mails show up in Roundup. I am not sure
> if this is acceptable to every one.

It's only desirable when someone requests a code review, as it happens
currently. Were this feature to make linking to Rietveld much easier
(or available to any user), your concern about polluting bugs-list
would fully apply. I think restricting the shortcut to Developers
might be a way out of that.

Best regards,
Daniel

From draghuram at gmail.com  Thu Mar  5 17:12:33 2009
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Thu, 5 Mar 2009 11:12:33 -0500
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
Message-ID: <2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>

On Thu, Mar 5, 2009 at 10:55 AM, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:

> Yes, completely automatic issue creation isn't possible. Populating
> Rietveld's "Create New Issue" form in an already-logged-in user's
> browser should be possible. Generating a command for copy and paste

"Create New Issue" form is very much discouraged (and may even go away
at some point of time).

> use with upload.py should be doable, too. Do you think that would be
> of any use?

I am not sure. Perhaps, a recommendation can be added to
http://www.python.org/dev/patches/ that mentions using Rietveld. In
addition, this link can also be shown right above the upload form in
Rietveld issue (may be a simple template change). A slight variation
would be to put the text "please consider uploading the patch at
http://codereview.appspot.com" above the upload form.

> It might be too little help and too much complication :)

Agreed.

>> How ever, this still requires all the
>> reviewers to be added explicitly (either by themselves or by others).
>
> I think it could add reviewers to the form or command-line, but it
> would have no way of checking whether given IDs would be valid AFAIK.

We can't be sure that all the members in the nosy list would want to
be automatically added to Rietveld issue (assuming that is what you
are implying). I guess there is no simple way of integrating Roundup
and Rietveld currently. I did bring this up on Rietveld list quite a
while back to which Guide replied that he didn't see any such need.

Thanks,
Raghu

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 17:16:59 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 16:16:59 +0000
Subject: [Tracker-discuss] [issue198] Set attributes in the body
In-Reply-To: <1205775053.19.0.471134513632.issue198@psf.upfronthosting.co.za>
Message-ID: <1236269819.85.0.655049776948.issue198@psf.upfronthosting.co.za>


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

I really like this idea and will try to implement it. Some discussion might help me:

Would it be acceptable to mimic the nosy-email format? That means fields below
message, after a '----------'.

Regardless of fields placement, should there be a marker/tag to explicitly
delimit commands? I ask that because, e.g., your original message could trigger
this behavior when you only wanted to discuss it.

Should the attribute-setting part be stripped from the message?

Should setting attributes both in subject and in body be allowed in a given message?

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

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

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 17:25:30 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 16:25:30 +0000
Subject: [Tracker-discuss] [issue50] Patches may be better displayed close
	to the message they were attached to.
In-Reply-To: <1163962319.6.0.763231898366.issue50@psf.upfronthosting.co.za>
Message-ID: <1236270330.62.0.710988312498.issue50@psf.upfronthosting.co.za>


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

I like the current 'all files before messages' layout. It neatly covers "the
problem of files that were uploaded without a change note".

If anyone still wants to have clear grouping of files to messages, I can add a
link to a message's file as a simple inline entry or a simple row below a message.

----------
nosy: +ajaksu2

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

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 17:49:07 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 16:49:07 +0000
Subject: [Tracker-discuss] [issue169] Improve gmail interaction
In-Reply-To: <1196188531.28.0.84959205083.issue169@psf.upfronthosting.co.za>
Message-ID: <1236271747.4.0.80533955465.issue169@psf.upfronthosting.co.za>


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

I think that for (b), setting the From to a bogus
"reports+<user>@bugs.python.org" but leaving a correct Reply-To should cover the
gmail use case, without MTA changes. The question would then be 'what MUAs does
it break?'. :)

----------
nosy: +ajaksu2

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

From ajaksu at gmail.com  Thu Mar  5 18:17:19 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 14:17:19 -0300
Subject: [Tracker-discuss] Tracker cleanup - Roundup hacking report :)
Message-ID: <2d75d7660903050917n340ede0u4746bc8395e07b12@mail.gmail.com>

Hi,
Here's a progress report on the "let's make the tracker a bit better" tasks.

Note: if you make use of saved queries, I recommend reading the
'anyone can remove any queries' issue:
http://psf.upfronthosting.co.za/roundup/meta/issue244

Feedback on meta-tracker open issues, as well as new RFEs and replies
to tracker-discuss threads should make the tracker meeting your needs
a bit more likely :)

Thanks Martin, Stefan, Jeroen, Ezio, Brett, Georg and others that
helped along the way.

Real tracker cleanup will be back soon ;)

Best regards,
Daniel

Open WIP tickets:
    add # of comments to default issue list
        Track the counts of messages and nosy users on a given issue.
        http://psf.upfronthosting.co.za/roundup/meta/issue87
(screenshot: http://psf.upfronthosting.co.za/roundup/meta/file110/msg_nosy_counts.png
)

    Add multiselects for searches
        This allows one to search, e.g., for issues with "Version in
['2.5', '2.6', '2.7']" or "Stage in ['patch review', 'not selected']".
        http://psf.upfronthosting.co.za/roundup/meta/issue243
(example: http://psf.upfronthosting.co.za/roundup/meta/file105/issue_search.html
)

    Add 'Mail me' button to messages and issues
        Similar to becoming nosy retroactively, by getting a past
message after the fact. This (supposedly) allows one to reply to any
message in an issue from email.
        http://psf.upfronthosting.co.za/roundup/meta/issue245

    Have issue ID search work from "search tracker" box
        Passing an ID into the "search tracker" box opens the issue
with the matching ID.
        http://psf.upfronthosting.co.za/roundup/meta/issue123

    Add 'Stage' to results page
        Adds 'Stage' as a column to the search results when 'Display'
is selected.
        http://psf.upfronthosting.co.za/roundup/meta/issue242

    "Search in All Issues" button
        http://psf.upfronthosting.co.za/roundup/meta/issue224

    Have CVS download of issue list put name rather than ID
        http://issues.roundup-tracker.org/issue955070

    Failed logins do not produce an error message
        Add a 'Login as %(user) successful' green-banner on successful logins
        http://psf.upfronthosting.co.za/roundup/meta/issue230

Tickets/ideas on sketching or local testing stage:

    notation to filter by logged-in user
        Allows 'reflexive' queries, like 'issues I've created',
'issues I follow', 'issues assigned to me'. Pending Query security
resolution.
        http://issues.roundup-tracker.org/issue1525113

    Shortcuts for selecting self in user lists: "Add me" for nosy and
"Claim" for assignee.

    Provide prev/next/show list links when going through a list of bugs
        http://psf.upfronthosting.co.za/roundup/meta/issue4

    Ability to specify non-matching criteria in filters/searches
        http://issues.roundup-tracker.org/issue678900

    Email me my current changes without submitting (a.k.a. 'Save')

    Allow searching for ranges for Number attributes
        http://issues.roundup-tracker.org/issue1182919

    input fields should have HTML id attributes
        http://issues.roundup-tracker.org/issue1513369

    Full text "AND" search has message scope, not issue scope
        http://issues.roundup-tracker.org/issue1155657

    Set attributes in the body
        http://psf.upfronthosting.co.za/roundup/meta/issue198

Closed tickets:
    Edit Queries screen should include a link to the search page
        http://psf.upfronthosting.co.za/roundup/meta/issue202
    Denote which dependencies issues have been closed
        http://psf.upfronthosting.co.za/roundup/meta/issue207
    Fix 'not closed' search
        http://psf.upfronthosting.co.za/roundup/meta/issue240
    Add 'Stage' to search page
        http://psf.upfronthosting.co.za/roundup/meta/issue239
    Add creator/assignee to search view
        http://psf.upfronthosting.co.za/roundup/meta/issue180

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 21:46:10 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 20:46:10 +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: <1236285970.41.0.295107430273.issue246@psf.upfronthosting.co.za>


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

Add a checkbox per issue on index (home, search results) pages and a button
that, when pressed, shows the same view but with only the previously selected
issues on display.

Hopefully this will enable us to cherry pick search results, bookmark arbitrary
issue sets and sets the foundations to allow merging result-sets.

The last chunk of the patch is pretty crude, making it better should also give
us stable "Sort on" pre-selection on displayed issue sets.

----------
files: display_selected.diff
messages: 1206
nosy: ajaksu2
priority: wish
status: unread
title: Allow display of selected issue sets

_______________________________________________________
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_selected.diff
Type: text/x-diff
Size: 4371 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090305/c5022fab/attachment-0001.diff>

From ajaksu at gmail.com  Thu Mar  5 21:57:24 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 17:57:24 -0300
Subject: [Tracker-discuss] [Python-Dev] Tracker cleanup - Roundup
	hacking report :)
In-Reply-To: <0016e644cf3261684904646266b2@google.com>
References: <2d75d7660903050917n340ede0u4746bc8395e07b12@mail.gmail.com>
	<0016e644cf3261684904646266b2@google.com>
Message-ID: <2d75d7660903051257x522ad38cp202ff05b8fd7cb81@mail.gmail.com>

Jesse Noller wrote:
> Slightly off topic Daniel, but if you see any multiprocessing bugs
> lurking out there, can you make me (jnoller) the assignee?

Sure!

FWIW, I've just submitted a patch[1] that will make working with
arbitrary issue sets much saner  and should have a 'mass-add user X as
nosy to selected issues' working locally before Saturday.

When these land on bugs.python.org, this kind of task will become so
easy that my job as tracker janitorveloper might become redundant :)

Cheers,
Daniel

[1]http://psf.upfronthosting.co.za/roundup/meta/issue246

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 22:51:17 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 05 Mar 2009 21:51:17 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1236289877.86.0.359712196801.issue16@psf.upfronthosting.co.za>


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

I still want to see automatic closing of pending issues. SF did that with a
message to all nosy users.

The "pending" status is set during triage, in the expectation that the issue
should likely be closed, unless somebody still comments. Addition of a new
comment reverts the status change. Only if there is no follow-up the issue gets
auto-closed.

Implementation-wise, I would recommend to run a cron job.

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

_______________________________________________________
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 Mar  5 22:52:37 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 05 Mar 2009 21:52:37 +0000
Subject: [Tracker-discuss] [issue130] Submitter cannot withdraw issue
In-Reply-To: <1187789563.65.0.610907108426.issue130@psf.upfronthosting.co.za>
Message-ID: <1236289957.37.0.439998886939.issue130@psf.upfronthosting.co.za>


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

I think this is a simple permissions problem. I prefer to see it fixed.

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

From martin at v.loewis.de  Thu Mar  5 22:59:30 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 05 Mar 2009 22:59:30 +0100
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>
Message-ID: <49B04B42.7090800@v.loewis.de>

> We can't be sure that all the members in the nosy list would want to
> be automatically added to Rietveld issue (assuming that is what you
> are implying). I guess there is no simple way of integrating Roundup
> and Rietveld currently. I did bring this up on Rietveld list quite a
> while back to which Guide replied that he didn't see any such need.

Whenever I use Rietveld to review a patch, I add report at bugs.python.org
to the CC list. This will indeed send all patch comments to all people
on the nosy list. It's clear (to me) that they indeed asked for getting
that email, so I cannot see anything wrong there.

I would like to see two things
a) make "Rietveld link" a part of the issue page (rendered only if there
   actually is one)
b) provide an upload script that has an option of giving a tracker issue
   number during upload, so that it can
   1. add the tracker to the Rietveld issue, and
   2. correctly set the subject of the Rietveld issue.

Regards,
Martin

From metatracker at psf.upfronthosting.co.za  Thu Mar  5 23:29:37 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Thu, 05 Mar 2009 22:29:37 +0000
Subject: [Tracker-discuss] [issue130] Submitter cannot withdraw issue
In-Reply-To: <1187789563.65.0.610907108426.issue130@psf.upfronthosting.co.za>
Message-ID: <1236292177.0.0.0316864956582.issue130@psf.upfronthosting.co.za>


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

The patch attached changes 'issue.status' permission in schema.py to parallel
those of 'Edit own query'. A tiny change to issue.item.html is then necessary,
as the assignee menu was displayed depending on 'status' permission :)

I think we could restrict the closing to issues with only one nosy user (when
that lands), so a user could give up until someone else replied.

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

From ajaksu at gmail.com  Fri Mar  6 00:29:25 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 20:29:25 -0300
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <49B04B42.7090800@v.loewis.de>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>
	<49B04B42.7090800@v.loewis.de>
Message-ID: <2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>

Martin v. L?wis wrote:
> I would like to see two things
> a) make "Rietveld link" a part of the issue page (rendered only if there
> ? actually is one)

It'll need a storage place, could be a Link, Multilink (if we cater to
multiple reviews of a single issue)  or simply a column in _issue
(hackish, but might be sufficient). Once we decide where this should
be stored, I can work on that, plus template and whatever behavior
change is necessary.

> b) provide an upload script that has an option of giving a tracker issue
> ? number during upload, so that it can
> ? 1. add the tracker to the Rietveld issue, and
> ? 2. correctly set the subject of the Rietveld issue.

OK, would a patch against Rietveld's upload.py be enough? Or should it
be a wrapper that forwards any command line options it doesn't handle
to upload.py?

Here's a proposed implementation for the 'correctly set the subject'
part, IIUC it should output a '--message' snippet to upload.py:

from urllib import urlopen, urlencode
def get_title(id, tracker='http://bugs.python.org'):
    # This should be the smallest query able to return an issue title
    query_tpl = [('@action', 'export_csv'), ('@columns', 'title'),
                 ('@filter', 'id'), ('id', id)]
    # Request path + query
    issue = '/issue?' + urlencode(query_tpl)
    title = urlopen(tracker + issue).readlines()
    if title[0] == 'title\r\n':
        # Got a single data row CSV, format and return it
        return '[issue%s] %s' % (id, title[1].strip())

Regards,
Daniel

From martin at v.loewis.de  Fri Mar  6 01:00:57 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 06 Mar 2009 01:00:57 +0100
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>	
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>	
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>	
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>	
	<49B04B42.7090800@v.loewis.de>
	<2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>
Message-ID: <49B067B9.7070008@v.loewis.de>

> It'll need a storage place, could be a Link, Multilink (if we cater to
> multiple reviews of a single issue)  or simply a column in _issue
> (hackish, but might be sufficient). Once we decide where this should
> be stored, I can work on that, plus template and whatever behavior
> change is necessary.

Just a regular string field. It could be the Rietveld issue number,
or the full code review URL. I don't find that hackish myself.

> OK, would a patch against Rietveld's upload.py be enough? Or should it
> be a wrapper that forwards any command line options it doesn't handle
> to upload.py?

I think a patch (or full file) would be good enough. We could put it
into the tracker itself, and publish it prominently where people
upload files.

> from urllib import urlopen, urlencode
> def get_title(id, tracker='http://bugs.python.org'):
>     # This should be the smallest query able to return an issue title
>     query_tpl = [('@action', 'export_csv'), ('@columns', 'title'),
>                  ('@filter', 'id'), ('id', id)]
>     # Request path + query
>     issue = '/issue?' + urlencode(query_tpl)
>     title = urlopen(tracker + issue).readlines()
>     if title[0] == 'title\r\n':
>         # Got a single data row CSV, format and return it
>         return '[issue%s] %s' % (id, title[1].strip())

Nice! I didn't think of something that complicated (or, rather,
complicated in a different way):

upload.py --roundup 5428

That could either fill in a description given by -d, or fetch
the description from roundup.

Regards,
Martin

From metatracker at psf.upfronthosting.co.za  Fri Mar  6 03:14:55 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 06 Mar 2009 02:14:55 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>


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

This adds a Rietveld Issue field that is hidden for Anonymous/Users when not set
and allows editing by Developers.

----------
files: rietveld.diff
messages: 1210
nosy: ajaksu2
priority: feature
status: unread
title: Add Rietveld Issue link

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

From ajaksu at gmail.com  Fri Mar  6 03:54:16 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Thu, 5 Mar 2009 23:54:16 -0300
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <49B067B9.7070008@v.loewis.de>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>
	<49B04B42.7090800@v.loewis.de>
	<2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>
	<49B067B9.7070008@v.loewis.de>
Message-ID: <2d75d7660903051854i7e75ba96ib88953230de2e5dd@mail.gmail.com>

Martin v. L?wis wrote:
>> It'll need a storage place, could be a Link, Multilink (if we cater to
>> multiple reviews of a single issue) ?or simply a column in _issue
>> (hackish, but might be sufficient). Once we decide where this should
>> be stored, I can work on that, plus template and whatever behavior
>> change is necessary.
>
> Just a regular string field. It could be the Rietveld issue number,
> or the full code review URL. I don't find that hackish myself.

It isn't hackish, I was (again) thinking of overcomplicated implementation :)

Here's an early attempt of adding it as a String (holding only the
Rietveld ID): http://psf.upfronthosting.co.za/roundup/meta/issue247

>> OK, would a patch against Rietveld's upload.py be enough? Or should it
>> be a wrapper that forwards any command line options it doesn't handle
>> to upload.py?
>
> I think a patch (or full file) would be good enough. We could put it
> into the tracker itself, and publish it prominently where people
> upload files.

I'll post it as a patch and a full file at issue 247 when I get to it.

[snip code]
> Nice! I didn't think of something that complicated (or, rather,
> complicated in a different way):
>
> upload.py --roundup 5428

Just to be clear, this will work as if the user passed the following options:

upload.py --message "[issue5428] Pyshell history management error"
--cc report at bugs.python.org

Right? :)

> That could either fill in a description given by -d, or fetch
> the description from roundup.

Fetching a description is as easy as fetching a title[1], but I can't
think of a fixed place to look for one (last message? last patch
description?). Maybe we can add another option that tells the script
where to fetch description/content from? Something like "
[-F|--fetch_description] msg83029" ?

Thanks for the guidance, Martin!

Best regards,
Daniel

[1] http://bugs.python.org/msg?@action=export_csv&@columns=content&@filter=id&id=83029

From metatracker at psf.upfronthosting.co.za  Fri Mar  6 15:07:57 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 06 Mar 2009 14:07:57 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236348477.43.0.673552219968.issue247@psf.upfronthosting.co.za>


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

A better implementation of fetching info from the Python tracker.

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

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

From ajaksu at gmail.com  Fri Mar  6 15:25:22 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 6 Mar 2009 11:25:22 -0300
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2d75d7660903051854i7e75ba96ib88953230de2e5dd@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>
	<49B04B42.7090800@v.loewis.de>
	<2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>
	<49B067B9.7070008@v.loewis.de>
	<2d75d7660903051854i7e75ba96ib88953230de2e5dd@mail.gmail.com>
Message-ID: <2d75d7660903060625i18a48121m39a5e0f633554f0e@mail.gmail.com>

CC'ing python-dev, as more RFEs might be uncovered :)

Daniel (ajax) Diniz wrote:
> Martin v. L?wis wrote:
>> I think a patch (or full file) would be good enough. We could put it
>> into the tracker itself, and publish it prominently where people
>> upload files.
>
> I'll post it as a patch and a full file at issue 247 when I get to it.

Posted as full file to
http://psf.upfronthosting.co.za/roundup/meta/issue247 , Guido suggests
the wrapper way so I won't bother with creating patches now.

> [snip code]
>> Nice! I didn't think of something that complicated (or, rather,
>> complicated in a different way):
>>
>> upload.py --roundup 5428
>
> Just to be clear, this will work as if the user passed the following options:
>
> upload.py --message "[issue5428] Pyshell history management error"
> --cc report at bugs.python.org
>
> Right? :)

If that is right, it works :)

>> That could either fill in a description given by -d, or fetch
>> the description from roundup.
>
> Fetching a description is as easy as fetching a title[1], but I can't
> think of a fixed place to look for one (last message? last patch
> description?). Maybe we can add another option that tells the script
> where to fetch description/content from? Something like "
> [-F|--fetch_description] msg83029" ?

Works too, for files or messages :)

Examples:
http://bugs.python.org/issue400608
http://bugs.python.org/issue2771
http://codereview.appspot.com/25073
http://codereview.appspot.com/24075

Thanks again,
Daniel

From metatracker at psf.upfronthosting.co.za  Fri Mar  6 16:33:10 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 06 Mar 2009 15:33:10 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236353590.68.0.644699288566.issue247@psf.upfronthosting.co.za>


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

Here's a detector that updates Rietveld ID when a message contents match
r'http://codereview.appspot.com/(\d+)'.

It defeats the rietveld_id restriction of Users. We could either lift that
restriction or enforce it in the detector, whatever makes more sense.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue247>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reviewauditor.py
Type: text/x-python
Size: 567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090306/75055a91/attachment.py>

From metatracker at psf.upfronthosting.co.za  Fri Mar  6 22:23:12 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 06 Mar 2009 21:23:12 +0000
Subject: [Tracker-discuss] [issue248] Mass-update/batch-editing support
In-Reply-To: <1236374592.31.0.943684755279.issue248@psf.upfronthosting.co.za>
Message-ID: <1236374592.31.0.943684755279.issue248@psf.upfronthosting.co.za>


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

This is a very rough (but working and happy-dance-inducing) patch that adds a
mass-update or batch-edit interface, along with underlying plumbing to make it work.

I'll try to post a few screenshots before Monday.

Entry point is dependent on issue 246 (which needs some love too). No
confirmation dialog is displayed, but the supporting parts are in place. The
template and code need some cleaning up, tests and docs.  It still lacks success
feedback (failure feedback is rough, but exists). No security checks are
implemented so far.

With so many open issues, one might question why post this at all. My only
answer to that would be yet another happy-dance :D

----------
files: batch_edit_01.diff
messages: 1214
nosy: ajaksu2
priority: wish
status: unread
title: Mass-update/batch-editing support

_______________________________________________________
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.diff
Type: text/x-diff
Size: 15652 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090306/be89acd3/attachment-0001.diff>

From jnoller at gmail.com  Thu Mar  5 18:21:34 2009
From: jnoller at gmail.com (jnoller at gmail.com)
Date: Thu, 05 Mar 2009 17:21:34 +0000
Subject: [Tracker-discuss] [Python-Dev] Tracker cleanup - Roundup
	hacking report :)
In-Reply-To: <2d75d7660903050917n340ede0u4746bc8395e07b12@mail.gmail.com>
Message-ID: <0016e644cf3261684904646266b2@google.com>

On Mar 5, 2009 12:17pm, "Daniel (ajax) Diniz" <ajaksu at gmail.com> wrote:
> Hi,

> Here's a progress report on the "let's make the tracker a bit better"  
> tasks.

...snip

Slightly off topic Daniel, but if you see any multiprocessing bugs lurking  
out there, can you make me (jnoller) the assignee?

jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090305/28fdb4cb/attachment-0001.htm>

From metatracker at psf.upfronthosting.co.za  Fri Mar  6 15:18:23 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 06 Mar 2009 14:18:23 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236349103.77.0.318649428782.issue247@psf.upfronthosting.co.za>


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

upload.py with Python Tracker (PT) issue fetched hacked in.

Allows fetching a PT issue title to set Rietveld issue subject (--message).
Fetches PT file description or message content to set Rietveld issue description
(--description). Adds PT's email to CC list (--cc).

I think a link from Rietveld issue to PT issue is a must have, adding the
command line could be nice too.

We could also add an option to set any PT issue Rietveld ID on successful code
review issue creation (would require asking for PT user email).

See the following issues for examples:
http://bugs.python.org/issue400608
http://bugs.python.org/issue2771
http://codereview.appspot.com/25073
http://codereview.appspot.com/24075

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue247>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload.py
Type: text/x-python
Size: 52760 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090306/c0ead2ca/attachment-0001.py>

From metatracker at psf.upfronthosting.co.za  Sat Mar  7 15:22:07 2009
From: metatracker at psf.upfronthosting.co.za (Philipp Gortan)
Date: Sat, 07 Mar 2009 14:22:07 +0000
Subject: [Tracker-discuss] [issue4] Provide prev/next/show list links when
	going through a list of bugs
Message-ID: <1236435727.31.0.0410062957653.issue4@psf.upfronthosting.co.za>


Philipp Gortan <mephinet at gmx.net> added the comment:

> ... and a positional pointer in a cookie.

This would need to be carefully crafted to not break
multiple-searches-in-multiple-tabs.

----------
nosy: +mephinet

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

From metatracker at psf.upfronthosting.co.za  Sat Mar  7 19:21:51 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 07 Mar 2009 18:21:51 +0000
Subject: [Tracker-discuss] [issue4] Provide prev/next/show list links when
	going through a list of bugs
Message-ID: <1236450111.79.0.25680968443.issue4@psf.upfronthosting.co.za>


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

Philipp Gortan wrote:
>This would need to be carefully crafted to not break
>multiple-searches-in-multiple-tabs.

True. I think using a hidden input for the pointer would both avoid
multiple-searches-in-multiple-tabs issues and fit better with the way Roundup
does similar things.

I got the pseudo-query part working (issue 246), during next week I'll polish it
and try to build the prev/next/show feature on top of that.

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

From metatracker at psf.upfronthosting.co.za  Sat Mar  7 23:15:33 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 07 Mar 2009 22:15:33 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
Message-ID: <1236464133.59.0.28189437956.issue16@psf.upfronthosting.co.za>


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

OK, I'll work on this one later.

A script that searches for pending issues and compares time since last activity
to a config limit sounds simple. Should set Stage ('committed/rejected') and
Resolution ('out of date' or 'invalid'?). Do you want it to set a Keyword (or
short note on auto-closing) to make searching for auto-closed issues easier?

A detector for pending -> open on comment is trivial.

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 10:00:35 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 09:00:35 +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: <1236502835.1.0.400119320769.issue244@psf.upfronthosting.co.za>


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

actions_query.diff is not appropriate to solve this problem: it puts knowledge
of a "keywords" class into roundup.

I don't quite understand the problem. If it is possible to edit arbitrary
queries through CSV, why is it not possible to edit arbitrary issues through CSV?

(I'm assuming it is not possible to edit arbitrary issues - if it was, we are in
much bigger problems)

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 10:09:30 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 09:09:30 +0000
Subject: [Tracker-discuss] [issue130] Submitter cannot withdraw issue
In-Reply-To: <1187789563.65.0.610907108426.issue130@psf.upfronthosting.co.za>
Message-ID: <1236503370.64.0.371762773266.issue130@psf.upfronthosting.co.za>


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

Thanks, committed as r70239.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 10:17:17 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 09:17:17 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236503837.84.0.496135686692.issue247@psf.upfronthosting.co.za>


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

With reviewauditor.py, what would the workflow look like for creating a tracker
issue with associated rietveld issue?

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 10:20:39 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 09:20:39 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236504039.48.0.862705663582.issue247@psf.upfronthosting.co.za>


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

Is it possible to have Rietveld not include the entire patch in the message, or
send it as an attachment? Or could we strip it out?

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 11:37:15 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 10:37:15 +0000
Subject: [Tracker-discuss] [issue87] add # of comments to default issue list
In-Reply-To: <1173534188.93.0.690515473058.issue87@psf.upfronthosting.co.za>
Message-ID: <1236508635.93.0.315060191067.issue87@psf.upfronthosting.co.za>


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

Thanks for the patch, committed as r70240; I also added sql commands to
initialize these fields.

One unfortunate side effect is that these two fields now show up in the journal;
I wish hyperdb supported a per-field flag to indicate that the field shouldn't
be journaled.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 11:42:27 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 10:42:27 +0000
Subject: [Tracker-discuss] [issue50] Patches may be better displayed close
	to the message they were attached to.
In-Reply-To: <1163962319.6.0.763231898366.issue50@psf.upfronthosting.co.za>
Message-ID: <1236508947.3.0.348584018654.issue50@psf.upfronthosting.co.za>


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

Ok, resolving it as "won't fix", then.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 11:45:05 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 10:45:05 +0000
Subject: [Tracker-discuss] [issue224] "Search in All Issues" button
In-Reply-To: <1223897016.78.0.0580124380517.issue224@psf.upfronthosting.co.za>
Message-ID: <1236509105.7.0.134229168276.issue224@psf.upfronthosting.co.za>


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

Ok, adding the radio button would be fine with me.

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 11:58:59 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 10:58:59 +0000
Subject: [Tracker-discuss] [issue242] Add 'Stage' to results page
In-Reply-To: <1235494805.03.0.629781097036.issue242@psf.upfronthosting.co.za>
Message-ID: <1236509939.22.0.544667951135.issue242@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r70241

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 12:01:30 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 11:01:30 +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: <1236510090.8.0.594434938174.issue246@psf.upfronthosting.co.za>


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

The patch is out of date. Can you please update it?

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 13:33:02 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 08 Mar 2009 12:33:02 +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: <1236515582.23.0.174627813992.issue244@psf.upfronthosting.co.za>


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

We could either ditch EditCSVAction entirely or add permission checks to it, if
it's an useful action. To solve this class of problems, I think it'd be
necessary to add another kind of permission ('EditCSV') to Roles and check for that.

Here's a temporary fix, given the potential hassle described in private email.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 14:10:18 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 13:10:18 +0000
Subject: [Tracker-discuss] [issue123] Have issue ID search work from "search
	tracker" box
In-Reply-To: <1186618913.24.0.852272975879.issue123@psf.upfronthosting.co.za>
Message-ID: <1236517818.4.0.747171895809.issue123@psf.upfronthosting.co.za>


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

ajaksu2, thanks for the patch. Committed as r70242.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 14:11:31 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 13:11:31 +0000
Subject: [Tracker-discuss] [issue238] Update 'initial_data.py' to match
	current values
In-Reply-To: <1235045063.45.0.472608826025.issue238@psf.upfronthosting.co.za>
Message-ID: <1236517891.41.0.33221242219.issue238@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r70243

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 14:47:31 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 13:47:31 +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: <1236520051.77.0.0976418934454.issue244@psf.upfronthosting.co.za>


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

I have now disabled editcsv for roundup.

I do think it is useful, as various coordinators use it to add components etc.
Of course, we could also create forms for it, or have people submit such
requests to this tracker, so I create the components through the command line -
however, the CSV interface is really convenient for distributed administration.

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

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

From skip at pobox.com  Sun Mar  8 14:47:52 2009
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 8 Mar 2009 08:47:52 -0500
Subject: [Tracker-discuss] Float?
Message-ID: <18867.52360.792787.515257@montanaro.dyndns.org>


    >> message_count: 23.0 -> 24.0
    >> nosy: +pitrou
    >> nosy_count: 5.0 -> 6.0

Maybe an int(...) call in the appropriate place is called for?

Skip

From martin at v.loewis.de  Sun Mar  8 14:49:11 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Mar 2009 14:49:11 +0100
Subject: [Tracker-discuss] Float?
In-Reply-To: <18867.52360.792787.515257@montanaro.dyndns.org>
References: <18867.52360.792787.515257@montanaro.dyndns.org>
Message-ID: <49B3CCD7.1040206@v.loewis.de>

>     >> message_count: 23.0 -> 24.0
>     >> nosy: +pitrou
>     >> nosy_count: 5.0 -> 6.0
> 
> Maybe an int(...) call in the appropriate place is called for?

Where exactly would you put this call?

It's not really possible without a lot of effort, AFAICT.

Regards,
Martin

From ajaksu at gmail.com  Sun Mar  8 15:00:00 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Sun, 8 Mar 2009 11:00:00 -0300
Subject: [Tracker-discuss] Float?
In-Reply-To: <49B3CCD7.1040206@v.loewis.de>
References: <18867.52360.792787.515257@montanaro.dyndns.org>
	<49B3CCD7.1040206@v.loewis.de>
Message-ID: <2d75d7660903080700t32ed84dbsf6d51ec33f6e293d@mail.gmail.com>

"Martin v. L?wis" wrote:
>> ? ? >> message_count: 23.0 -> 24.0
>> ? ? >> nosy: +pitrou
>> ? ? >> nosy_count: 5.0 -> 6.0
>>
>> Maybe an int(...) call in the appropriate place is called for?
>
> Where exactly would you put this call?
>
> It's not really possible without a lot of effort, AFAICT.

Regarding the display, Antoine finds it distracting and I think it
might be better to suppress it from the history log.

Now, the implementation...

My goal here is to make these fields searchable and proper @columns
(so one can opt to show/hide on issues lists). However, searching for
exact number of messages is silly, so I need to add the ability of
searching for intervals ('less than four messages').

I still want to tweak this, so it might end being a String (or I might
have to add an Integer _Type, as Number is float). Or a float will
work fine :)

Regards,
Daniel

From martin at v.loewis.de  Sun Mar  8 15:21:14 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 08 Mar 2009 15:21:14 +0100
Subject: [Tracker-discuss] Float?
In-Reply-To: <2d75d7660903080700t32ed84dbsf6d51ec33f6e293d@mail.gmail.com>
References: <18867.52360.792787.515257@montanaro.dyndns.org>	
	<49B3CCD7.1040206@v.loewis.de>
	<2d75d7660903080700t32ed84dbsf6d51ec33f6e293d@mail.gmail.com>
Message-ID: <49B3D45A.2070701@v.loewis.de>

> Regarding the display, Antoine finds it distracting and I think it
> might be better to suppress it from the history log.
> 
> Now, the implementation...
> 
> My goal here is to make these fields searchable and proper @columns
> (so one can opt to show/hide on issues lists). However, searching for
> exact number of messages is silly, so I need to add the ability of
> searching for intervals ('less than four messages').
> 
> I still want to tweak this, so it might end being a String (or I might
> have to add an Integer _Type, as Number is float). Or a float will
> work fine :)

I don't think anything improves by making them Int or String - they
continue to clutter the history log, and the change messages that get
send out.

If people feel that the status quo is completely unacceptable, I could
disable the countauditor for the moment, and update all counts on a
daily basis with a cron job.

However, I'd rather prefer to get support for "hidden" properties in
a hyperdb class. Those would not get displayed in places where changed
properties normally get displayed, and they wouldn't be searchable.

Regards,
Martin

From skip at pobox.com  Sun Mar  8 16:08:59 2009
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 8 Mar 2009 10:08:59 -0500
Subject: [Tracker-discuss] Float?
In-Reply-To: <49B3CCD7.1040206@v.loewis.de>
References: <18867.52360.792787.515257@montanaro.dyndns.org>
	<49B3CCD7.1040206@v.loewis.de>
Message-ID: <18867.57227.974276.598079@montanaro.dyndns.org>

    >> >> message_count: 23.0 -> 24.0
    >> >> nosy: +pitrou
    >> >> nosy_count: 5.0 -> 6.0
    >> 
    >> Maybe an int(...) call in the appropriate place is called for?

    Martin> Where exactly would you put this call?

    Martin> It's not really possible without a lot of effort, AFAICT.

I haven't the slightest idea, not being familiar with the code.  I was just
pointing out the problem.  Can the output be formatted easily with the
equivalent of "%.0f"?

Skip

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 16:57:25 2009
From: metatracker at psf.upfronthosting.co.za (Philipp Gortan)
Date: Sun, 08 Mar 2009 15:57:25 +0000
Subject: [Tracker-discuss] [issue4] Provide prev/next/show list links when
	going through a list of bugs
Message-ID: <1236527845.09.0.841775044478.issue4@psf.upfronthosting.co.za>


Philipp Gortan <mephinet at gmx.net> added the comment:

I've tried to come up with a patch for this - you might want to take a look at
it. See upstream tracker:
<http://issues.roundup-tracker.org/issue1876221>

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

From martin at v.loewis.de  Sun Mar  8 17:42:05 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Mar 2009 17:42:05 +0100
Subject: [Tracker-discuss] Float?
In-Reply-To: <18867.57227.974276.598079@montanaro.dyndns.org>
References: <18867.52360.792787.515257@montanaro.dyndns.org>
	<49B3CCD7.1040206@v.loewis.de>
	<18867.57227.974276.598079@montanaro.dyndns.org>
Message-ID: <49B3F55D.5040706@v.loewis.de>

> I haven't the slightest idea, not being familiar with the code.  I was just
> pointing out the problem.  Can the output be formatted easily with the
> equivalent of "%.0f"?

I don't think it can.

Regards,
Martin

From metatracker at psf.upfronthosting.co.za  Sun Mar  8 20:19:55 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 08 Mar 2009 19:19:55 +0000
Subject: [Tracker-discuss] [issue16] Automatic issue expiration
In-Reply-To: <1236464133.59.0.28189437956.issue16@psf.upfronthosting.co.za>
Message-ID: <49B41A55.1090202@v.loewis.de>


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

Daniel Diniz wrote:
> Should set Stage ('committed/rejected') and
> Resolution ('out of date' or 'invalid'?).

No - whoever sets it pending should already put it into its final state.

> Do you want it to set a Keyword (or
> short note on auto-closing) to make searching for auto-closed issues easier?

Not sure; we should leave it out for now (it should be possible to find
autoclosed by looking for issues that were closed by admin, if necessary).

SF sent a message to all nosy users explaining what autoclose is. This
message got also logged into the regular message list (IIRC). It might
be useful to send a message here as well; if possible, IMO, it should
be a plain email message, not a roundup message that gets a messageid
and associated with the issue. SF's wording is

"""This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker)."""

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

From martin at v.loewis.de  Sun Mar  8 20:35:56 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sun, 08 Mar 2009 20:35:56 +0100
Subject: [Tracker-discuss] Adding a "Rietveld this" button?
In-Reply-To: <2d75d7660903051854i7e75ba96ib88953230de2e5dd@mail.gmail.com>
References: <2d75d7660903042012y70883ea0r3b48fba3405e1a08@mail.gmail.com>	
	<2c51ecee0903050724x2cfd1a50oe8838e9280de3696@mail.gmail.com>	
	<2d75d7660903050755i37f6f107hb1fd14bd533684ca@mail.gmail.com>	
	<2c51ecee0903050812j5f8e21bdp9d50743b139ef8c9@mail.gmail.com>	
	<49B04B42.7090800@v.loewis.de>	
	<2d75d7660903051529i5300e170rc2c655fd6fdfd14a@mail.gmail.com>	
	<49B067B9.7070008@v.loewis.de>
	<2d75d7660903051854i7e75ba96ib88953230de2e5dd@mail.gmail.com>
Message-ID: <49B41E1C.1070303@v.loewis.de>

>> upload.py --roundup 5428
> 
> Just to be clear, this will work as if the user passed the following options:
> 
> upload.py --message "[issue5428] Pyshell history management error"
> --cc report at bugs.python.org
> 
> Right? :)

Not sure whether it's still relevant - yes, that is how it should work.
But I guess you have figured that out by now.

> Fetching a description is as easy as fetching a title[1], but I can't
> think of a fixed place to look for one (last message? last patch
> description?). Maybe we can add another option that tells the script
> where to fetch description/content from? Something like "
> [-F|--fetch_description] msg83029" ?

What's wrong with using the issue title itself?

Regards,
Martin

From metatracker at psf.upfronthosting.co.za  Tue Mar 10 01:18:55 2009
From: metatracker at psf.upfronthosting.co.za (Amaury Forgeot d'Arc)
Date: Tue, 10 Mar 2009 00:18:55 +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: <1236644335.96.0.047685692214.issue249@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Almost every email shows the change of the message_count and nosy_count 
properties. For 
example:
http://mail.python.org/pipermail/python-bugs-list/2009-March/072600.html
contains:
    message_count: 17.0 -> 18.0
    nosy: +ncoghlan
    nosy_count: 7.0 -> 8.0

I suggest to remove these fields from the emails: they are only noise, and tend 
to hide 
more import changes (the status for example)

----------
messages: 1233
nosy: amaury.forgeotdarc
priority: feature
status: unread
title: message_count and nosy_count changes appear in every mail

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

From metatracker at psf.upfronthosting.co.za  Tue Mar 10 02:21:35 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 10 Mar 2009 01:21:35 +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: <1236648095.65.0.940103343.issue249@psf.upfronthosting.co.za>


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

Unfortunately, that's difficult to implement.

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

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

From metatracker at psf.upfronthosting.co.za  Tue Mar 10 02:35:16 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 10 Mar 2009 01:35: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: <2d75d7660903091835x16605859p9e51756808b95b04@mail.gmail.com>


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

Amaury Forgeot d'Arc wrote:
> I suggest to remove these fields from the emails: they are only noise, and tend
> to hide more import changes (the status for example)

I'll try to hide them in emails and the history log.

----------
nosy: +ajaksu2

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

From metatracker at psf.upfronthosting.co.za  Tue Mar 10 16:05:39 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 10 Mar 2009 15:05:39 +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: <1236697539.69.0.832750618801.issue249@psf.upfronthosting.co.za>


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

This patch cleans the history log, emails and ok_message. Might fix it in a more
elegant way later, but should be enough for now.

_______________________________________________________
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: nosy_noise.diff
Type: text/x-diff
Size: 2924 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090310/7b91e1b2/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Tue Mar 10 17:45:18 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 10 Mar 2009 16:45:18 +0000
Subject: [Tracker-discuss] [issue247] Add Rietveld Issue link
In-Reply-To: <1236305695.18.0.109184453171.issue247@psf.upfronthosting.co.za>
Message-ID: <1236703518.31.0.459008775769.issue247@psf.upfronthosting.co.za>


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

It seems that setting the debug level to info avoids the inlining of the patch.
I'm mailing codereview-discuss to make sure :)

So far, the workflow for a new issue would be:
1 - Create a Roundup issue (RoI)
2 - Use the modified upload.py to create a Rietveld issue (RiI) that has a
reference to RoI in the subject. This adds a link to RoI at RiI. Uploading the
patch to RoI should be possible.
3 - The auditor creates a link in RoI to RiI

Any suggestions on this?

Before we add this, I'd like to have this workflow available:
1 - Using the modified upload.py, set a description and ask it to create a new
Roundup issue.
2 - It creates the issue and adds the patch
3 - Start at 2 in the above workflow :)

I have a script that does the 'create a new Roundup issue from command line'
working, just have to spend some time adding the bits to upload.py or a wrapper.

_______________________________________________________
PSF Meta Tracker <metatracker at psf.upfronthosting.co.za>
<http://psf.upfronthosting.co.za/roundup/meta/issue247>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload.py
Type: text/x-python
Size: 53061 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090310/f48cab5b/attachment-0001.py>

From ajaksu at gmail.com  Tue Mar 10 20:33:20 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Tue, 10 Mar 2009 16:33:20 -0300
Subject: [Tracker-discuss] looking at all issues before pycon
In-Reply-To: <Pine.LNX.4.64.0903101353100.2596@kimball.webabinitio.net>
References: <43c8685c0903092025j14883a1cwa6a182535a6fe8a8@mail.gmail.com>
	<2d75d7660903092105n17bc5a5fke2c373be0e00705b@mail.gmail.com>
	<Pine.LNX.4.64.0903101353100.2596@kimball.webabinitio.net>
Message-ID: <2d75d7660903101233i64a94df2p794ff9024ba38bc4@mail.gmail.com>

Hi David,

R. David Murray wrote:
> On Tue, 10 Mar 2009 at 01:05, Daniel (ajax) Diniz wrote:
>>
>> I plan to take a look at all open issues before PyCon, do you want to
>> join forces? :)
>
> I would like to help out with this. ?I've joined tracker-discuss, any
> place else I should plug in?

Great! Thanks a lot for joining! Go Tracker-Team-That-Has-No-Name! :)

Not any other place that I know of.

> Any thoughts on how to split up the workload? ?I don't have tons of time
> available, but I should have at least an hour a day for this.

I think we could delimit chunks (based on interest areas or simply ID
sequences) and use a shared tasklist (Google Docs, the wiki?) to
'claim' and mark them as done. Once we decide how things should be
split, displaying a group of issues in a browser is pretty easy[1].

Some properties need Developer rights to change, we could set a queue
for these and I'd go through it, or the Python core devs could decide
to give you Developer rights too.

> What is your desired outcome when an issue is "looked at"?

Short version: Add value to it...

Not-quite-so-short version: ... either by updating
versions/components/title, confirming the described behavior still
exists, denoting it's likely a won't-fix/out of date/invalid, filling
the Stage/Type/Dependencies fields or even providing
tests/patches/patch reviews.

Longer-than-I-expect-anyone-to-want-to-read-but-helped-me-review-the-process
version: See below :)

Best regards,
Daniel

---
Huge-I-told-you-so-feel-free-to-skip version:
    [2] Issue categorization will look like this last Bug Season[3] (adding
    details to tickets), but hopefully with a saner workflow. There are a
    few clear sets of similar issues, e.g. about socket, handling of
    characters on network protocol and format parsing modules, Tkinter +
    IDLE, etc., that could use grouping and closing of duplicates. A
    suggested form of grouping would be 'umbrella' or 'grab-bag' issues,
    with existing issues of a topic as dependencies.
    [...]
    Issue categorization
    - present better statistics about the open issues
    - maybe add grab-bag issues (3rd party patch available)
    - assorted closing, updating and poking old issues
[...]
    [4] I've marked some issues (25 now) to close, mostly because:
    - there was no reply from OP, nor a clear justification for the issue;
    - there are messages explaining why the issue is invalid;
    - the OSes/versions of the report suggest the issue is currently invalid;
[...]
    [5][...]verifying, adding tests, updating or closing as
    needed the recently changed old issues [...]
[...]
    [6] [Brett Cannon]
    One thing to keep an eye on for old issues, Daniel, is the Stage field.
    Setting that is nice for Bug Days as people can see what issues still need a
    test written or could use a review, etc. I have a doc I am writing up at
    http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the
    various Stage values should mean. Feedback from you and anybody else is
    welcome, although realize it is rough as I was not planning to make this
    public quite yet.
[...]
    [7] I'd like to nominate a couple (minor) RFEs and bug
    fixes for 3.1. By 'nominate' I mean 'group related issues together,
    offer tests, docs, patches and/or reviews as needed and
    ask-pretty-please-for-inclusion'

---
[1] Here's a little secret sauce:

http://bugs.python.org/issue?@action=search&id=5469,5468,5467,5466,5465

You have no idea how happy I was when I saw that :)

The 'ID' field in the search page works just like that. I plan to
offer patch to add a small textarea in the tracker where you can paste
IDs (coma-, space- and/or newline-separated) and get that kind of
list. It should also display the IDs of all issues shown in the
current page, so merging search results will be easier.

It looks a bit crowded, but you can append
"&@columns=id,title,activity" to that URL and get a clean list.
---
[2] http://mail.python.org/pipermail/python-dev/2009-February/086171.html
---
[3] http://mail.python.org/pipermail/python-dev/2009-February/086157.html
---
[4] http://mail.python.org/pipermail/python-dev/2009-February/086151.html
---
[5] http://mail.python.org/pipermail/python-dev/2009-February/086016.html
---
[6] http://mail.python.org/pipermail/python-dev/2009-February/086019.html
---
[7] http://mail.python.org/pipermail/python-dev/2009-March/086661.html

From metatracker at psf.upfronthosting.co.za  Wed Mar 11 00:04:01 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 10 Mar 2009 23:04:01 +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: <1236726241.09.0.344835207759.issue249@psf.upfronthosting.co.za>


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

Ok, committed as r70304. This is very hackish, so I do plan to revert it at some
point entirely. cbb - could be better.

----------
status: chatting -> done-cbb

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

From metatracker at psf.upfronthosting.co.za  Wed Mar 11 01:52:57 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 11 Mar 2009 00:52:57 +0000
Subject: [Tracker-discuss] [issue249] message_count and nosy_count changes
	appear in every mail
In-Reply-To: <1236726241.09.0.344835207759.issue249@psf.upfronthosting.co.za>
Message-ID: <2d75d7660903101752pc471fa5x2599495412dfdd9d@mail.gmail.com>


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

Martin v. L?wis wrote:
> Ok, committed as r70304. This is very hackish, so I do plan to revert it at some
> point entirely. cbb - could be better.

I agree completely and will work on it soon. I see two cleaner ways to
do this, both below the template layer.

The first is making the change-list builders more flexible, so they
accept a list of properties to ignore. This would touch
roundupdb.generateChangeNote and cgi.templating._HTMLItem.history. The
ignore list would be provided by templates and by the sendmail
detector.

Or we could create a new _Type (say, Integer) that would be
initialized with "do_journal='no'" and wouldn't appear in history
logs. I haven't seen a way to register new _Types so far, so it might
have to happen in hyperdb.

These fields need a searching interface, display in index/item views
and a way to search for intervals, so we're definitely going to spend
a bit of time on them :)

Regards,
Daniel

----------
status: done-cbb -> chatting

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

From metatracker at psf.upfronthosting.co.za  Wed Mar 11 19:38:26 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 11 Mar 2009 18:38:26 +0000
Subject: [Tracker-discuss] [issue225] Ordering of messages is incorrect for
	some jython issues.
In-Reply-To: <1225134556.68.0.873773412263.issue225@psf.upfronthosting.co.za>
Message-ID: <1236796706.49.0.736229989834.issue225@psf.upfronthosting.co.za>


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

I just found one issue in the Python Tracker that has one message messing the
ordering: http://bugs.python.org/issue1817

It has a SpamBayes score of 0.0, FWIW.

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

From metatracker at psf.upfronthosting.co.za  Wed Mar 11 20:44:34 2009
From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 11 Mar 2009 19:44:34 +0000
Subject: [Tracker-discuss] [issue225] Ordering of messages is incorrect for
	some jython issues.
In-Reply-To: <1225134556.68.0.873773412263.issue225@psf.upfronthosting.co.za>
Message-ID: <1236800674.27.0.633986164136.issue225@psf.upfronthosting.co.za>


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

For the msg class, both labelprop() and orderprop() give "activity", apparently
because that is the alphabetically smallest property. Since setting the spam
value creates activity, the sorting changes.

I think sorting by creation should work fine. I tried setorderprop; this failed
since orderprop is apparently not used for sorting (???). I also tried
setlabelprop; however, setting the labelprop is futile since then the
default_to_id flag doesn't work anymore (so the labelprop would not be 'id' when
the flag is set).

I fixed it in r70313 and r70314 by sorting explicitly in the html template.

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

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

From metatracker at psf.upfronthosting.co.za  Sun Mar 15 02:13:31 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sun, 15 Mar 2009 01:13:31 +0000
Subject: [Tracker-discuss] [issue250] Duplicated X-Roundup-issue-* headers
	in emails
In-Reply-To: <1237079611.46.0.352998786934.issue250@psf.upfronthosting.co.za>
Message-ID: <1237079611.46.0.352998786934.issue250@psf.upfronthosting.co.za>


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

The code that adds "X-Roundup-issue-*" headers to emails sent by the tracker is
duplicated, resulting in duplicated headers.

This patch removes such duplication.

----------
files: duplicated_headers.diff
messages: 1242
nosy: ajaksu2
priority: bug
status: unread
title: Duplicated X-Roundup-issue-* headers in emails

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

From martin at v.loewis.de  Sun Mar 15 23:28:06 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 15 Mar 2009 23:28:06 +0100
Subject: [Tracker-discuss] Roundup upgrade
Message-ID: <49BD80F6.40909@v.loewis.de>

I just upgraded roundup to 1.4.7. Please let me know if you find
any problems in its operation.

Regards,
Martin

From dirkjan at ochtman.nl  Mon Mar 16 10:58:47 2009
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Mon, 16 Mar 2009 10:58:47 +0100
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <49BD80F6.40909@v.loewis.de>
References: <49BD80F6.40909@v.loewis.de>
Message-ID: <ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>

On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I just upgraded roundup to 1.4.7. Please let me know if you find
> any problems in its operation.

I get timeouts from bugs.python.org. Would that be related?

Other stuff on python.org seems to work.

Cheers,

Dirkjan

From ajaksu at gmail.com  Mon Mar 16 13:28:43 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 16 Mar 2009 09:28:43 -0300
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
References: <49BD80F6.40909@v.loewis.de>
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
Message-ID: <2d75d7660903160528x41a68645n8e68bea69151c332@mail.gmail.com>

Dirkjan Ochtman wrote:
> On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis" wrote:
>> I just upgraded roundup to 1.4.7. Please let me know if you find
>> any problems in its operation.
>
> I get timeouts from bugs.python.org. Would that be related?
>
> Other stuff on python.org seems to work.

 http://issues.roundup-tracker.org/ is down too,  as is
http://psf.upfronthosting.co.za/roundup/meta/ :/

Daniel

From fwierzbicki at gmail.com  Mon Mar 16 13:32:52 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Mon, 16 Mar 2009 08:32:52 -0400
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <2d75d7660903160528x41a68645n8e68bea69151c332@mail.gmail.com>
References: <49BD80F6.40909@v.loewis.de>
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
	<2d75d7660903160528x41a68645n8e68bea69151c332@mail.gmail.com>
Message-ID: <4dab5f760903160532s7c375a41o2d6a59a6ed5bc6f1@mail.gmail.com>

http://bugs.jython.org is also down.

-Frank

From martin at v.loewis.de  Mon Mar 16 22:17:28 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 16 Mar 2009 22:17:28 +0100
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
References: <49BD80F6.40909@v.loewis.de>
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
Message-ID: <49BEC1E8.2000603@v.loewis.de>

Dirkjan Ochtman wrote:
> On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I just upgraded roundup to 1.4.7. Please let me know if you find
>> any problems in its operation.
> 
> I get timeouts from bugs.python.org. Would that be related?

I don't know. I can't login into the machine anymore.

Regards,
Martin

From brett at python.org  Mon Mar 16 22:51:20 2009
From: brett at python.org (Brett Cannon)
Date: Mon, 16 Mar 2009 14:51:20 -0700
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <49BEC1E8.2000603@v.loewis.de>
References: <49BD80F6.40909@v.loewis.de>
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
	<49BEC1E8.2000603@v.loewis.de>
Message-ID: <bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>

On Mon, Mar 16, 2009 at 14:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> Dirkjan Ochtman wrote:
> > On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis" <martin at v.loewis.de>
> wrote:
> >> I just upgraded roundup to 1.4.7. Please let me know if you find
> >> any problems in its operation.
> >
> > I get timeouts from bugs.python.org. Would that be related?
>
> I don't know. I can't login into the machine anymore.


Has anyone emailed the Upfront guys?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090316/10f22cd8/attachment.htm>

From seefeld at sympatico.ca  Mon Mar 16 22:55:41 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 16 Mar 2009 17:55:41 -0400
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
References: <49BD80F6.40909@v.loewis.de>	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>	<49BEC1E8.2000603@v.loewis.de>
	<bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
Message-ID: <49BECADD.5050506@sympatico.ca>

Brett Cannon wrote:
>
>
> On Mon, Mar 16, 2009 at 14:17, "Martin v. L?wis" <martin at v.loewis.de 
> <mailto:martin at v.loewis.de>> wrote:
>
>     Dirkjan Ochtman wrote:
>     > On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis"
>     <martin at v.loewis.de <mailto:martin at v.loewis.de>> wrote:
>     >> I just upgraded roundup to 1.4.7. Please let me know if you find
>     >> any problems in its operation.
>     >
>     > I get timeouts from bugs.python.org <http://bugs.python.org>.
>     Would that be related?
>
>     I don't know. I can't login into the machine anymore.
>
>
> Has anyone emailed the Upfront guys?

Here is how the problem looks like from my end (Montreal, Canada):

[stefan at quasimodo ~]$ ping issues.roundup-tracker.org
PING issues.roundup-tracker.org (88.198.142.26) 56(84) bytes of data.
 From 213.239.244.101 icmp_seq=3 Destination Host Unreachable

(that's the same machine as bugs.python.org)

It has been like this for the entire day.


Regards,
       Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From martin at v.loewis.de  Mon Mar 16 23:44:20 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 16 Mar 2009 23:44:20 +0100
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
References: <49BD80F6.40909@v.loewis.de>	
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>	
	<49BEC1E8.2000603@v.loewis.de>
	<bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
Message-ID: <49BED644.5030908@v.loewis.de>

>     I don't know. I can't login into the machine anymore.
> 
> 
> Has anyone emailed the Upfront guys?

I did.

Martin

From brett at python.org  Mon Mar 16 23:44:56 2009
From: brett at python.org (Brett Cannon)
Date: Mon, 16 Mar 2009 15:44:56 -0700
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <49BED644.5030908@v.loewis.de>
References: <49BD80F6.40909@v.loewis.de>
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>
	<49BEC1E8.2000603@v.loewis.de>
	<bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
	<49BED644.5030908@v.loewis.de>
Message-ID: <bbaeab100903161544u56a42728kf3c8fa1e9ca145b3@mail.gmail.com>

On Mon, Mar 16, 2009 at 15:44, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> >     I don't know. I can't login into the machine anymore.
> >
> >
> > Has anyone emailed the Upfront guys?
>
> I did.


Thanks, Martin.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090316/eb0ade81/attachment.htm>

From martin at v.loewis.de  Tue Mar 17 07:15:29 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 17 Mar 2009 07:15:29 +0100
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <49BED644.5030908@v.loewis.de>
References: <49BD80F6.40909@v.loewis.de>	
	<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>	
	<49BEC1E8.2000603@v.loewis.de>
	<bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>
	<49BED644.5030908@v.loewis.de>
Message-ID: <49BF4001.9090500@v.loewis.de>

Martin v. L?wis wrote:
>>     I don't know. I can't login into the machine anymore.
>>
>>
>> Has anyone emailed the Upfront guys?

It turned out that the physical host (that hosts the virtual
machine) crashed; so it had nothing to do with the upgrade.
The trackers are now back up.

Regards,
Martin

From izak at upfrontsystems.co.za  Tue Mar 17 08:36:47 2009
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Tue, 17 Mar 2009 09:36:47 +0200
Subject: [Tracker-discuss] Roundup upgrade
In-Reply-To: <49BF4001.9090500@v.loewis.de>
References: <49BD80F6.40909@v.loewis.de>		<ea2499da0903160258x50419187n1d3c49a338c02ce6@mail.gmail.com>		<49BEC1E8.2000603@v.loewis.de>	<bbaeab100903161451u4a6cdd9dnf64d30aafa97d97b@mail.gmail.com>	<49BED644.5030908@v.loewis.de>
	<49BF4001.9090500@v.loewis.de>
Message-ID: <49BF530F.9000406@upfrontsystems.co.za>

Hi guys,

Martin v. L?wis wrote:
> It turned out that the physical host (that hosts the virtual
> machine) crashed; so it had nothing to do with the upgrade.
> The trackers are now back up.

We'd like to apologise for the crash, or more accurately, for not 
noticing sooner. The parent host (we call it Nina) ran out of memory and 
locked up.

Usually we notice immediately, but there was a regression during a 
recent nagios upgrade. Naturally this event means there is now much 
pressure on our nagios guy to get it fixed.

regards,
Izak

From support at upfrontsystems.co.za  Tue Mar 17 07:10:52 2009
From: support at upfrontsystems.co.za (Gustav Franzsen)
Date: Tue, 17 Mar 2009 06:10:52 -0000
Subject: [Tracker-discuss] [issue6803] Roundup upgrade
In-Reply-To: <49BECADD.5050506@sympatico.ca>
Message-ID: <1237270216.6574.0.camel@z60m>


Gustav Franzsen <gustav at upfrontsystems.co.za> added the comment:

Assigned to Gareth


On Mon, 2009-03-16 at 21:56 +0000, Stefan Seefeld wrote:
> New submission from Stefan Seefeld <seefeld at sympatico.ca>:
> 
> Brett Cannon wrote:
> >
> >
> > On Mon, Mar 16, 2009 at 14:17, "Martin v. L?wis" <martin at v.loewis.de 
> > <mailto:martin at v.loewis.de>> wrote:
> >
> >     Dirkjan Ochtman wrote:
> >     > On Sun, Mar 15, 2009 at 23:28, "Martin v. L?wis"
> >     <martin at v.loewis.de <mailto:martin at v.loewis.de>> wrote:
> >     >> I just upgraded roundup to 1.4.7. Please let me know if you find
> >     >> any problems in its operation.
> >     >
> >     > I get timeouts from bugs.python.org <http://bugs.python.org>.
> >     Would that be related?
> >
> >     I don't know. I can't login into the machine anymore.
> >
> >
> > Has anyone emailed the Upfront guys?
> 
> Here is how the problem looks like from my end (Montreal, Canada):
> 
> [stefan at quasimodo ~]$ ping issues.roundup-tracker.org
> PING issues.roundup-tracker.org (88.198.142.26) 56(84) bytes of data.
>  From 213.239.244.101 icmp_seq=3 Destination Host Unreachable
> 
> (that's the same machine as bugs.python.org)
> 
> It has been like this for the entire day.
> 
> 
> Regards,
>        Stefan
> 
> 

-- 
Gustav Franzsen         www.upfrontsystems.co.za

----------
assignedto:  -> gareth
priority:  -> highest
status: unread -> chatting
title: [Tracker-discuss] Roundup upgrade -> Roundup upgrade

________________________________________________________
Upfront Systems support <support at upfrontsystems.co.za>
<https://roundup.upfrontsystems.co.za/support/issue6803>
________________________________________________________

From metatracker at psf.upfronthosting.co.za  Tue Mar 17 22:44:09 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 17 Mar 2009 21:44:09 +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: <1237326249.1.0.106099905867.issue249@psf.upfronthosting.co.za>


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

Here's a small change to roundup-src that allows omitting message and nosy
counts more cleanly. It applies to both template history and email messages.

_______________________________________________________
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_roundup.diff
Type: text/x-diff
Size: 2163 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090317/5ee9b439/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Tue Mar 17 22:46:23 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Tue, 17 Mar 2009 21:46:23 +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: <1237326383.4.0.281417198974.issue249@psf.upfronthosting.co.za>


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

This patch reverts nosy_noise.diff and sets .do_journal=False to message_count
and nosy_count, allowing them to be omitted from emails and template change history.

_______________________________________________________
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_instance.diff
Type: text/x-diff
Size: 3804 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090317/71887410/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Wed Mar 18 01:33:21 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 18 Mar 2009 00:33:21 +0000
Subject: [Tracker-discuss] [issue250] Duplicated X-Roundup-issue-* headers
	in emails
In-Reply-To: <1237079611.46.0.352998786934.issue250@psf.upfronthosting.co.za>
Message-ID: <1237336401.37.0.897754986052.issue250@psf.upfronthosting.co.za>


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

Looks like the upgrade fixed this one :)

----------
status: unread -> resolved

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

From metatracker at psf.upfronthosting.co.za  Wed Mar 18 15:05:24 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 18 Mar 2009 14:05:24 +0000
Subject: [Tracker-discuss] [issue251] Allow searching,
	displaying message and nosy counts
In-Reply-To: <1237385124.95.0.505475087652.issue251@psf.upfronthosting.co.za>
Message-ID: <1237385124.95.0.505475087652.issue251@psf.upfronthosting.co.za>


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

This patch adds searching UI for message and nosy counts. This allows
displaying, sorting and/or grouping by them. It also adds the counts to issue
item view.

If http://issues.roundup-tracker.org/issue1182919 is accepted, we'll have a
simple way of searching these properties based on intervals.

----------
files: count_ui.diff
messages: 1246
nosy: ajaksu2
priority: feature
status: unread
title: Allow searching, displaying message and nosy counts

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

From metatracker at psf.upfronthosting.co.za  Wed Mar 18 16:25:36 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Wed, 18 Mar 2009 15:25:36 +0000
Subject: [Tracker-discuss] [issue224] "Search in All Issues" button
In-Reply-To: <1223897016.78.0.0580124380517.issue224@psf.upfronthosting.co.za>
Message-ID: <1237389936.93.0.719487133137.issue224@psf.upfronthosting.co.za>


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

This patch displays the same 'search in open issues' interface for anonymous
users and a 'search open/all' one for logged in users.

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 02:22:53 2009
From: metatracker at psf.upfronthosting.co.za (Joshua Kugler)
Date: Fri, 20 Mar 2009 01:22:53 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>


New submission from Joshua Kugler <joshua at joshuakugler.com>:

I tried to edit my e-mail address in the python bug tracker 
(under "Your Details"), but when I hit submit, it tells me:

You do not have permission to edit user

----------
messages: 1248
nosy: jkugler
priority: bug
status: unread
title: Python bug tracker won't let you edit your profile

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 02:44:24 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Fri, 20 Mar 2009 01:44:24 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
Message-ID: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>


New submission from Brett C. <brett at python.org>:

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

----------
messages: 1249
nosy: brett.cannon
priority: bug
status: unread
title: Remove outdated keywords

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 02:46:19 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 20 Mar 2009 01:46:19 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237513579.94.0.511017598654.issue252@psf.upfronthosting.co.za>


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

Joshua,
I can't reproduce it on bugs.python.org nor in my local instance. Could you
please log out, clean bugs.python.org cookies and try again?

BTW, does it work in this tracker?

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Fri Mar 20 06:46:41 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, 20 Mar 2009 05:46:41 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237528000.83.0.18392527269.issue252@psf.upfronthosting.co.za>


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

Daniel, could this be because you have the Developer role? I have the same
problem on the roundup tracker.

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Fri Mar 20 06:52: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: Fri, 20 Mar 2009 05:52:26 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
Message-ID: <1237528346.39.0.0774256363589.issue253@psf.upfronthosting.co.za>


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

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

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

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

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 15:19:17 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 20 Mar 2009 14:19:17 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237558757.79.0.0378197601999.issue252@psf.upfronthosting.co.za>


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

Martin, I don't have this problem on the roundup tracker either, tried many
combinations of organization, phone, timezone, but I can't trigger this bug.

However, I notice roundup.cgi.actions.EditCommon.editItemPermission used to have
this check:
        if self.classname == 'user':
            [...]
            if self.isEditingSelf():
                return 1

And now it checks for Edit permission on each property. Hmm, maybe we have a
detector changing some non-obvious property?

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 15:39:46 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 20 Mar 2009 14:39:46 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237559986.37.0.639381522669.issue252@psf.upfronthosting.co.za>


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

Oops, it seems I didn't test organisation properly :)

Changing the email auto-adds an organi*s*ation, but schema.py allows User to
Edit organi*z*ation instead :)

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 18:13:09 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Fri, 20 Mar 2009 17:13:09 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237528346.39.0.0774256363589.issue253@psf.upfronthosting.co.za>
Message-ID: <bbaeab100903201012k55593884pc7ec00e40c4e067@mail.gmail.com>


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

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

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

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

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

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

-Brett

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

From skip at pobox.com  Fri Mar 20 19:13:41 2009
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 20 Mar 2009 13:13:41 -0500
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237528346.39.0.0774256363589.issue253@psf.upfronthosting.co.za>
References: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
	<1237528346.39.0.0774256363589.issue253@psf.upfronthosting.co.za>
Message-ID: <18883.56533.531886.58768@montanaro.dyndns.org>


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

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

Skip

From metatracker at psf.upfronthosting.co.za  Fri Mar 20 19:13:57 2009
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Fri, 20 Mar 2009 18:13:57 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237528346.39.0.0774256363589.issue253@psf.upfronthosting.co.za>
Message-ID: <18883.56533.531886.58768@montanaro.dyndns.org>


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

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

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

Skip

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

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

From ajaksu at gmail.com  Fri Mar 20 22:18:51 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 20 Mar 2009 18:18:51 -0300
Subject: [Tracker-discuss] Tracker clean up starting again :)
Message-ID: <2d75d7660903201418i390618a6lea9c6ffd8c4ddc21@mail.gmail.com>

Hi,
This is just to let you know I'm back to triaging/updating issues
during this weekend, starting now :)

Attached are a couple of helper files I've been using:
getids.txt  contains javascript to create a bookmarklet that, when
clicked on a issue list page, creates a textarea containing the IDs of
displayed issues  (tested in FF and Opera).

tool.html has a simple form that accepts IDs and displays a
bugs.python.org page containing the correspondent issues.

bugs.html puts bugs.python.org and tool.html in a frameset, for those
who'd like to play with the form :)

Regards,
Daniel
-------------- next part --------------
(function(){

// div containing the main table, so we can grab...
var content_div = document.body.childNodes[11].childNodes[1].childNodes[1];

// the issue list, would look better if we had an id for it :)
var table = content_div.childNodes[3];

var issues = table.rows;
var ids = [];
var j = 0;
for (var i = 1; i < issues.length - 1; i = i + 1) {
    //avoid grouping rows: they have a single cell
    if (issues[i].cells.length > 1) {
        ids[j] = issues[i].cells[0].textContent;
        j = j + 1;
    }
}
var ids_as_string = ids.join(', ');


var issue_ids_form = document.createElement("form");
var issue_ids = document.createElement("textarea");
issue_ids.setAttribute("cols", "40");
issue_ids.setAttribute("rows", "10");
issue_ids.setAttribute("name", "issue_ids");
issue_ids.value = ids_as_string;

issue_ids_form.appendChild(issue_ids);

content_div.appendChild(issue_ids_form);
})()
/*
//minified
(function(){var c_div=document.body.childNodes[11].childNodes[1].childNodes[1];var tb=c_div.childNodes[3];var iss=tb.rows;var ids=[];var j=0;for(var i=1;i<iss.length-1;i=i+1){if(iss[i].cells.length>1){ids[j]=iss[i].cells[0].textContent;j=j+1;}}
var ids_s=ids.join(', ');var iss_f=document.createElement("form");var is_i=document.createElement("textarea");is_i.setAttribute("cols","40");is_i.value=ids_s;iss_f.appendChild(is_i);c_div.appendChild(iss_f);})()
*/

/*
//minified and urlencoded
javascript:(function(){var%20c_div=document.body.childNodes[11].childNodes[1].childNodes[1];var%20tb=c_div.childNodes[3];var%20iss=tb.rows;var%20ids=[];var%20j=0;for(var%20i=1;i<iss.length-1;i=i+1){if(iss[i].cells.length>1){ids[j]=iss[i].cells[0].textContent;j=j+1;}}%20var%20ids_s=ids.join(',%20');var%20iss_f=document.createElement("form");var%20is_i=document.createElement("textarea");is_i.setAttribute("cols","40");is_i.value=ids_s;iss_f.appendChild(is_i);c_div.appendChild(iss_f);})()
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090320/b696550b/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090320/b696550b/attachment-0003.html>

From brett at python.org  Fri Mar 20 22:29:31 2009
From: brett at python.org (Brett Cannon)
Date: Fri, 20 Mar 2009 14:29:31 -0700
Subject: [Tracker-discuss] Tracker clean up starting again :)
In-Reply-To: <2d75d7660903201418i390618a6lea9c6ffd8c4ddc21@mail.gmail.com>
References: <2d75d7660903201418i390618a6lea9c6ffd8c4ddc21@mail.gmail.com>
Message-ID: <bbaeab100903201429k14136281kd3b7750f251b9f2e@mail.gmail.com>

If these scripts continue to help you, Daniel, and you personally use FF
then you might want to consider releasing them as Greasemonkey scripts.

2009/3/20 Daniel (ajax) Diniz <ajaksu at gmail.com>

> Hi,
> This is just to let you know I'm back to triaging/updating issues
> during this weekend, starting now :)
>
> Attached are a couple of helper files I've been using:
> getids.txt  contains javascript to create a bookmarklet that, when
> clicked on a issue list page, creates a textarea containing the IDs of
> displayed issues  (tested in FF and Opera).
>
> tool.html has a simple form that accepts IDs and displays a
> bugs.python.org page containing the correspondent issues.
>
> bugs.html puts bugs.python.org and tool.html in a frameset, for those
> who'd like to play with the form :)
>
> Regards,
> Daniel
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090320/defd829a/attachment.htm>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 00:41:28 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, 20 Mar 2009 23:41:28 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <bbaeab100903201012k55593884pc7ec00e40c4e067@mail.gmail.com>
Message-ID: <49C429A4.6070104@v.loewis.de>


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

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

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

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

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 00:42:11 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, 20 Mar 2009 23:42:11 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <18883.56533.531886.58768@montanaro.dyndns.org>
Message-ID: <49C429D1.4070001@v.loewis.de>


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

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

That could be done. Should it?

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

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 00:44:09 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Fri, 20 Mar 2009 23:44:09 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <49C429A4.6070104@v.loewis.de>
Message-ID: <bbaeab100903201643s18ea0cdv4ed2a3e61ada935a@mail.gmail.com>


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

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

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

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

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

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

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

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 00:45:50 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Fri, 20 Mar 2009 23:45:50 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <49C429D1.4070001@v.loewis.de>
Message-ID: <bbaeab100903201645v49da5e93s8c12fb75acdbcdaf@mail.gmail.com>


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

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

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

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 00:57: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: Fri, 20 Mar 2009 23:57:59 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <bbaeab100903201645v49da5e93s8c12fb75acdbcdaf@mail.gmail.com>
Message-ID: <49C42D84.8060101@v.loewis.de>


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

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

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

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

From ajaksu at gmail.com  Sat Mar 21 01:14:23 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Fri, 20 Mar 2009 21:14:23 -0300
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
References: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
	<1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
Message-ID: <2d75d7660903201714w505118a0o3de8117001d50128@mail.gmail.com>

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

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

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 01:14:25 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 21 Mar 2009 00:14:25 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za>
Message-ID: <2d75d7660903201714w505118a0o3de8117001d50128@mail.gmail.com>


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

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

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

----------
nosy: +ajaksu2

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

From brett at python.org  Sat Mar 21 01:19:27 2009
From: brett at python.org (Brett Cannon)
Date: Fri, 20 Mar 2009 17:19:27 -0700
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <2d75d7660903201714w505118a0o3de8117001d50128@mail.gmail.com>
References: <1237513464.32.0.072891570662.issue253@psf.upfronthosting.co.za> 
	<2d75d7660903201714w505118a0o3de8117001d50128@mail.gmail.com>
Message-ID: <bbaeab100903201719w16fb6844m30f8d5389787bb21@mail.gmail.com>

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

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


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

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090320/446c6015/attachment.htm>

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 01:19:45 2009
From: metatracker at psf.upfronthosting.co.za (Brett C.)
Date: Sat, 21 Mar 2009 00:19:45 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <2d75d7660903201714w505118a0o3de8117001d50128@mail.gmail.com>
Message-ID: <bbaeab100903201719w16fb6844m30f8d5389787bb21@mail.gmail.com>


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

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

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

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

-Brett

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 01:38:47 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, 21 Mar 2009 00:38:47 +0000
Subject: [Tracker-discuss] [issue253] Remove outdated keywords
In-Reply-To: <bbaeab100903201719w16fb6844m30f8d5389787bb21@mail.gmail.com>
Message-ID: <49C43715.5010109@v.loewis.de>


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

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

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 20:23:50 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, 21 Mar 2009 19:23:50 +0000
Subject: [Tracker-discuss] [issue252] Python bug tracker won't let you edit
	your profile
In-Reply-To: <1237512173.15.0.837570975554.issue252@psf.upfronthosting.co.za>
Message-ID: <1237663430.41.0.300481065841.issue252@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r70512 and r70513

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 20:25: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, 21 Mar 2009 19:25:26 +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: <1237663526.01.0.187844582455.issue244@psf.upfronthosting.co.za>


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

Is this still an issue after the roundup update?

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 20:31: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: Sat, 21 Mar 2009 19:31:56 +0000
Subject: [Tracker-discuss] [issue224] "Search in All Issues" button
In-Reply-To: <1223897016.78.0.0580124380517.issue224@psf.upfronthosting.co.za>
Message-ID: <1237663916.2.0.710406509778.issue224@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r70514

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 20:36:19 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, 21 Mar 2009 19:36:19 +0000
Subject: [Tracker-discuss] [issue251] Allow searching,
	displaying message and nosy counts
In-Reply-To: <1237385124.95.0.505475087652.issue251@psf.upfronthosting.co.za>
Message-ID: <1237664179.98.0.700484849758.issue251@psf.upfronthosting.co.za>


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

Thanks for the patch. Committed as r70515

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

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 20:42:48 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, 21 Mar 2009 19:42:48 +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: <1237664568.58.0.295611786562.issue249@psf.upfronthosting.co.za>


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

Isn't this incomplete? Won't it continue to include the change to the counters
in the change notes?

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

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 21:39:34 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 21 Mar 2009 20:39:34 +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: <1237667974.77.0.382414778178.issue249@psf.upfronthosting.co.za>


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

Argh, I broke creation of new issues. This should fix it, I'll test the change
notes now.

_______________________________________________________
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: nosy_count_new.diff
Type: text/x-diff
Size: 457 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090321/3c37ceef/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 21:49:28 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 21 Mar 2009 20:49:28 +0000
Subject: [Tracker-discuss] [issue251] Allow searching,
	displaying message and nosy counts
In-Reply-To: <1237385124.95.0.505475087652.issue251@psf.upfronthosting.co.za>
Message-ID: <1237668568.83.0.39400644721.issue251@psf.upfronthosting.co.za>


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

This is the right bug... nosy_count breaks creation of new issues, patch attached.

----------
priority: feature -> bug
status: resolved -> chatting

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

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 22:24: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: Sat, 21 Mar 2009 21:24:23 +0000
Subject: [Tracker-discuss] [issue251] Allow searching,
	displaying message and nosy counts
In-Reply-To: <1237385124.95.0.505475087652.issue251@psf.upfronthosting.co.za>
Message-ID: <1237670663.38.0.619658201464.issue251@psf.upfronthosting.co.za>


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

Thanks, committed as r70516

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

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 22:35:53 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 21 Mar 2009 21:35:53 +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: <1237671353.06.0.578555579962.issue249@psf.upfronthosting.co.za>


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

Yes, change notes in ok_message still appeared. This new patch fixes it but
starts to fell hackish, any suggestion welcome :)

_______________________________________________________
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_roundup2.diff
Type: text/x-diff
Size: 3619 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090321/b5406368/attachment.diff>

From metatracker at psf.upfronthosting.co.za  Sat Mar 21 22:36:54 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Sat, 21 Mar 2009 21:36:54 +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: <1237671414.84.0.924633111956.issue249@psf.upfronthosting.co.za>


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

And a updated python-dev version, no changes beyond diffing from new SVN version.

_______________________________________________________
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_instance2.diff
Type: text/x-diff
Size: 3803 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090321/99bdd47e/attachment.diff>

From =?utf-8?q?=22Martin_v=2E_L=C3=B6wis=22_=3Cmetatracker=40psf=2Eupfronthost?= at psf.upfronthosting.co.za  Sat Mar 21 23:03:38 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, 21 Mar 2009 22:03:38 +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: <1237673018.12.0.261133800727.issue249@psf.upfronthosting.co.za>


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

My proposal would be to introduce "silent" properties (i.e. a .silent attribute,
or perhaps .quiet). Those will not appear in journals, and not in change notes.
The attribute should be present on all properties (so hasattr won't be needed),
and default to false.

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

From bcannon at gmail.com  Mon Mar 23 02:05:22 2009
From: bcannon at gmail.com (bcannon at gmail.com)
Date: Mon, 23 Mar 2009 01:05:22 +0000
Subject: [Tracker-discuss] bugs.python.org schema redesign
Message-ID: <0016e64b9d0862f5420465bedc70@google.com>

I've shared a document with you called "bugs.python.org schema redesign":  
http://docs.google.com/Doc?id=dg7fctr4_10dbzzxzc4&invite=gpg8cmh It's not  
an attachment -- it's stored online at Google Docs. To open this document,  
just click the link above. --- After writing up the Issue Workflow doc and  
listening to what Daniel and Tennessee seem to be after, I wrote up this  
Google Doc to cover what, in my mind, seems like a good way to go for the  
issue tracker. I also tried to explain how the major use-cases of the  
tracker are covered by the schema. I have no clue how doable anything I am  
suggesting is. Feel free to reply here to this email or leave comments  
(using Insert -> Comment) in the doc. Don't significantly change the doc  
without discussing it here first in case this turns out not be a crazy idea  
and this doc becomes a reference.
Schema Redesign

Inspired by Django's issues and triage procedure along with our issues and  
how we do things now.

Bold = New
Bold-Italic = Changed
Bold-Italic-Strikeout = Removed

Type {drop-down} [anyone] "So people know whether it is a crasher vs. a  
feature request."
Components {drop-down} [anyone] "To be able to search for issues based on  
knowledge, e.g. pure Python vs. interpreter core."
2to3
Build
ctypes
Demos and Tools
Distutils
Documentation
Extension Modules
IDLE
Interpreter Core
Library (Lib)
Macintosh
Regular Expressions
Tests
Tkinter
Unicode
Windows
XML
Versions {multi-select} [anyone] "What versions are affected."
Status {drop-down} [Developer] "To know whether the issue is finished or  
not."
-no selection -
Open
Feedback Pending
Closed
Stage {drop-down} [Developer] "To get the attention of committers."
- no selection -
test needed
needs patch
Patch Review
Committer Review
Needs backporting
Committed/rejected
Dependencies {text} [anyone] "To know if other issues are holding this one  
up."
Superseder {text} [anyone] "To tie into another issue which already has  
more of a discussion of the same problem."
Assigned To {drop-down} [Developer] "Who should be dealing with this right  
now."
Nosy List {text} [anyone] "Who is keeping an eye or should be notified."
Priority {drop-down} [Developer] "How important is this?"
Keywords {multi-select} [anyone] "Fluid settings that anyone should be  
allowed to set."
26backport
64bit
Easy
Decision Needed (from "needs review")
patch
Needs unit test {checkbox} [Developer] "For when a unit test needs to be  
written."
Needs docs {checkbox} [Developer] "For when a doc changes are needed in the  
patch."
Patch needs work {checkbox} [Developer] "For when there is a patch but it  
is not finished."


Use Cases

A public issue tracker for an open source project needs to fill several  
needs. One is to let the public report bugs or submit changes that they  
come up with on their own and get feedback on their work. It also needs to  
provide a way for people to get involved easily regardless of their skill  
level or expertise. For those that help triage they need a way to quickly  
find out what issues have not been categorized yet. The core developers of  
the project also need to be able to easily take in submitted patches and  
bug fixes quickly and easily. And all of this needs to somehow be reflected  
in an issue tracker along with what work is left at any one time for an  
issue. It's a lot to try to accomplish.


Submitted Bug/Patch

For reported bugs, they need to eventually turn into patches if they happen  
to be valid bugs. Since the verification is usually very quick this does  
not need to be explicitly covered by the schema. Plus it should be fairly  
obvious upfront whether an issue still has yet to be verified a bug.

For people who submit new code, the proposed checkboxes make it clear what  
is lacking from a patch in terms of core parts (test, solution, and docs).  
It also lets them know that there is something to be addressed (previously  
mentioned boxes plus "patch needs work"). Plus they can know when they are  
the hold-up (status set to "feedback pending"). And the person knows that  
the issue has been triaged once the status switched off of "- no selection  
-" to something else.

Looking to Contribute

For those looking to contribute in a generic fashion, there are multiple  
ways to query for open issues. First off, they can look at the type to  
decide if they only want to deal with problems in the documentation or go  
all the way up to a crasher. They can also look at the component it affects  
to figure out if they want to work on just Python code or dive into C (Lib  
vs. extension modules vs. interpreter core). If they want to work on just  
tests, they can look at issues that have the "needs unit test" checkbox  
selected. Same applies to other checkboxes. And they also have the "easy"  
keyword.

Triaging

If the status of an issue is "- no selection -" then it needs to be triaged  
before it is considered an "open" issue.

Core Developers

For core developers there is what stage an issue is at. If something  
requires the attention of a core developer then it will have the  
keyword "Decision Needed" set by someone in order to get the attention of  
the developers. That way anyone can try to mark an issue as needing  
attention without having Developer privileges on the issue tracker.

If an issue has one of the two review stages set then they know that  
someone with Developer privileges has flagged a patch as ready to be  
reviewed for checkin. And if something gets committed and needs a backport  
that just can't be done that instant, that can be flagged as well. And with  
the "patch" keyword is there if a developer wants to help find issues that  
have code to look at but might not be ready to be checked in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090323/f624ed4b/attachment.htm>

From rdmurray at bitdance.com  Tue Mar 24 03:01:30 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 23 Mar 2009 22:01:30 -0400 (EDT)
Subject: [Tracker-discuss] pending autoclose?
Message-ID: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>

I seem to remember a mention of pending issues getting autoclosed.
Was that a wish-list item or is it implemented?

--
R. David Murray           http://www.bitdance.com


From rdmurray at bitdance.com  Tue Mar 24 03:21:19 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 23 Mar 2009 22:21:19 -0400 (EDT)
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper setting of 'versions'
Message-ID: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>

The workflow document explains the stages, but doesn't cover types.
I think it would be useful if there were some definitions and examples.

This came up because I reviewed issue 2259.  The submitter set it to
'crash', which I would imagine actually refers to the interpreter
crashing.  So I changed it to 'behavior', which I imagine means "things
are behaving according to the docs" (ie: this is a bug).

But am I correct?  And even if I am, this should be documented.

Should I take a stab at it, or does someone better qualified prefer to
do it? :)

Also, what "should" be selected in the versions field?  All versions in
which the bug appears?  Only versions in which the bug might get
fixed?  The version in which it was reported plus any later versions
in which it is still broken?

--
R. David Murray           http://www.bitdance.com

From ajaksu at gmail.com  Tue Mar 24 03:33:09 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 23 Mar 2009 23:33:09 -0300
Subject: [Tracker-discuss] pending autoclose?
In-Reply-To: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>
Message-ID: <2d75d7660903231933q28fefb31pb6774f8a8465c24e@mail.gmail.com>

R. David Murray wrote:
> I seem to remember a mention of pending issues getting autoclosed.
> Was that a wish-list item or is it implemented?

Wish-list item, on my to-do list and easy to implement AFAIK.

The key reason I haven't worked on it yet is that it would require
some effort to see if it wouldn't mess with issues currently set as
pending (and lack of time).

That and the fact that sometimes small, simple features often carry a
unexpected hidden workload, specially when I break things :)

If you'd like to have it soon, I might be able to provide a patch
before Wednesday. Otherwise, I'll let it rest for a week or two.

Regards,
Daniel

From ajaksu at gmail.com  Tue Mar 24 03:42:13 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 23 Mar 2009 23:42:13 -0300
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>
Message-ID: <2d75d7660903231942k5c4b1047sae3a13c25b24b1fb@mail.gmail.com>

OR. David Murray wrote:
> The workflow document explains the stages, but doesn't cover types.
> I think it would be useful if there were some definitions and examples.

Agreed, and we can add tooltips to the UI later on.

> This came up because I reviewed issue 2259. ?The submitter set it to
> 'crash', which I would imagine actually refers to the interpreter
> crashing. ?So I changed it to 'behavior', which I imagine means "things
> are behaving according to the docs" (ie: this is a bug).

"things are not behaving...", I guess. That's exactly the way I
understand 'behavior'.

> But am I correct? ?And even if I am, this should be documented.

Not sure whether you're correct, but if you're wrong I can tell you
I've made the same mistake in 98% of the issues I've updated so far.
So I hope you're right :)

> Should I take a stab at it, or does someone better qualified prefer to
> do it? :)

Unless Brett or Tennessee have this already written, I say go on, please!

> Also, what "should" be selected in the versions field? ?All versions in
> which the bug appears? ?Only versions in which the bug might get
> fixed? ?The version in which it was reported plus any later versions
> in which it is still broken?

I'm using the 'versions the bug might get fixed' target (RFEs set to
next major release, bugs and doc RFEs for minor releases), but have
the same doubts. Thanks a lot for bringing this up!

Cheers,
Daniel

From martin at v.loewis.de  Tue Mar 24 07:08:44 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 24 Mar 2009 07:08:44 +0100
Subject: [Tracker-discuss] pending autoclose?
In-Reply-To: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>
Message-ID: <49C878EC.4010102@v.loewis.de>

R. David Murray wrote:
> I seem to remember a mention of pending issues getting autoclosed.
> Was that a wish-list item or is it implemented?

It's still a wish-list item.

Regards,
Martin

From rdmurray at bitdance.com  Tue Mar 24 08:50:28 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 03:50:28 -0400 (EDT)
Subject: [Tracker-discuss] pending autoclose?
In-Reply-To: <2d75d7660903231933q28fefb31pb6774f8a8465c24e@mail.gmail.com>
References: <Pine.LNX.4.64.0903232200320.31981@kimball.webabinitio.net>
	<2d75d7660903231933q28fefb31pb6774f8a8465c24e@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0903240348500.31981@kimball.webabinitio.net>

On Mon, 23 Mar 2009 at 23:33, Daniel (ajax) Diniz wrote:
> R. David Murray wrote:
>> I seem to remember a mention of pending issues getting autoclosed.
>> Was that a wish-list item or is it implemented?
>
> Wish-list item, on my to-do list and easy to implement AFAIK.
>
> The key reason I haven't worked on it yet is that it would require
> some effort to see if it wouldn't mess with issues currently set as
> pending (and lack of time).
>
> That and the fact that sometimes small, simple features often carry a
> unexpected hidden workload, specially when I break things :)
>
> If you'd like to have it soon, I might be able to provide a patch
> before Wednesday. Otherwise, I'll let it rest for a week or two.

Nah, no rush, I just wanted to know if it was in place or not so I know
what behavior to expect when I set something to pending.

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Tue Mar 24 11:47:05 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 06:47:05 -0400 (EDT)
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <0016e64b9d0862f5420465bedc70@google.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
Message-ID: <Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>

On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
> Submitted Bug/Patch
>
> For reported bugs, they need to eventually turn into patches if they happen 
> to be valid bugs. Since the verification is usually very quick this does not 
> need to be explicitly covered by the schema. Plus it should be fairly obvious 
> upfront whether an issue still has yet to be verified a bug.
>
> For people who submit new code, the proposed checkboxes make it clear what is 
> lacking from a patch in terms of core parts (test, solution, and docs). It 
> also lets them know that there is something to be addressed (previously 
> mentioned boxes plus "patch needs work"). Plus they can know when they are 
> the hold-up (status set to "feedback pending"). And the person knows that the 
> issue has been triaged once the status switched off of "- no selection -" to 
> something else.

"Feedback pending" reminds me of the "customer pending" status in our
trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
Whose feedback is pending?  I think you want it to be the submitter, in
which case it should say that, I think.

I think there is some value in the 'stages' workflow: that tests come
first, then the patch, then the review.  So I'm not sure I like the idea
of converting those to checkboxes.

> Looking to Contribute
>
> For those looking to contribute in a generic fashion, there are multiple ways 
> to query for open issues. First off, they can look at the type to decide if 
> they only want to deal with problems in the documentation or go all the way 
> up to a crasher. They can also look at the component it affects to figure out 
> if they want to work on just Python code or dive into C (Lib vs. extension 
> modules vs. interpreter core). If they want to work on just tests, they can 
> look at issues that have the "needs unit test" checkbox selected. Same 
> applies to other checkboxes. And they also have the "easy" keyword.

I'm not sure why you suggest removing so many of the components,
especially '2to3'.  'Macintosh' and 'Windows' should go, I think, or be
moved into an optional 'platform' dropdown and renamed appropriately.
But the others seem useful, and in fact I'd like to generalize the list
into a way to identify any particular library module.  Perhaps that's
a separate dropdown?

> Triaging
>
> If the status of an issue is "- no selection -" then it needs to be triaged 
> before it is considered an "open" issue.
>
> Core Developers
>
> For core developers there is what stage an issue is at. If something requires 
> the attention of a core developer then it will have the keyword "Decision 
> Needed" set by someone in order to get the attention of the developers. That 
> way anyone can try to mark an issue as needing attention without having 
> Developer privileges on the issue tracker.

I like this idea, though if we had enough triage people it would be
better to have the flag alert triage, and triage alert the core
developers if they agree.

> If an issue has one of the two review stages set then they know that someone 
> with Developer privileges has flagged a patch as ready to be reviewed for 
> checkin. And if something gets committed and needs a backport that just can't 
> be done that instant, that can be flagged as well. And with the "patch" 
> keyword is there if a developer wants to help find issues that have code to 
> look at but might not be ready to be checked in.

I may have other thoughts as well later, but these are what occurred to
me today.

--
R. David Murray           http://www.bitdance.com

From martin at v.loewis.de  Tue Mar 24 20:45:18 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 24 Mar 2009 20:45:18 +0100
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
Message-ID: <49C9384E.6090407@v.loewis.de>

> "Feedback pending" reminds me of the "customer pending" status in our
> trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
> Whose feedback is pending?  I think you want it to be the submitter, in
> which case it should say that, I think.

Any kind of followup should close the issue.

It's actually not that feedback is pending (in my understanding of
the word "pending", i.e. "present, but not considered yet").
Instead, what is pending is that the issue will be closed (is
it then that "closure" is pending?)

> I'm not sure why you suggest removing so many of the components,
> especially '2to3'.  'Macintosh' and 'Windows' should go, I think

Why do you think so? The question really is "who should look at this",
and, in case of these two components, the answer is "a Mac expert"
or "a Windows expert" (just like for any other component).

> But the others seem useful, and in fact I'd like to generalize the list
> into a way to identify any particular library module.  Perhaps that's
> a separate dropdown?

I would think that this is only useful for modules that have actually
many bugs reported against them.

Regards,
Martin

From stephen at xemacs.org  Tue Mar 24 21:29:24 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 25 Mar 2009 05:29:24 +0900
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <49C9384E.6090407@v.loewis.de>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<49C9384E.6090407@v.loewis.de>
Message-ID: <87vdpyfyvv.fsf@xemacs.org>

"Martin v. L?wis" writes:

 > > But the others seem useful, and in fact I'd like to generalize the list
 > > into a way to identify any particular library module.  Perhaps that's
 > > a separate dropdown?
 > 
 > I would think that this is only useful for modules that have actually
 > many bugs reported against them.

But users will like the feature because (to the extent that they've
*correctly* identified the problem module) there will be few bugs they
need to check for duplication.

Also, for modules that have specific maintainers, it will be a good
way to list all the issues of interest, and it could be used to
automatically assign bugs or add people to the nosy list, etc.

From rdmurray at bitdance.com  Tue Mar 24 21:37:17 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 16:37:17 -0400 (EDT)
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <49C9384E.6090407@v.loewis.de>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<49C9384E.6090407@v.loewis.de>
Message-ID: <Pine.LNX.4.64.0903241620220.31981@kimball.webabinitio.net>

On Tue, 24 Mar 2009 at 20:45, "Martin v. L?wis" wrote:
>> "Feedback pending" reminds me of the "customer pending" status in our
>> trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
>> Whose feedback is pending?  I think you want it to be the submitter, in
>> which case it should say that, I think.
>
> Any kind of followup should close the issue.

Except for followup that says don't close this issue, I presume?

> It's actually not that feedback is pending (in my understanding of
> the word "pending", i.e. "present, but not considered yet").
> Instead, what is pending is that the issue will be closed (is
> it then that "closure" is pending?)

But I think Brett is proposing something different from the current
"close pending".  I could be wrong, though.

>> I'm not sure why you suggest removing so many of the components,
>> especially '2to3'.  'Macintosh' and 'Windows' should go, I think
>
> Why do you think so? The question really is "who should look at this",
> and, in case of these two components, the answer is "a Mac expert"
> or "a Windows expert" (just like for any other component).

Because a problem could be a problem with, say, a particular
library module, but only shows up on the Mac (or the submitter has
only seen it on a Mac).

But I'm actually of two minds about that, since when I've dealt with
these two things being separate on other trackers, I've often thought
that filling in the platform was irrelevant since I was sure the bug
had nothing to do with the platform.

So I'm actually happy leaving Windows and Mac in there (Brett's
proposal was to delete them entirely).  (And should it be changed to
'OS/X' now?)

>> But the others seem useful, and in fact I'd like to generalize the list
>> into a way to identify any particular library module.  Perhaps that's
>> a separate dropdown?
>
> I would think that this is only useful for modules that have actually
> many bugs reported against them.

Well, the motivation for it would be so that someone who was maintainer
of a specific module or set of modules could easily find bugs against
just those, instead of having to fish through all bugs marked "Library".
But I suppose we could have triage assign them, instead, if we continue
to have enough active triage people.

Speaking of which, is there somewhere where the list Daniel gathered
of people who wanted certain classes of bugs assigned to them is
posted?  I should probably have that in hand while doing triage.

--
R. David Murray           http://www.bitdance.com

From martin at v.loewis.de  Tue Mar 24 21:48:41 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 24 Mar 2009 21:48:41 +0100
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903241620220.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<49C9384E.6090407@v.loewis.de>
	<Pine.LNX.4.64.0903241620220.31981@kimball.webabinitio.net>
Message-ID: <49C94729.9060108@v.loewis.de>

R. David Murray wrote:
> On Tue, 24 Mar 2009 at 20:45, "Martin v. L?wis" wrote:
>>> "Feedback pending" reminds me of the "customer pending" status in our
>>> trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
>>> Whose feedback is pending?  I think you want it to be the submitter, in
>>> which case it should say that, I think.
>>
>> Any kind of followup should close the issue.
> 
> Except for followup that says don't close this issue, I presume?

Oops: Any kind of followup should *reopen* the issue (i.e. not close it)

Pending should be used with "I believe you are mistaken, and here is
why. No need to reply", or with "It's been a long time. If you are still
around, please confirm that the issue still exists".

Once we have autoclose, after 14 days, there will be a second message,
"this is now autoclosed", reminding the submitter that he didn't
respond. If then nobody still responds, there is agreement that the
issue deserves to be closed.

>> Why do you think so? The question really is "who should look at this",
>> and, in case of these two components, the answer is "a Mac expert"
>> or "a Windows expert" (just like for any other component).
> 
> Because a problem could be a problem with, say, a particular
> library module, but only shows up on the Mac (or the submitter has
> only seen it on a Mac).

The mac expert (or anybody performing triage) should then reclassify.

The same can happen to any other issue. It crashes in in httplib,
but the actual bug is somewhere down in the reference counting of
Unicode strings. Things get misclassified - no problem.

> Well, the motivation for it would be so that someone who was maintainer
> of a specific module or set of modules could easily find bugs against
> just those, instead of having to fish through all bugs marked "Library".
> But I suppose we could have triage assign them, instead, if we continue
> to have enough active triage people.

Maintainers wishing new component categories for their issues will
get them right away. Likewise, if you tell me that you found 20 issues
for xyz, I can create a component in no time.

> Speaking of which, is there somewhere where the list Daniel gathered
> of people who wanted certain classes of bugs assigned to them is
> posted?  I should probably have that in hand while doing triage.

Not sure - Daniel should certainly have it.

Regards,
Martin

From bcannon at gmail.com  Tue Mar 24 21:49:55 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 24 Mar 2009 13:49:55 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903241620220.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<49C9384E.6090407@v.loewis.de>
	<Pine.LNX.4.64.0903241620220.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241349i22182a56w7eef5dcf1acb0db3@mail.gmail.com>

On Tue, Mar 24, 2009 at 13:37, R. David Murray <rdmurray at bitdance.com>wrote:

> On Tue, 24 Mar 2009 at 20:45, "Martin v. L?wis" wrote:
>
>> "Feedback pending" reminds me of the "customer pending" status in our
>>> trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
>>> Whose feedback is pending?  I think you want it to be the submitter, in
>>> which case it should say that, I think.
>>>
>>
>> Any kind of followup should close the issue.
>>
>
> Except for followup that says don't close this issue, I presume?
>
>  It's actually not that feedback is pending (in my understanding of
>> the word "pending", i.e. "present, but not considered yet").
>> Instead, what is pending is that the issue will be closed (is
>> it then that "closure" is pending?)
>>
>
> But I think Brett is proposing something different from the current
> "close pending".  I could be wrong, though.


Nope, I'm not. I want "close pending w/o feedback", but that's too long for
the drop-down. "Close Pending" works for me.


>
>
>  I'm not sure why you suggest removing so many of the components,
>>> especially '2to3'.  'Macintosh' and 'Windows' should go, I think
>>>
>>
>> Why do you think so? The question really is "who should look at this",
>> and, in case of these two components, the answer is "a Mac expert"
>> or "a Windows expert" (just like for any other component).
>>
>
> Because a problem could be a problem with, say, a particular
> library module, but only shows up on the Mac (or the submitter has
> only seen it on a Mac).
>
> But I'm actually of two minds about that, since when I've dealt with
> these two things being separate on other trackers, I've often thought
> that filling in the platform was irrelevant since I was sure the bug
> had nothing to do with the platform.
>
> So I'm actually happy leaving Windows and Mac in there (Brett's
> proposal was to delete them entirely).  (And should it be changed to
> 'OS/X' now?)
>

Everyone knows OS X is Mac so I don't see a need other than perhaps
shortening "Macintosh" to "Mac".


>
>
>  But the others seem useful, and in fact I'd like to generalize the list
>>> into a way to identify any particular library module.  Perhaps that's
>>> a separate dropdown?
>>>
>>
>> I would think that this is only useful for modules that have actually
>> many bugs reported against them.
>>
>
> Well, the motivation for it would be so that someone who was maintainer
> of a specific module or set of modules could easily find bugs against
> just those, instead of having to fish through all bugs marked "Library".
> But I suppose we could have triage assign them, instead, if we continue
> to have enough active triage people.
>

That's what I was assuming and thus why I was suggesting trimming down the
rather long components section.


>
> Speaking of which, is there somewhere where the list Daniel gathered
> of people who wanted certain classes of bugs assigned to them is
> posted?  I should probably have that in hand while doing triage.


Nope, although it probably wouldn't hurt to have one somewhere in the wiki.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/02475007/attachment-0001.htm>

From bcannon at gmail.com  Tue Mar 24 22:01:42 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 24 Mar 2009 14:01:42 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>

On Tue, Mar 24, 2009 at 03:47, R. David Murray <rdmurray at bitdance.com>wrote:

> On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
>
>> Submitted Bug/Patch
>>
>> For reported bugs, they need to eventually turn into patches if they
>> happen to be valid bugs. Since the verification is usually very quick this
>> does not need to be explicitly covered by the schema. Plus it should be
>> fairly obvious upfront whether an issue still has yet to be verified a bug.
>>
>> For people who submit new code, the proposed checkboxes make it clear what
>> is lacking from a patch in terms of core parts (test, solution, and docs).
>> It also lets them know that there is something to be addressed (previously
>> mentioned boxes plus "patch needs work"). Plus they can know when they are
>> the hold-up (status set to "feedback pending"). And the person knows that
>> the issue has been triaged once the status switched off of "- no selection
>> -" to something else.
>>
>
> "Feedback pending" reminds me of the "customer pending" status in our
> trouble ticket issue tracker.  But 'feedback pending' is too ambiguous.
> Whose feedback is pending?  I think you want it to be the submitter, in
> which case it should say that, I think.
>
> I think there is some value in the 'stages' workflow: that tests come
> first, then the patch, then the review.  So I'm not sure I like the idea
> of converting those to checkboxes.


Well, having them be checkboxes makes it very obvious what issues still need
a test, which need help with docs, etc. It should make it easier for people
to search for issues that need just help with the docs if that is how they
want to contribute even if the patch is also missing a test because the
submitter only fixed the bug.

What do other people think? If others are happy with Stage as it is then we
could add the "Needs docs" step along with "Needs backporting" and that
should fill in the gaps along with a "Needs Decision" keyword to help grab
the attention of core developers when people are stuck and need help with
deciding how to do something (should address Tennessee's desires). If people
want to stick with the Stage idea I can rework the proposal to be more of
just a cleanup of what we currently have.


>
>
>  Looking to Contribute
>>
>> For those looking to contribute in a generic fashion, there are multiple
>> ways to query for open issues. First off, they can look at the type to
>> decide if they only want to deal with problems in the documentation or go
>> all the way up to a crasher. They can also look at the component it affects
>> to figure out if they want to work on just Python code or dive into C (Lib
>> vs. extension modules vs. interpreter core). If they want to work on just
>> tests, they can look at issues that have the "needs unit test" checkbox
>> selected. Same applies to other checkboxes. And they also have the "easy"
>> keyword.
>>
>
> I'm not sure why you suggest removing so many of the components,
> especially '2to3'.  'Macintosh' and 'Windows' should go, I think, or be
> moved into an optional 'platform' dropdown and renamed appropriately.
> But the others seem useful, and in fact I'd like to generalize the list
> into a way to identify any particular library module.  Perhaps that's
> a separate dropdown?
>

Perhaps 2to3 and IDLE as Benjamin suggests in the doc should stay, but most
of that other stuff can be found in a simple search. If I was looking for
xml bugs I would search for xml. And this does not extend to http stuff as
you point out, David (or do you prefer to be addressed as R?).

But I do not want to add the maintenance headache of listing every top-level
module and package in the stdlib. Closest I would be willing to come is have
a text field where people can try to list what they think is the affected
modules.


>
>
>  Triaging
>>
>> If the status of an issue is "- no selection -" then it needs to be
>> triaged before it is considered an "open" issue.
>>
>> Core Developers
>>
>> For core developers there is what stage an issue is at. If something
>> requires the attention of a core developer then it will have the keyword
>> "Decision Needed" set by someone in order to get the attention of the
>> developers. That way anyone can try to mark an issue as needing attention
>> without having Developer privileges on the issue tracker.
>>
>
> I like this idea, though if we had enough triage people it would be
> better to have the flag alert triage, and triage alert the core
> developers if they agree.


Like what? Another Stage such as "Requires Attention"? This almost feels
like splitting hairs here between people who do triage and the core
developers. I would want to hear what others think before diving into this
one.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/848e97d3/attachment.htm>

From rdmurray at bitdance.com  Tue Mar 24 22:53:58 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 17:53:58 -0400 (EDT)
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net>

On Tue, 24 Mar 2009 at 14:01, Brett Cannon wrote:
> On Tue, Mar 24, 2009 at 03:47, R. David Murray <rdmurray at bitdance.com>wrote:
>> On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
>>
>> I think there is some value in the 'stages' workflow: that tests come
>> first, then the patch, then the review.  So I'm not sure I like the idea
>> of converting those to checkboxes.
>
> Well, having them be checkboxes makes it very obvious what issues still need
> a test, which need help with docs, etc. It should make it easier for people
> to search for issues that need just help with the docs if that is how they
> want to contribute even if the patch is also missing a test because the
> submitter only fixed the bug.

Ah, now I see where you are coming from on that.

> What do other people think? If others are happy with Stage as it is then we
> could add the "Needs docs" step along with "Needs backporting" and that
> should fill in the gaps along with a "Needs Decision" keyword to help grab
> the attention of core developers when people are stuck and need help with
> deciding how to do something (should address Tennessee's desires). If people
> want to stick with the Stage idea I can rework the proposal to be more of
> just a cleanup of what we currently have.

Tests (as in unit test) and code are pretty much the same skillset,
as opposed to docs.  What about having 'needs docs' as a keyword
instead?

"Needs decision" as a keyword works for me.

>> I'm not sure why you suggest removing so many of the components,
>> especially '2to3'.  'Macintosh' and 'Windows' should go, I think, or be
>> moved into an optional 'platform' dropdown and renamed appropriately.
>> But the others seem useful, and in fact I'd like to generalize the list
>> into a way to identify any particular library module.  Perhaps that's
>> a separate dropdown?
>>
>
> Perhaps 2to3 and IDLE as Benjamin suggests in the doc should stay, but most
> of that other stuff can be found in a simple search. If I was looking for
> xml bugs I would search for xml. And this does not extend to http stuff as
> you point out, David (or do you prefer to be addressed as R?).
>
> But I do not want to add the maintenance headache of listing every top-level
> module and package in the stdlib. Closest I would be willing to come is have
> a text field where people can try to list what they think is the affected
> modules.

Yes, the maintenance headache is valid...unless it could be automated :)
Having an unambiguous way to 'tag' issues for those developers who
want to be able to see particular collections, which is apparently
how this has been used so far, does seem like a valid use case, though.
Text searches aren't always easy.

>>  Triaging
>>>
>>> If the status of an issue is "- no selection -" then it needs to be
>>> triaged before it is considered an "open" issue.
>>>
>>> Core Developers
>>>
>>> For core developers there is what stage an issue is at. If something
>>> requires the attention of a core developer then it will have the keyword
>>> "Decision Needed" set by someone in order to get the attention of the
>>> developers. That way anyone can try to mark an issue as needing attention
>>> without having Developer privileges on the issue tracker.
>>>
>>
>> I like this idea, though if we had enough triage people it would be
>> better to have the flag alert triage, and triage alert the core
>> developers if they agree.
>
>
> Like what? Another Stage such as "Requires Attention"? This almost feels
> like splitting hairs here between people who do triage and the core
> developers. I would want to hear what others think before diving into this
> one.

Yes, I was visualizing a team of triage people who were "lesser gods"
compared to the core developers, but in fact core developers will triage
and triage people will sometimes become developers.  And the team isn't
so big (I gather :) that the division of labor necessarily makes sense.
I was trying to keep from "bugging" the core developers unnecessarily,
but I suspect now that that is misguided.

--
R. David Murray           http://www.bitdance.com

From tleeuwenburg at gmail.com  Tue Mar 24 23:47:45 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Wed, 25 Mar 2009 09:47:45 +1100
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net>
Message-ID: <43c8685c0903241547m481dba9dpcf1d59ef10a86bd3@mail.gmail.com>

On Wed, Mar 25, 2009 at 8:53 AM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Tue, 24 Mar 2009 at 14:01, Brett Cannon wrote:
>
>> On Tue, Mar 24, 2009 at 03:47, R. David Murray <rdmurray at bitdance.com
>> >wrote:
>>
>>> On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
>>>
>>> I think there is some value in the 'stages' workflow: that tests come
>>> first, then the patch, then the review.  So I'm not sure I like the idea
>>> of converting those to checkboxes.
>>>
>>
>> Well, having them be checkboxes makes it very obvious what issues still
>> need
>> a test, which need help with docs, etc. It should make it easier for
>> people
>> to search for issues that need just help with the docs if that is how they
>> want to contribute even if the patch is also missing a test because the
>> submitter only fixed the bug.
>>
>
> Ah, now I see where you are coming from on that.
>
>  What do other people think? If others are happy with Stage as it is then
>> we
>> could add the "Needs docs" step along with "Needs backporting" and that
>> should fill in the gaps along with a "Needs Decision" keyword to help grab
>> the attention of core developers when people are stuck and need help with
>> deciding how to do something (should address Tennessee's desires). If
>> people
>> want to stick with the Stage idea I can rework the proposal to be more of
>> just a cleanup of what we currently have.
>>
>
> Tests (as in unit test) and code are pretty much the same skillset,
> as opposed to docs.  What about having 'needs docs' as a keyword
> instead?
>
> "Needs decision" as a keyword works for me.


"Needs decision" or "Needs consensus" would be great for me. It would be
nice to be able to "tick off" that stage, checkbox-style (so ticking it off
== stage completed)

I am definitely in the triage / lower-level developer position. I'm happy to
contribute time and code as I'm available to. I'm planning currently to
start doing a lot of work on strftime and strptime, as there are a lot of
quite tractable, isolated issues with those modules, which have been
outstanding for some time.

Cheers,
-T

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

From bcannon at gmail.com  Wed Mar 25 00:28:38 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 24 Mar 2009 16:28:38 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com> 
	<Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241628p67efada1v89dc03d4053461a@mail.gmail.com>

On Tue, Mar 24, 2009 at 14:53, R. David Murray <rdmurray at bitdance.com>wrote:

> On Tue, 24 Mar 2009 at 14:01, Brett Cannon wrote:
>
>> On Tue, Mar 24, 2009 at 03:47, R. David Murray <rdmurray at bitdance.com
>> >wrote:
>>
>>> On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
>>>
>>> I think there is some value in the 'stages' workflow: that tests come
>>> first, then the patch, then the review.  So I'm not sure I like the idea
>>> of converting those to checkboxes.
>>>
>>
>> Well, having them be checkboxes makes it very obvious what issues still
>> need
>> a test, which need help with docs, etc. It should make it easier for
>> people
>> to search for issues that need just help with the docs if that is how they
>> want to contribute even if the patch is also missing a test because the
>> submitter only fixed the bug.
>>
>
> Ah, now I see where you are coming from on that.
>
>  What do other people think? If others are happy with Stage as it is then
>> we
>> could add the "Needs docs" step along with "Needs backporting" and that
>> should fill in the gaps along with a "Needs Decision" keyword to help grab
>> the attention of core developers when people are stuck and need help with
>> deciding how to do something (should address Tennessee's desires). If
>> people
>> want to stick with the Stage idea I can rework the proposal to be more of
>> just a cleanup of what we currently have.
>>
>
> Tests (as in unit test) and code are pretty much the same skillset,


Well, yes and no. Yes they both taking coding, but tests tend to be
technically simpler than fixing existing code.


>
> as opposed to docs.  What about having 'needs docs' as a keyword
> instead?
>

That works as well. I basically want keywords to be something we are happy
letting anyone set and this is fine.


>
> "Needs decision" as a keyword works for me.
>
>  I'm not sure why you suggest removing so many of the components,
>>> especially '2to3'.  'Macintosh' and 'Windows' should go, I think, or be
>>> moved into an optional 'platform' dropdown and renamed appropriately.
>>> But the others seem useful, and in fact I'd like to generalize the list
>>> into a way to identify any particular library module.  Perhaps that's
>>> a separate dropdown?
>>>
>>>
>> Perhaps 2to3 and IDLE as Benjamin suggests in the doc should stay, but
>> most
>> of that other stuff can be found in a simple search. If I was looking for
>> xml bugs I would search for xml. And this does not extend to http stuff as
>> you point out, David (or do you prefer to be addressed as R?).
>>
>> But I do not want to add the maintenance headache of listing every
>> top-level
>> module and package in the stdlib. Closest I would be willing to come is
>> have
>> a text field where people can try to list what they think is the affected
>> modules.
>>
>
> Yes, the maintenance headache is valid...unless it could be automated :)
> Having an unambiguous way to 'tag' issues for those developers who
> want to be able to see particular collections, which is apparently
> how this has been used so far, does seem like a valid use case, though.
> Text searches aren't always easy.
>

The problem is that the use of Components for auto-assignment tends not to
last. Documentation is now the only component that actually auto-assigns;
everything else is a relic so that is why I was suggesting we prune the list
down. I think that adding someone to the nosy list works just as well, it's
just not automated.


>
>
>   Triaging
>>>
>>>>
>>>> If the status of an issue is "- no selection -" then it needs to be
>>>> triaged before it is considered an "open" issue.
>>>>
>>>> Core Developers
>>>>
>>>> For core developers there is what stage an issue is at. If something
>>>> requires the attention of a core developer then it will have the keyword
>>>> "Decision Needed" set by someone in order to get the attention of the
>>>> developers. That way anyone can try to mark an issue as needing
>>>> attention
>>>> without having Developer privileges on the issue tracker.
>>>>
>>>>
>>> I like this idea, though if we had enough triage people it would be
>>> better to have the flag alert triage, and triage alert the core
>>> developers if they agree.
>>>
>>
>>
>> Like what? Another Stage such as "Requires Attention"? This almost feels
>> like splitting hairs here between people who do triage and the core
>> developers. I would want to hear what others think before diving into this
>> one.
>>
>
> Yes, I was visualizing a team of triage people who were "lesser gods"
> compared to the core developers, but in fact core developers will triage
> and triage people will sometimes become developers.  And the team isn't
> so big (I gather :) that the division of labor necessarily makes sense.
> I was trying to keep from "bugging" the core developers unnecessarily,
> but I suspect now that that is misguided.


 It's not misguided as it is a nice thought, but for now I would rather only
add/remove stuff we know to be useful for now. The whole idea of a few
people handling triage is rather new. =)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/30b6fd04/attachment.htm>

From bcannon at gmail.com  Wed Mar 25 00:30:22 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 24 Mar 2009 16:30:22 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <43c8685c0903241547m481dba9dpcf1d59ef10a86bd3@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com> 
	<Pine.LNX.4.64.0903241743170.31981@kimball.webabinitio.net> 
	<43c8685c0903241547m481dba9dpcf1d59ef10a86bd3@mail.gmail.com>
Message-ID: <bbaeab100903241630k29e16ce6v9b706c684c58d815@mail.gmail.com>

On Tue, Mar 24, 2009 at 15:47, Tennessee Leeuwenburg <tleeuwenburg at gmail.com
> wrote:

>
>
> On Wed, Mar 25, 2009 at 8:53 AM, R. David Murray <rdmurray at bitdance.com>wrote:
>
>> On Tue, 24 Mar 2009 at 14:01, Brett Cannon wrote:
>>
>>> On Tue, Mar 24, 2009 at 03:47, R. David Murray <rdmurray at bitdance.com
>>> >wrote:
>>>
>>>> On Mon, 23 Mar 2009 at 01:05, bcannon at gmail.com wrote:
>>>>
>>>> I think there is some value in the 'stages' workflow: that tests come
>>>> first, then the patch, then the review.  So I'm not sure I like the idea
>>>> of converting those to checkboxes.
>>>>
>>>
>>> Well, having them be checkboxes makes it very obvious what issues still
>>> need
>>> a test, which need help with docs, etc. It should make it easier for
>>> people
>>> to search for issues that need just help with the docs if that is how
>>> they
>>> want to contribute even if the patch is also missing a test because the
>>> submitter only fixed the bug.
>>>
>>
>> Ah, now I see where you are coming from on that.
>>
>>  What do other people think? If others are happy with Stage as it is then
>>> we
>>> could add the "Needs docs" step along with "Needs backporting" and that
>>> should fill in the gaps along with a "Needs Decision" keyword to help
>>> grab
>>> the attention of core developers when people are stuck and need help with
>>> deciding how to do something (should address Tennessee's desires). If
>>> people
>>> want to stick with the Stage idea I can rework the proposal to be more of
>>> just a cleanup of what we currently have.
>>>
>>
>> Tests (as in unit test) and code are pretty much the same skillset,
>> as opposed to docs.  What about having 'needs docs' as a keyword
>> instead?
>>
>> "Needs decision" as a keyword works for me.
>
>
> "Needs decision" or "Needs consensus" would be great for me. It would be
> nice to be able to "tick off" that stage, checkbox-style (so ticking it off
> == stage completed)


OK, so a "Needs Decision" keyword sound reasonable. I will wait to hear back
from more people before I change the proposal but it sounds like just
tweaking what we have might work out better than the overhaul I was
suggesting.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/67afcce5/attachment.htm>

From brett at python.org  Wed Mar 25 00:37:19 2009
From: brett at python.org (Brett Cannon)
Date: Tue, 24 Mar 2009 16:37:19 -0700
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com>

On Mon, Mar 23, 2009 at 19:21, R. David Murray <rdmurray at bitdance.com>wrote:

> The workflow document explains the stages, but doesn't cover types.
> I think it would be useful if there were some definitions and examples.
>
> This came up because I reviewed issue 2259.  The submitter set it to
> 'crash', which I would imagine actually refers to the interpreter
> crashing.  So I changed it to 'behavior', which I imagine means "things
> are behaving according to the docs" (ie: this is a bug).
>
> But am I correct?  And even if I am, this should be documented.
>

Yep, you are correct.


>
> Should I take a stab at it, or does someone better qualified prefer to
> do it? :)
>
> Also, what "should" be selected in the versions field?  All versions in
> which the bug appears?  Only versions in which the bug might get
> fixed?  The version in which it was reported plus any later versions
> in which it is still broken?


Any version it is known to be broken in. So if it was reported in 2.5 and it
still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It lets
people who are using old versions find out what they might have to watch out
for since we are not about to fix anything for 2.5 that is not
security-related.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/d2224cd9/attachment-0001.htm>

From ajaksu at gmail.com  Wed Mar 25 01:17:42 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Tue, 24 Mar 2009 21:17:42 -0300
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com>
Message-ID: <2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>

Brett Cannon wrote:
>> Also, what "should" be selected in the versions field? ?All versions in
>> which the bug appears? ?Only versions in which the bug might get
>> fixed? ?The version in which it was reported plus any later versions
>> in which it is still broken?
>
> Any version it is known to be broken in. So if it was reported in 2.5 and it
> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It lets
> people who are using old versions find out what they might have to watch out
> for since we are not about to fix anything for 2.5 that is not
> security-related.

Oopsie, I've applied a different rule to a couple of hundred of issues :)

I'll use this rule from now on and eventually fix the wrong changes.
IIRC, my wrong interpretation is somewhat widespread, so it might be
interesting to add help/descriptions to the versions input.

Some doubts:
  For a bug filled against e.g. 2.4 that was confirmed then but not
yet in any new versions, should we add current versions to denote they
need checking?
  For bugs filled against e.g. 2.5 that were never confirmed, should
we add the current version? And should we try to verify it for the old
one?
  For bugs that were confirmed for e.g. 2.3 but don't have that
version set, should we be able to add it?

Thanks for the clarification and sorry for not asking about it :)
Daniel

From rdmurray at bitdance.com  Wed Mar 25 02:25:47 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 21:25:47 -0400 (EDT)
Subject: [Tracker-discuss] type field, specifically 'crash',
 and proper  setting of 'versions'
In-Reply-To: <2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com>
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0903242023290.31981@kimball.webabinitio.net>

On Tue, 24 Mar 2009 at 21:17, Daniel (ajax) Diniz wrote:
> Brett Cannon wrote:
>>> Also, what "should" be selected in the versions field? ??All versions in
>>> which the bug appears? ??Only versions in which the bug might get
>>> fixed? ??The version in which it was reported plus any later versions
>>> in which it is still broken?
>>
>> Any version it is known to be broken in. So if it was reported in 2.5 and it
>> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It lets
>> people who are using old versions find out what they might have to watch out
>> for since we are not about to fix anything for 2.5 that is not
>> security-related.
>
> Oopsie, I've applied a different rule to a couple of hundred of issues :)
>
> I'll use this rule from now on and eventually fix the wrong changes.
> IIRC, my wrong interpretation is somewhat widespread, so it might be
> interesting to add help/descriptions to the versions input.
>
> Some doubts:
>  For a bug filled against e.g. 2.4 that was confirmed then but not
> yet in any new versions, should we add current versions to denote they
> need checking?
>  For bugs filled against e.g. 2.5 that were never confirmed, should
> we add the current version? And should we try to verify it for the old
> one?
>  For bugs that were confirmed for e.g. 2.3 but don't have that
> version set, should we be able to add it?

IMO, given what Brett said, we should only add ones for which we can
confirm the bug exists, so if there's no test then it would only be
the one the submitter reported, with the stage set to test required.
If there's a test, then run it.  I would imagine we could assume that
if the bug exists in trunk it exists in all versions in between, so we'd
only need to run two tests in most cases (trunk and py3k).

For issues with patches it is often possible to figure out that the
bug still exists in current versions just by inspecting the source.

But this is just IMO ;)

--
R. David Murray           http://www.bitdance.com

From rdmurray at bitdance.com  Wed Mar 25 02:40:57 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Mar 2009 21:40:57 -0400 (EDT)
Subject: [Tracker-discuss] commit review
Message-ID: <Pine.LNX.4.64.0903242135231.31981@kimball.webabinitio.net>

A message went by (from Martin?) that I seem to have deleted that I
believe said that 'commit review' was appropriate if the reviewer thought
the patch was ready for final committer review and (hopefully) commit.
That's what I'd like it to mean, but http://www.python.org/dev/workflow
indicates it is for a second review when (and only when?) a release
candidate is in prep.

So which is it? :)

--
R. David Murray           http://www.bitdance.com


From brett at python.org  Wed Mar 25 03:24:25 2009
From: brett at python.org (Brett Cannon)
Date: Tue, 24 Mar 2009 19:24:25 -0700
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com> 
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
Message-ID: <bbaeab100903241924r2aabbd4fw6e4603523e733eb9@mail.gmail.com>

On Tue, Mar 24, 2009 at 17:17, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:

> Brett Cannon wrote:
> >> Also, what "should" be selected in the versions field?  All versions in
> >> which the bug appears?  Only versions in which the bug might get
> >> fixed?  The version in which it was reported plus any later versions
> >> in which it is still broken?
> >
> > Any version it is known to be broken in. So if it was reported in 2.5 and
> it
> > still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It
> lets
> > people who are using old versions find out what they might have to watch
> out
> > for since we are not about to fix anything for 2.5 that is not
> > security-related.
>
> Oopsie, I've applied a different rule to a couple of hundred of issues :)
>
> I'll use this rule from now on and eventually fix the wrong changes.
> IIRC, my wrong interpretation is somewhat widespread, so it might be
> interesting to add help/descriptions to the versions input.
>

Don't worry about this too much. Were you just resetting the version to the
latest one if you found out the bug still existed?


>
> Some doubts:
>  For a bug filled against e.g. 2.4 that was confirmed then but not
> yet in any new versions, should we add current versions to denote they
> need checking?


No. Only update the version if it has been confirmed. Having not set acts as
a flag that it has not been not been confirmed for trunk.


>
>  For bugs filled against e.g. 2.5 that were never confirmed, should
> we add the current version? And should we try to verify it for the old
> one?


Just worry about the current version.


>
>  For bugs that were confirmed for e.g. 2.3 but don't have that
> version set, should we be able to add it?


If it was confirmed you can add it if you want.

The really critical thing here is to only set it on version where the bug
has been verified. That way it is easy to tell when it is a known issue
still and one does not need to check again.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/60af21b1/attachment.htm>

From brett at python.org  Wed Mar 25 03:25:13 2009
From: brett at python.org (Brett Cannon)
Date: Tue, 24 Mar 2009 19:25:13 -0700
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <Pine.LNX.4.64.0903242023290.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com> 
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com> 
	<Pine.LNX.4.64.0903242023290.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241925r5bc8760ejb9053b68f5487c1f@mail.gmail.com>

On Tue, Mar 24, 2009 at 18:25, R. David Murray <rdmurray at bitdance.com>wrote:

> On Tue, 24 Mar 2009 at 21:17, Daniel (ajax) Diniz wrote:
>
>> Brett Cannon wrote:
>>
>>> Also, what "should" be selected in the versions field?  All versions in
>>>> which the bug appears?  Only versions in which the bug might get
>>>> fixed?  The version in which it was reported plus any later versions
>>>> in which it is still broken?
>>>>
>>>
>>> Any version it is known to be broken in. So if it was reported in 2.5 and
>>> it
>>> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It
>>> lets
>>> people who are using old versions find out what they might have to watch
>>> out
>>> for since we are not about to fix anything for 2.5 that is not
>>> security-related.
>>>
>>
>> Oopsie, I've applied a different rule to a couple of hundred of issues :)
>>
>> I'll use this rule from now on and eventually fix the wrong changes.
>> IIRC, my wrong interpretation is somewhat widespread, so it might be
>> interesting to add help/descriptions to the versions input.
>>
>> Some doubts:
>>  For a bug filled against e.g. 2.4 that was confirmed then but not
>> yet in any new versions, should we add current versions to denote they
>> need checking?
>>  For bugs filled against e.g. 2.5 that were never confirmed, should
>> we add the current version? And should we try to verify it for the old
>> one?
>>  For bugs that were confirmed for e.g. 2.3 but don't have that
>> version set, should we be able to add it?
>>
>
> IMO, given what Brett said, we should only add ones for which we can
> confirm the bug exists, so if there's no test then it would only be
> the one the submitter reported, with the stage set to test required.
> If there's a test, then run it.  I would imagine we could assume that
> if the bug exists in trunk it exists in all versions in between, so we'd
> only need to run two tests in most cases (trunk and py3k).
>

Exactly.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/69254c99/attachment-0001.htm>

From brett at python.org  Wed Mar 25 03:46:51 2009
From: brett at python.org (Brett Cannon)
Date: Tue, 24 Mar 2009 19:46:51 -0700
Subject: [Tracker-discuss] commit review
In-Reply-To: <Pine.LNX.4.64.0903242135231.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903242135231.31981@kimball.webabinitio.net>
Message-ID: <bbaeab100903241946i5b108d88v4ab8fc31749a572@mail.gmail.com>

On Tue, Mar 24, 2009 at 18:40, R. David Murray <rdmurray at bitdance.com>wrote:

> A message went by (from Martin?) that I seem to have deleted that I
> believe said that 'commit review' was appropriate if the reviewer thought
> the patch was ready for final committer review and (hopefully) commit.
> That's what I'd like it to mean, but http://www.python.org/dev/workflow
> indicates it is for a second review when (and only when?) a release
> candidate is in prep.


It means it is specifically ready for a core developer to review. Think of a
patch review as somebody such as yourself, David, has reviewed the patch and
said it looks good. Then you can set it to "committer review" for a core
developer to take a quick look and commit it. When Python is not in the
middle of an RC going through committer review is optional for core
developers. I will try to clarify that while I am at PyCon along with
documenting the Type and Versions fields.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/611ac04a/attachment.htm>

From stephen at xemacs.org  Wed Mar 25 06:47:46 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 25 Mar 2009 14:47:46 +0900
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
Message-ID: <87hc1idugt.fsf@xemacs.org>

Brett Cannon writes:

 > What do other people think? If others are happy with Stage as it is then we
 > could add the "Needs docs" step along with "Needs backporting" and that
 > should fill in the gaps along with a "Needs Decision" keyword to help grab
 > the attention of core developers when people are stuck and need help with
 > deciding how to do something (should address Tennessee's desires).

There's plenty of stuff that "needs decision" being discussed on
python-dev.  Are committers really going to troll the tracker for the
"needs decision" keyword?

 > But I do not want to add the maintenance headache of listing every
 > top-level module and package in the stdlib.

XEmacs's tracker has had that from day 1.  It's not a burden at all.


From bcannon at gmail.com  Wed Mar 25 07:19:16 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Tue, 24 Mar 2009 23:19:16 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <87hc1idugt.fsf@xemacs.org>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com> 
	<87hc1idugt.fsf@xemacs.org>
Message-ID: <bbaeab100903242319j189a2fd0h6211fd8854996713@mail.gmail.com>

On Tue, Mar 24, 2009 at 22:47, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Brett Cannon writes:
>
>  > What do other people think? If others are happy with Stage as it is then
> we
>  > could add the "Needs docs" step along with "Needs backporting" and that
>  > should fill in the gaps along with a "Needs Decision" keyword to help
> grab
>  > the attention of core developers when people are stuck and need help
> with
>  > deciding how to do something (should address Tennessee's desires).
>
> There's plenty of stuff that "needs decision" being discussed on
> python-dev.  Are committers really going to troll the tracker for the
> "needs decision" keyword?
>

Maybe, maybe not. Don't honestly know. Obviously this can be left out for
now.


>
>  > But I do not want to add the maintenance headache of listing every
>  > top-level module and package in the stdlib.
>
> XEmacs's tracker has had that from day 1.  It's not a burden at all.
>
>
How many do you guys have? Is it equivalent to Python's nearly 140?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/f7410699/attachment.htm>

From tleeuwenburg at gmail.com  Wed Mar 25 07:25:43 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Wed, 25 Mar 2009 17:25:43 +1100
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <87hc1idugt.fsf@xemacs.org>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<87hc1idugt.fsf@xemacs.org>
Message-ID: <43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>

On Wed, Mar 25, 2009 at 4:47 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Brett Cannon writes:
>
>  > What do other people think? If others are happy with Stage as it is then
> we
>  > could add the "Needs docs" step along with "Needs backporting" and that
>  > should fill in the gaps along with a "Needs Decision" keyword to help
> grab
>  > the attention of core developers when people are stuck and need help
> with
>  > deciding how to do something (should address Tennessee's desires).
>
> There's plenty of stuff that "needs decision" being discussed on
> python-dev.  Are committers really going to troll the tracker for the
> "needs decision" keyword?


I'm not sure that "needs decision" does in fact address what I'm talking
about, and I am also concerned that it would make the committers life
harder. What I wanted wasn't a flag to get a committer's attention on the
issue, but rather a flag for the committers not to waste their time until
the issue has been bashed into shape. It's a flag that the people involved
are still debating what to do about the issue, and it's not yet ready for
higher consideration.

Under that model, I imagine the core committers would do what (I think) they
have always done -- react to what is on python-dev, review patches when they
are flagged as ready, and take up specific issues which are of interest to
them.

I would use use the new flag when processing new issues often. I'm currently
involved in a discussion about the implementation of additional operators
for timedelta objects, for example. In this case there's a patch, but the
functionality is still being debated amongst the group (it had been dormant
for a while before  I commented on it). If I want the input of a committer,
there's nothing stopping me from posting to python-dev for more input.
However, I would love to mark the issue as "under discussion" so that I can
start categorising issues into two camps -- one which is ready for
development and one which is not. For example, I'm considering building some
sub-issues, some which deal with uncontroversial aspects of the parent
issue, so that they can move forward, and others which will concentrate on
the thorny bits. At the moment, all the new functionality is being blocked
by the debate.

I feel that I have all the power I need to get more attention to this issue
if I want, but what I can't do is exclude it from the list of "new" issues.
It's not ready for any of the "stage" levels as yet, but it's not "fully up
for grabs" either. It's in a pre-development, post-triage state.

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

From stephen at xemacs.org  Wed Mar 25 15:19:45 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 25 Mar 2009 23:19:45 +0900
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <bbaeab100903242319j189a2fd0h6211fd8854996713@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<87hc1idugt.fsf@xemacs.org>
	<bbaeab100903242319j189a2fd0h6211fd8854996713@mail.gmail.com>
Message-ID: <87y6uty9a6.fsf@xemacs.org>

Brett Cannon writes:

 > >  > But I do not want to add the maintenance headache of listing every
 > >  > top-level module and package in the stdlib.
 > >
 > > XEmacs's tracker has had that from day 1.  It's not a burden at all.
 > >
 > >
 > How many do you guys have? Is it equivalent to Python's nearly 140?

Yes and maybe no.  I currently have things categorized into 12 generic
categories ("core code stable", "core code trunk", "website",
"tracker", ...), 1 "new package" category for requests to add an
externally maintained package, and 130 packages.  So on pure count
it's neck and neck.

But about 1/3 of the packages are applications (stuff like the
calendar package, several MUAs, a web browser, a couple of IRC
clients, a window manager for X11), another 1/3 implement editor modes
(cc-mode for C, AUCTeX for TeX/LaTeX, nXML, python-mode :-), and about
1/3 lower-level facilities (comint which provides command-shell-like
functionality, maillib approximately equivalent to Python's email
package, a wrapper for Xlib, etc.  So I have to admit that the kind of
thing that happens in Python with libraries built on packages built on
modules is much more limited, to about 35 of those packages.  And the
density of dependencies is lower.

Still, it's worthwhile in practice and not a hassle.  OPs don't
actually use the module flag very much (most issues come in by mail
still), it's mostly added in triage.  Nevertheless, they don't
complain about it being a required field in the web interface; I think
it's easy for ordinary users to make a pretty good guess at who should
look at the issue.  It is useful for our "external package
maintainers" (people who *use* XEmacs but *develop* a module) as a way
to flag "their issues".  And the maintainers don't mind the occasional
inaccuracy, they're quick to throw anything that doesn't belong to
them back over the fence, usually into a much more appropriate
backyard.

Maintenance is trivial, I do it through the web mostly.  New packages
are not exactly an everyday event.

The only real gripe I have is that the Roundup list widget stinks for
lists longer than fit on a single screen.  I need to write a thunk to
reformat that list into a multicolumn table that scrolls both
vertically and horizontally.

From bcannon at gmail.com  Wed Mar 25 15:37:04 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 25 Mar 2009 07:37:04 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com> 
	<87hc1idugt.fsf@xemacs.org>
	<43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
Message-ID: <bbaeab100903250737i5aa7478fv3f9f044acbb5b7f7@mail.gmail.com>

On Tue, Mar 24, 2009 at 23:25, Tennessee Leeuwenburg <tleeuwenburg at gmail.com
> wrote:

>
>
> On Wed, Mar 25, 2009 at 4:47 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:
>
>> Brett Cannon writes:
>>
>>  > What do other people think? If others are happy with Stage as it is
>> then we
>>  > could add the "Needs docs" step along with "Needs backporting" and that
>>  > should fill in the gaps along with a "Needs Decision" keyword to help
>> grab
>>  > the attention of core developers when people are stuck and need help
>> with
>>  > deciding how to do something (should address Tennessee's desires).
>>
>> There's plenty of stuff that "needs decision" being discussed on
>> python-dev.  Are committers really going to troll the tracker for the
>> "needs decision" keyword?
>
>
> I'm not sure that "needs decision" does in fact address what I'm talking
> about, and I am also concerned that it would make the committers life
> harder. What I wanted wasn't a flag to get a committer's attention on the
> issue, but rather a flag for the committers not to waste their time until
> the issue has been bashed into shape. It's a flag that the people involved
> are still debating what to do about the issue, and it's not yet ready for
> higher consideration.
>
> Under that model, I imagine the core committers would do what (I think)
> they have always done -- react to what is on python-dev, review patches when
> they are flagged as ready, and take up specific issues which are of interest
> to them.
>
> I would use use the new flag when processing new issues often. I'm
> currently involved in a discussion about the implementation of additional
> operators for timedelta objects, for example. In this case there's a patch,
> but the functionality is still being debated amongst the group (it had been
> dormant for a while before  I commented on it). If I want the input of a
> committer, there's nothing stopping me from posting to python-dev for more
> input. However, I would love to mark the issue as "under discussion" so that
> I can start categorising issues into two camps -- one which is ready for
> development and one which is not. For example, I'm considering building some
> sub-issues, some which deal with uncontroversial aspects of the parent
> issue, so that they can move forward, and others which will concentrate on
> the thorny bits. At the moment, all the new functionality is being blocked
> by the debate.
>
> I feel that I have all the power I need to get more attention to this issue
> if I want, but what I can't do is exclude it from the list of "new" issues.
> It's not ready for any of the "stage" levels as yet, but it's not "fully up
> for grabs" either. It's in a pre-development, post-triage state.
>

Well, it has been suggested to add a "confirmed" stage to say the issue has
been triaged, but nothing more. After that committers can simply wait until
an issue has reached "patch review" or "committer review" if triaging ends
up working that well.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090325/5f194ddb/attachment.htm>

From stephen at xemacs.org  Wed Mar 25 15:49:25 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 25 Mar 2009 23:49:25 +0900
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<87hc1idugt.fsf@xemacs.org>
	<43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
Message-ID: <87wsady7wq.fsf@xemacs.org>

Tennessee Leeuwenburg writes:

 > I would use use the new flag when processing new issues often.

Well, obviously.  I certainly give you due respect that you're not
adding complexity for the sake of redundancy!  But the question is
will anybody *else* look at the new flag?

 > I'm currently involved in a discussion about the implementation of
 > additional operators for timedelta objects, for example. In this
 > case there's a patch, but the functionality is still being debated
 > amongst the group (it had been dormant for a while before I
 > commented on it). If I want the input of a committer, there's
 > nothing stopping me from posting to python-dev for more input.

So don't, and I'll bet nobody who matters will look at the issue until
you do.<wink>

 > However, I would love to mark the issue as "under discussion" so
 > that I can start categorising issues into two camps -- one which is
 > ready for development and one which is not.  For example, I'm
 > considering building some sub-issues, some which deal with
 > uncontroversial aspects of the parent issue, so that they can move
 > forward, and others which will concentrate on the thorny bits.

It seems to me that by doing that you'll get exactly the right result
without marking the parent issue in any special way (except possibly
"closed/superseded" if you're really confident that the broken out
issues capture everything currently under discussion).

One thing that is missing in Roundup is the concept of a blocking
issue in the sense of dependency.  That is, you have a 'improve
timedelta' issue; now you'd like to split it into 'fix parsing bug'
and 'add new input format' (like on TV, this is a work of fiction --
any resemblance to real issues is pure luck).  What we'd like to have
is a way to mark these three as related, and have it that "improve" is
resolved if and only if *both* "fix" and "add" are resolved.  Ie,
"improve" depends on (is blocked by) "fix" and "add".

That's in theory, and lots of bug trackers have it.  I don't have
experience with it so I can't say if it would be useful to add.
Maintaining dependencies, even in these simple cases, is an order of
magnitude more complex that (say) guessing which module contains the
defect that we need to fix.  It might be easier and just as effective
to simply insist on factoring issues into more or less independent sub
issues that supersede the parent completely.

 > I feel that I have all the power I need to get more attention to
 > this issue if I want, but what I can't do is exclude it from the
 > list of "new" issues.

This is the first time I've heard anybody worry about their issues
getting too much attention!<wink>


From bcannon at gmail.com  Wed Mar 25 15:46:16 2009
From: bcannon at gmail.com (Brett Cannon)
Date: Wed, 25 Mar 2009 07:46:16 -0700
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <87wsady7wq.fsf@xemacs.org>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net> 
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com> 
	<87hc1idugt.fsf@xemacs.org>
	<43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com> 
	<87wsady7wq.fsf@xemacs.org>
Message-ID: <bbaeab100903250746h73cf2aem550d3080a62bfa58@mail.gmail.com>

On Wed, Mar 25, 2009 at 07:49, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Tennessee Leeuwenburg writes:
>
>  > I would use use the new flag when processing new issues often.
>
> Well, obviously.  I certainly give you due respect that you're not
> adding complexity for the sake of redundancy!  But the question is
> will anybody *else* look at the new flag?
>
>  > I'm currently involved in a discussion about the implementation of
>  > additional operators for timedelta objects, for example. In this
>  > case there's a patch, but the functionality is still being debated
>  > amongst the group (it had been dormant for a while before I
>  > commented on it). If I want the input of a committer, there's
>  > nothing stopping me from posting to python-dev for more input.
>
> So don't, and I'll bet nobody who matters will look at the issue until
> you do.<wink>
>
>  > However, I would love to mark the issue as "under discussion" so
>  > that I can start categorising issues into two camps -- one which is
>  > ready for development and one which is not.  For example, I'm
>  > considering building some sub-issues, some which deal with
>  > uncontroversial aspects of the parent issue, so that they can move
>  > forward, and others which will concentrate on the thorny bits.
>
> It seems to me that by doing that you'll get exactly the right result
> without marking the parent issue in any special way (except possibly
> "closed/superseded" if you're really confident that the broken out
> issues capture everything currently under discussion).
>
> One thing that is missing in Roundup is the concept of a blocking
> issue in the sense of dependency.  That is, you have a 'improve
> timedelta' issue; now you'd like to split it into 'fix parsing bug'
> and 'add new input format' (like on TV, this is a work of fiction --
> any resemblance to real issues is pure luck).  What we'd like to have
> is a way to mark these three as related, and have it that "improve" is
> resolved if and only if *both* "fix" and "add" are resolved.  Ie,
> "improve" depends on (is blocked by) "fix" and "add".
>

What do you mean Roundup doesn't have this? We use the Dependencies field to
signal that the issue cannot be considered finished until the listed
dependencies are closed. And that's easy to tell thanks to Daniel and Martin
getting closed dependency issues showing up as crossed off.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090325/1cc08eb2/attachment-0001.htm>

From stephen at xemacs.org  Wed Mar 25 16:23:15 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 26 Mar 2009 00:23:15 +0900
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <bbaeab100903250746h73cf2aem550d3080a62bfa58@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>
	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>
	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<87hc1idugt.fsf@xemacs.org>
	<43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
	<87wsady7wq.fsf@xemacs.org>
	<bbaeab100903250746h73cf2aem550d3080a62bfa58@mail.gmail.com>
Message-ID: <87tz5hy6cc.fsf@xemacs.org>

Brett Cannon writes:

 > What do you mean Roundup doesn't have this? We use the Dependencies
 > field to signal that the issue cannot be considered finished until
 > the listed dependencies are closed. And that's easy to tell thanks
 > to Daniel and Martin getting closed dependency issues showing up as
 > crossed off.

I think I mean I haven't taken a close look at the Python tracker in
at least 6 months ... vanilla Roundup (and XEmacs's tracker) don't
have it.  (And I was even looking at it 20 minutes before I wrote that
:-(, but I'm (obviously) more familiar with XEmacs's tracker.)

Sorry for the nasty transient drop in S/N there!

From martin at v.loewis.de  Wed Mar 25 23:54:59 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 25 Mar 2009 17:54:59 -0500
Subject: [Tracker-discuss] type field, specifically 'crash',
 and proper 	setting of 'versions'
In-Reply-To: <2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net>
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com>
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com>
Message-ID: <49CAB643.9040207@v.loewis.de>

>> Any version it is known to be broken in. So if it was reported in 2.5 and it
>> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It lets
>> people who are using old versions find out what they might have to watch out
>> for since we are not about to fix anything for 2.5 that is not
>> security-related.
> 
> Oopsie, I've applied a different rule to a couple of hundred of issues :)

So do I: I only tag the versions where the bug should be fixed, or, more
precisely, where there is still action needed.

So I remove a version from the list if the bug exists in that versions, 
but will not be fixed there, and also remove a version if a patch has
been applied to that version, but still needs to be applied to other
versions.

> I'll use this rule from now on and eventually fix the wrong changes.
> IIRC, my wrong interpretation is somewhat widespread, so it might be
> interesting to add help/descriptions to the versions input.

Don't switch so easily. I like my rule better than Brett's - what's
your rule?

Regards,
Martin


From martin at v.loewis.de  Thu Mar 26 00:19:03 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 25 Mar 2009 18:19:03 -0500
Subject: [Tracker-discuss] commit review
In-Reply-To: <Pine.LNX.4.64.0903242135231.31981@kimball.webabinitio.net>
References: <Pine.LNX.4.64.0903242135231.31981@kimball.webabinitio.net>
Message-ID: <49CABBE7.9060807@v.loewis.de>

R. David Murray schrieb:
> A message went by (from Martin?) that I seem to have deleted that I
> believe said that 'commit review' was appropriate if the reviewer thought
> the patch was ready for final committer review and (hopefully) commit.
> That's what I'd like it to mean, but http://www.python.org/dev/workflow
> indicates it is for a second review when (and only when?) a release
> candidate is in prep.
> 
> So which is it? :)

I actually don't know. I said it was the former, but that was a guess
only.

I have personally ignored the stage field so far at all.

Regards,
Martin

From martin at v.loewis.de  Thu Mar 26 01:03:00 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 25 Mar 2009 19:03:00 -0500
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <87hc1idugt.fsf@xemacs.org>
References: <0016e64b9d0862f5420465bedc70@google.com>	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>
	<87hc1idugt.fsf@xemacs.org>
Message-ID: <49CAC634.6050809@v.loewis.de>

> There's plenty of stuff that "needs decision" being discussed on
> python-dev.  Are committers really going to troll the tracker for the
> "needs decision" keyword?

I know I'm not. I sometimes give an opinion when I get explicitly
asked for one, but sometimes also don't. I would not actively search
for issues that need my opinion.

OTOH, if other people want to search for this, to post list of them
to python-dev, I let them go ahead.

I *am* worried about the shyness that shines through, though.
Anybody performing the review should be able to propose a decision.
It might be that he had been missing some aspect, so some
maintainer will revert this decision, but there is no reason to be
shy of giving an opinion, and publicly announcing it in the tracker.

Of course, for some issue, one needs to do research first, i.e.
study the code, study some specifications, study the use case,
try reproducing the issue, etc. It's fine if some reviewer doesn't
want to contribute the time for that. In that case, it is best if
the issue remains unreviewed, until somebody comes along who does
the necessary research.

Regards,
Martin

From martin at v.loewis.de  Thu Mar 26 01:14:42 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 25 Mar 2009 19:14:42 -0500
Subject: [Tracker-discuss] bugs.python.org schema redesign
In-Reply-To: <43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
References: <0016e64b9d0862f5420465bedc70@google.com>	<Pine.LNX.4.64.0903240627320.31981@kimball.webabinitio.net>	<bbaeab100903241401v53fb4e68la98001ad8c1d2d6@mail.gmail.com>	<87hc1idugt.fsf@xemacs.org>
	<43c8685c0903242325i4d017c18p5f1799f146773f1d@mail.gmail.com>
Message-ID: <49CAC8F2.1090605@v.loewis.de>

> I would use use the new flag when processing new issues often. I'm 
> currently involved in a discussion about the implementation of 
> additional operators for timedelta objects, for example. In this case 
> there's a patch, but the functionality is still being debated amongst 
> the group (it had been dormant for a while before  I commented on it). 

As a reviewer, I think you should try to cut discussion. If you think
the patch is inappropriate for some reason, state your complaints about
it. If the submitter is then uncooperative, just reject the patch 
(unless you want to work on it yourself); offer to the submitter that
he needs to write a PEP if he wants it his way.

Contributors react often pissed-off if they don't get it their way.
If valid concerns remain, it is (IMO) still best for the project to
reject the contribution (after first threatening to do so). In some
cases, after a day or two, the contributor comes back and bites the
bullet. In some cases, somebody else interested in the issue will pick
it up, and provide the requested changes. If the issue is really
contentious, a PEP is the formal process to resolve such debates.

> I feel that I have all the power I need to get more attention to this 
> issue if I want, but what I can't do is exclude it from the list of 
> "new" issues. It's not ready for any of the "stage" levels as yet, but 
> it's not "fully up for grabs" either. It's in a pre-development, 
> post-triage state.

One way might be to assign it to yourself, if you want to lead the 
discussion. Assignment-to-self is usually interpreted as a request
for other people to stay out of the issue (that is also why assignment
to other people is really problematic - if they don't want the issue,
assigning it essentially means that it gets stuck).

Regards,
Martin


From ajaksu at gmail.com  Thu Mar 26 01:50:01 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Wed, 25 Mar 2009 21:50:01 -0300
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <49CAB643.9040207@v.loewis.de>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com> 
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com> 
	<49CAB643.9040207@v.loewis.de>
Message-ID: <2d75d7660903251750j744c7762r5a07048a296cb3cf@mail.gmail.com>

"Martin v. L?wis" wrote:
>>> Any version it is known to be broken in. So if it was reported in 2.5 and
>>> it
>>> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It
>>> lets
>>> people who are using old versions find out what they might have to watch
>>> out
>>> for since we are not about to fix anything for 2.5 that is not
>>> security-related.
>>
>> Oopsie, I've applied a different rule to a couple of hundred of issues :)
>
> So do I: I only tag the versions where the bug should be fixed, or, more
> precisely, where there is still action needed.
>
> So I remove a version from the list if the bug exists in that versions, but
> will not be fixed there, and also remove a version if a patch has
> been applied to that version, but still needs to be applied to other
> versions.

It seems to be a matter of favoring an operative versus an informative
use of the tracker. I think both make sense and that consensus is
simple in this specific case.

>> I'll use this rule from now on and eventually fix the wrong changes.
>> IIRC, my wrong interpretation is somewhat widespread, so it might be
>> interesting to add help/descriptions to the versions input.
>
> Don't switch so easily. I like my rule better than Brett's - what's
> your rule?

Mine is 'be doubtful, always' :)

OK, more seriously, I've been working under the operative assumption,
more specifically using a "RFEs set to next major releases, bugs (and
doc RFEs) for current major releases" rule that I'm pretty sure I
learned somewhere a long time ago. But it was a rule about when things
get fixed/addresses, not about what to set in the tracker, IIRC.

I think consensus here is easy. It's possible to mark all versions in
Brett's rule and have tooltips explaining which fixes can land in
which versions (and we operative people would have to learn to look at
the selected versions in a slightly different way). Or we could select
versions in the operative way and include the data from the
informative one in messages or in a new property (and have tooltips
for version explaining how to learn which versions are affected).

Right now, having the informative data in messages would be broken, as
the tokens shorter than three characters aren't indexed (and periods
split tokens), but that would be really easy to fix (we could even
include a regex to find the 'affects python x.x' comments).

So I'd like to cater for the other rule regardless of which one we
choose for selecting versions :)

perhaps-I-should-be-in-social-sciences-ly y'rs,
Daniel

From brett at python.org  Thu Mar 26 03:40:53 2009
From: brett at python.org (Brett Cannon)
Date: Wed, 25 Mar 2009 19:40:53 -0700
Subject: [Tracker-discuss] type field, specifically 'crash',
	and proper 	setting of 'versions'
In-Reply-To: <2d75d7660903251750j744c7762r5a07048a296cb3cf@mail.gmail.com>
References: <Pine.LNX.4.64.0903232211550.31981@kimball.webabinitio.net> 
	<bbaeab100903241637p65c090c0x7181932bdb65621d@mail.gmail.com> 
	<2d75d7660903241717m545dd690r541406c43344572@mail.gmail.com> 
	<49CAB643.9040207@v.loewis.de>
	<2d75d7660903251750j744c7762r5a07048a296cb3cf@mail.gmail.com>
Message-ID: <bbaeab100903251940t3a6af4aanded6b0dd7d5a7207@mail.gmail.com>

On Wed, Mar 25, 2009 at 17:50, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:

> "Martin v. L?wis" wrote:
> >>> Any version it is known to be broken in. So if it was reported in 2.5
> and
> >>> it
> >>> still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It
> >>> lets
> >>> people who are using old versions find out what they might have to
> watch
> >>> out
> >>> for since we are not about to fix anything for 2.5 that is not
> >>> security-related.
> >>
> >> Oopsie, I've applied a different rule to a couple of hundred of issues
> :)
> >
> > So do I: I only tag the versions where the bug should be fixed, or, more
> > precisely, where there is still action needed.
> >
> > So I remove a version from the list if the bug exists in that versions,
> but
> > will not be fixed there, and also remove a version if a patch has
> > been applied to that version, but still needs to be applied to other
> > versions.
>
> It seems to be a matter of favoring an operative versus an informative
> use of the tracker. I think both make sense and that consensus is
> simple in this specific case.
>
> >> I'll use this rule from now on and eventually fix the wrong changes.
> >> IIRC, my wrong interpretation is somewhat widespread, so it might be
> >> interesting to add help/descriptions to the versions input.
> >
> > Don't switch so easily. I like my rule better than Brett's - what's
> > your rule?
>
> Mine is 'be doubtful, always' :)
>
> OK, more seriously, I've been working under the operative assumption,
> more specifically using a "RFEs set to next major releases, bugs (and
> doc RFEs) for current major releases" rule that I'm pretty sure I
> learned somewhere a long time ago. But it was a rule about when things
> get fixed/addresses, not about what to set in the tracker, IIRC.
>
> I think consensus here is easy. It's possible to mark all versions in
> Brett's rule and have tooltips explaining which fixes can land in
> which versions (and we operative people would have to learn to look at
> the selected versions in a slightly different way). Or we could select
> versions in the operative way and include the data from the
> informative one in messages or in a new property (and have tooltips
> for version explaining how to learn which versions are affected).


Go with Martin's approach; less clicking.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090325/05588af9/attachment.htm>

From metatracker at psf.upfronthosting.co.za  Thu Mar 26 04:30:27 2009
From: metatracker at psf.upfronthosting.co.za (Skip Montanaro)
Date: Thu, 26 Mar 2009 03:30:27 +0000
Subject: [Tracker-discuss] [issue254] Roundup treats <URL> badly
In-Reply-To: <1238038227.04.0.719265951876.issue254@psf.upfronthosting.co.za>
Message-ID: <1238038227.04.0.719265951876.issue254@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

Take a look at this setuptools issue:

  http://bugs.python.org/setuptools/issue63

When I first posted it I embedded a Google Code tracker URL in <...>.  Roundup
should almost certainly treat literal '<' and '>' as not part of URLs.  It
encoded the trailing '>' and generated a bogus URL.

----------
messages: 1276
nosy: montanaro
priority: bug
status: unread
title: Roundup treats <URL> badly

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 27 16:29:06 2009
From: metatracker at psf.upfronthosting.co.za (Amaury Forgeot d'Arc)
Date: Fri, 27 Mar 2009 15:29:06 +0000
Subject: [Tracker-discuss] [issue255] three consecutive commas in feedback
	message
In-Reply-To: <1238167746.67.0.0539775237706.issue255@psf.upfronthosting.co.za>
Message-ID: <1238167746.67.0.0539775237706.issue255@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

I just updated a issue in the python tracker, and the result page was:

http://bugs.python.org/issue5568?@ok_message=msg%2084263%20created%3Cbr%3Eissue%205568%20status%2C%20message_count%2C%20nosy_count%2C%20nosy%2C%20messages%2C%20resolution%20edited%20ok&@template=item

There are two minor formatting issues in this page:
- the green message contains three consecutive commas
- the update history shows two blank lines

I presume these are ghosts of the now-hidden "nosy_count" and "message_count"
attributes.

----------
messages: 1277
nosy: amaury.forgeotdarc
priority: bug
status: unread
title: three consecutive commas in feedback message

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

From metatracker at psf.upfronthosting.co.za  Fri Mar 27 21:13:49 2009
From: metatracker at psf.upfronthosting.co.za (Daniel Diniz)
Date: Fri, 27 Mar 2009 20:13:49 +0000
Subject: [Tracker-discuss] [issue255] three consecutive commas in feedback
	message
In-Reply-To: <1238167746.67.0.0539775237706.issue255@psf.upfronthosting.co.za>
Message-ID: <1238184829.45.0.594496864976.issue255@psf.upfronthosting.co.za>


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

Thanks for the report, this is due to the hacky fix for issue 249.

Since we're working on a clean fix on that issue, I'll close this one as
duplicated :)

----------
nosy: +ajaksu2
status: unread -> resolved
superseder: +message_count and nosy_count changes appear in every mail

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

From skip at pobox.com  Mon Mar 30 16:04:21 2009
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 30 Mar 2009 09:04:21 -0500
Subject: [Tracker-discuss] Problems getting registered (fwd)
Message-ID: <18896.53605.366584.906400@montanaro.dyndns.org>


Can someone help John out?

Skip

-------------- next part --------------
An embedded message was scrubbed...
From: John Posner <jjposner at snet.net>
Subject: Problems getting registered
Date: Sun, 29 Mar 2009 22:34:15 -0400
Size: 4592
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090330/32d66037/attachment.eml>

From martin at v.loewis.de  Tue Mar 31 06:26:06 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 30 Mar 2009 23:26:06 -0500
Subject: [Tracker-discuss] Problems getting registered (fwd)
In-Reply-To: <18896.53605.366584.906400@montanaro.dyndns.org>
References: <18896.53605.366584.906400@montanaro.dyndns.org>
Message-ID: <49D19B5E.3040004@v.loewis.de>

> I've tried three times to register myself at bugs.python.org. But the
> confirmation
> email message never arrives.
> 
> Can you help?

Dear John,

We have tried sending the mail to you, however, it was rejected:

host snetmx4.prodigy.net[207.115.36.23] said: 553 5.3.0 nlpi049 - 
n2U0hwrW015985, DNSBL:ATTRBL 521< 88.198.142.26 
 >_is_blocked.__For_information_see_http://att.net/blocks (in reply to 
MAIL FROM command)

If you can, try registering with an address that doesn't block
us.

Regards,
Martin

P.S. Postmasters: any idea how this problem can be resolved?