From martin at v.loewis.de  Fri Dec  1 00:12:45 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 01 Dec 2006 00:12:45 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F616E.5070103@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F413B.30102@v.loewis.de> <456F616E.5070103@sympatico.ca>
Message-ID: <456F656D.8000408@v.loewis.de>

Stefan Seefeld schrieb:
> As long as they report real bugs that shouldn't make a difference.
> What I find dangerous is that writing mail is so tempting that
> people may forget to do their homework and research (via the
> web interface) whether the bug they are about to report isn't
> already reported.

What I fear if we get many more bug reports is that they are
all feature requests: Why doesn't Python do this and that?...
Isn't it clearly obviously the right thing that it should have
this feature? There might also be an increase in help requests:
I did this and that, and it didn't work - clearly that's
a bug in Python; please let me know what to do.

Many of these reports really deserve an answer "please *think*
before typing". How could Python possibly do what you expect it
to do?

Allowing emails submission only for registered users is a good
thing - it gives people time to think a little more before
submitting their issue, and it make most not wanting to embarrass
themselves for writing non-sense.

Regards,
Martin

From brett at python.org  Fri Dec  1 00:22:56 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 15:22:56 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F5FD8.7020103@v.loewis.de>
References: <455891F0.2050209@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <4568C59F.90809@v.loewis.de>
	<4568C887.6060706@sympatico.ca> <4569515A.9010705@v.loewis.de>
	<456F303C.1090809@sympatico.ca> <456F4070.2090204@v.loewis.de>
	<456F5D5F.9000605@sympatico.ca> <456F5FD8.7020103@v.loewis.de>
Message-ID: <bbaeab100611301522q78e5138bq3ea54fa57990aa7b@mail.gmail.com>

On 11/30/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Stefan Seefeld schrieb:
> > OK, then what about
> >
> > new -> open -> needs_patch_review -> needs_feedback -> closed
>
> That should work. For bugs, something similar should exist:
> how about "confirmed"?


That would be good since bugs need to be verified as  one that can be
reproduced.  I guess that would be a parallel, but mutually exclusive, step
to needs_path_review?  Or should we name it something like needs_patch to be
more explicit?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/8a96455c/attachment.html 

From brett at python.org  Fri Dec  1 00:27:10 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 15:27:10 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F5F2F.6020403@v.loewis.de>
References: <455891F0.2050209@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <4568C59F.90809@v.loewis.de>
	<4568C887.6060706@sympatico.ca> <4569515A.9010705@v.loewis.de>
	<456F303C.1090809@sympatico.ca> <456F4070.2090204@v.loewis.de>
	<ee2a432c0611301349sf00e6dei9c001fc62e1c1b0d@mail.gmail.com>
	<456F5F2F.6020403@v.loewis.de>
Message-ID: <bbaeab100611301527w424259c3qf81ac3b467316b32@mail.gmail.com>

On 11/30/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Neal Norwitz schrieb:
> >> I'm slightly uncomfortable about that approach since it
> >> codifies a process which isn't codified so far. The
> >> discomfort is only about the codification - I can see
> >> that the implied process could actually work.
> >
> > But don't we mostly do that already?
>
> That's true. Still, we currently have a flag "is patch"
> (by having the issue in the patches tracker), so it would
> be a deviation from the status quo not to have that anymore.


Yeah, but the status quo sucks so I think it is fine to deviate.  =)

I know these fine points are not important for the initial
> setup, as they can be changed afterwards. So coding a work-flow
> into the tracker is fine with me, I guess.
>
>
I agree with Neal; let's go ahead and change how things are done now and if
it becomes an issue we can change it.  But I suspect if we help make it easy
to search for issues that are in a specific state it will not only let us
keep on top of things that need to be dealt with in a specific way (e.g.,
patch reviews), but also lets us get people to help us more in terms of
triaging bugs.  Bug days, for instance, could have total newbies look at
'open' bugs to help us flag them properly instead of having to go through
existing bugs and try to find easy ones to deal with.  Better granularity
(w/o being to restrictive) should be a good thing in this respect.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/5a4eb504/attachment.htm 

From brett at python.org  Fri Dec  1 00:30:42 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 15:30:42 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301357w64bd8c49k53f9393fe3cbcf08@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2289.1050305@sympatico.ca>
	<f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>
	<456F49B8.5050805@sympatico.ca>
	<bbaeab100611301338x39edd157m875e6175508cef48@mail.gmail.com>
	<f74a6c2f0611301357w64bd8c49k53f9393fe3cbcf08@mail.gmail.com>
Message-ID: <bbaeab100611301530oea21671nb6f7704d28c5135d@mail.gmail.com>

On 11/30/06, Paul Dubois <pfdubois at gmail.com> wrote:
>
> Yes, Stefan, the discussion about submitting issues by email, is now
> orthogonal to your patch idea. I like the solution you came up with.
>
> Brett, the 'people' who are saying that the email gateway won't be used
> very much seems to consist so far of two people, one of whom at least has no
> experience with Roundup. Although this point is moot for this particular
> issue (patch flag), it is relevant to the schema design in general. We have
> to be prepared for an email submitter, who is in some degree similar to a
> lazy web submitter, who isn't going to touch anything they don't have to
> touch.
>
> My sysadmins have three ways to tell them you need services, in this order
> of preference.
>     a. Use their website
>     b. Email them
>     c. Phone them or catch them in the hall
> Guess what order really happens. (:->


Fair enough.  It looks like this is all going towards a status solution
anyway so both our worries will be dealt with cleanly.  I am willing to stop
arguing over this and just assume that email submissions will be something
to keep in mind.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/0503e209/attachment.html 

From seefeld at sympatico.ca  Fri Dec  1 01:01:47 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 19:01:47 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F656D.8000408@v.loewis.de>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F413B.30102@v.loewis.de> <456F616E.5070103@sympatico.ca>
	<456F656D.8000408@v.loewis.de>
Message-ID: <456F70EB.3010806@sympatico.ca>

Martin v. L?wis wrote:

> Allowing emails submission only for registered users is a good
> thing - it gives people time to think a little more before
> submitting their issue, and it make most not wanting to embarrass
> themselves for writing non-sense.

And you can be sure any reply (such as a request for details) will
actually be received. In another tracker where I (initially) allowed
anonymous submissions I have lots of issues I don't know how to
deal with, because a) I can't reproduce them and b) I can't ask
the submitter to provide more details.

Regards,
		Stefan


-- 

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

From skip at pobox.com  Fri Dec  1 18:58:27 2006
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 1 Dec 2006 11:58:27 -0600
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456ED11B.10508@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
Message-ID: <17776.27971.944859.716899@montanaro.dyndns.org>


    Stefan> Please review and comment on the available fields at

    Stefan> http://psf.upfronthosting.co.za/roundup/tracker/

    Stefan> and in particular:

    Stefan> * type, severity, components, versions, platforms,
    Stefan>   as general issue descriptors

When I click on those descriptors, only severity has any specific values
defined.

Skip

From martin at v.loewis.de  Sat Dec  2 10:28:08 2006
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 02 Dec 2006 10:28:08 +0100
Subject: [Tracker-discuss] Alternative SF export
Message-ID: <45714728.4020500@v.loewis.de>

It seems that SF has finally fixed their tracker export;
using that approach, one can get the tracker data in ten
minutes (rather than through web scraping in several hours).
Notice that this doesn't include attachments; you'll have
to find all attachments by looking at the "File Added"
history records, and then download the attachments
separately (caching them is of course possible)

I made a current version of this export available as

http://svn.python.org/snapshots/tracker061202.xml.bz2

Regards,
Martin

From forsberg at efod.se  Sat Dec  2 15:26:58 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 02 Dec 2006 15:26:58 +0100
Subject: [Tracker-discuss] Alternative SF export
In-Reply-To: <45714728.4020500@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 02 Dec 2006 10:28:08 +0100")
References: <45714728.4020500@v.loewis.de>
Message-ID: <871wni4bm5.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> It seems that SF has finally fixed their tracker export;
> using that approach, one can get the tracker data in ten
> minutes (rather than through web scraping in several hours).
> Notice that this doesn't include attachments; you'll have
> to find all attachments by looking at the "File Added"
> history records, and then download the attachments
> separately (caching them is of course possible)

Oh, that's good news. I'll take a look at the data.

> I made a current version of this export available as
>
> http://svn.python.org/snapshots/tracker061202.xml.bz2

Do you need special permissions at sf do make an export? If possible,
add permissions to my sf user (forsberg) to make exports. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFcY0yrJurFAusidkRAmEsAJ9zunqjzogzKMeZaVtOWjHGqHgRsQCfcGlr
viPA66OcbqgvE4mKwbiWCPg=
=tqa3
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Dec  2 19:16:51 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 02 Dec 2006 19:16:51 +0100
Subject: [Tracker-discuss] Alternative SF export
In-Reply-To: <871wni4bm5.fsf@uterus.efod.se>
References: <45714728.4020500@v.loewis.de> <871wni4bm5.fsf@uterus.efod.se>
Message-ID: <4571C313.2090602@v.loewis.de>

Erik Forsberg schrieb:
> Do you need special permissions at sf do make an export? If possible,
> add permissions to my sf user (forsberg) to make exports. 

You have to be project admin; I made you that. The tracker export
can be reached through

http://sourceforge.net/project/admin/backup.php?group_id=5470

The actual download URL is

http://sourceforge.net/export/xml_export.php?group_id=5470

Regards,
Martin

From barry at python.org  Sun Dec  3 01:24:08 2006
From: barry at python.org (Barry Warsaw)
Date: Sat, 2 Dec 2006 19:24:08 -0500
Subject: [Tracker-discuss] Alternative SF export
In-Reply-To: <45714728.4020500@v.loewis.de>
References: <45714728.4020500@v.loewis.de>
Message-ID: <5A5D095D-A0B2-4436-9F9B-818C755DABA1@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 2, 2006, at 4:28 AM, Martin v. L?wis wrote:

> It seems that SF has finally fixed their tracker export;
> using that approach, one can get the tracker data in ten
> minutes (rather than through web scraping in several hours).
> Notice that this doesn't include attachments; you'll have
> to find all attachments by looking at the "File Added"
> history records, and then download the attachments
> separately (caching them is of course possible)
>
> I made a current version of this export available as
>
> http://svn.python.org/snapshots/tracker061202.xml.bz2

Sweet.

Here's a rough cut at an attachment scraper.  It's a tad bit Mailman- 
centric, but should be easily tweaked for the Python project.   
Suggestions, comments welcome.

http://mailman.svn.sourceforge.net/viewvc/mailman/trunk/sf/ 
getfiles.py?revision=8103&view=markup

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRXIZLXEjvBPtnXfVAQIwbQP/bRMq9hVGbp/rvR+85CZeoMHyruNNsHmH
/VzVz1EzLWuaLqf2Ph9irytNB3iUMXDoosByHeq5W5dj4jMoCA7QMl0eL0LQu7B3
w9iLzw0024vCp7GK8A3n1oUGX8zF/I6bFX9TINT0FY1/Y566Gpj5oydwqaKN/1Wk
LnaXsGbbxZ0=
=B5it
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sun Dec  3 21:39:25 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 03 Dec 2006 21:39:25 +0100
Subject: [Tracker-discuss] Alternative SF export
In-Reply-To: <45714728.4020500@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 02 Dec 2006 10:28:08 +0100")
References: <45714728.4020500@v.loewis.de>
Message-ID: <87hcwck936.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> It seems that SF has finally fixed their tracker export;
> using that approach, one can get the tracker data in ten
> minutes (rather than through web scraping in several hours).
> Notice that this doesn't include attachments; you'll have
> to find all attachments by looking at the "File Added"
> history records, and then download the attachments
> separately (caching them is of course possible)
>
> I made a current version of this export available as
>
> http://svn.python.org/snapshots/tracker061202.xml.bz2

I've spent some time today redesigning the importer to use the .xml
instead of the data screenscraped from the webpages. 

Seems to work rather well, although there is some work left to do. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFczX8rJurFAusidkRAhWmAKCv45QhTsg8FGlQr7HgZ2D0Xbit5wCg1kmw
jmNnk1bE3bL/1drIOole9MQ=
=v9cC
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Mon Dec  4 00:01:13 2006
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 04 Dec 2006 00:01:13 +0100
Subject: [Tracker-discuss] Privacy
Message-ID: <45735739.9050602@v.loewis.de>

I see that email addresses are visible to everybody in the tracker,
and also occur in the body of the email messages.

I know some people are extremely shy to make their email address appear
on a web page, so I think we should do what is possible to comfort them.
At a minimum, the email addresses shouldn't be displayed on the web
site, except for people who have proper permission.

SF solves this entire issue by given each user an account on their
system and an email address. I don't know how difficult it would be
to implement such a feature in the roundup installation. Users could
use a "fake" email address <user>@bugs.python.org, and have mail to
that forwarded to their real email address. Then the fake address
could be used in email messages, so it won't appear in archives
of the bug list.

Alternatively, it might be sufficient to give users a choice of
suppressing their email address in generated email messages.

Regards,
Martin

From pfdubois at gmail.com  Mon Dec  4 02:01:52 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 3 Dec 2006 17:01:52 -0800
Subject: [Tracker-discuss] Privacy
In-Reply-To: <45735739.9050602@v.loewis.de>
References: <45735739.9050602@v.loewis.de>
Message-ID: <f74a6c2f0612031701o3514b0e6kc8ba2b6fb81a71e5@mail.gmail.com>

There is no problem making it so that a normal user can see only their
own information on the web. This is a standard choice in
configuration.


# May users view other user information? Comment these lines out
# if you don't want them to
db.security.addPermissionToRole('User', 'View', 'user')

I'm not an email headers guy so I won't try to answer the second part.

Each Roundup user in effect has an account with a password, and sets their own
email address. They can also provide additional email addresses from
which they may send mail to roundup, besides their 'main' one.

On 12/3/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I see that email addresses are visible to everybody in the tracker,
> and also occur in the body of the email messages.
>
> I know some people are extremely shy to make their email address appear
> on a web page, so I think we should do what is possible to comfort them.
> At a minimum, the email addresses shouldn't be displayed on the web
> site, except for people who have proper permission.
>
> SF solves this entire issue by given each user an account on their
> system and an email address. I don't know how difficult it would be
> to implement such a feature in the roundup installation. Users could
> use a "fake" email address <user>@bugs.python.org, and have mail to
> that forwarded to their real email address. Then the fake address
> could be used in email messages, so it won't appear in archives
> of the bug list.
>
> Alternatively, it might be sufficient to give users a choice of
> suppressing their email address in generated email messages.
>
> Regards,
> Martin
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From seefeld at sympatico.ca  Mon Dec  4 02:02:38 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 03 Dec 2006 20:02:38 -0500
Subject: [Tracker-discuss] Privacy
In-Reply-To: <45735739.9050602@v.loewis.de>
References: <45735739.9050602@v.loewis.de>
Message-ID: <457373AE.3040603@sympatico.ca>

Martin v. L?wis wrote:
> I see that email addresses are visible to everybody in the tracker,
> and also occur in the body of the email messages.

As far as the accessibility of email addresses through the cgi interface
is concerned, we could simply display only the 'username'. For email
displays, I think there is an option to mangle the address (though that
may not be enough for those that don't want to reveal their address not
even to humans.

I'm not quite sure about the 'user at home.org wrote:' display inside messages.
Richard may have some suggestions.

Thanks,
		Stefan

-- 

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

From pfdubois at gmail.com  Mon Dec  4 06:48:35 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 3 Dec 2006 21:48:35 -0800
Subject: [Tracker-discuss] Weekly summary progress report
Message-ID: <f74a6c2f0612032148w71fff1eg375389c41124d33a@mail.gmail.com>

> Your target is to reproduce that report using Roundup and mail it out.
> If it can be done without using email as an input, that would probably
> be more reliable and require less ongoing maintenance.
>
>
Kurt,

So far: can make multipart reports and mail them. Or, just make a text
report and print it. Have not yet separated bug/patch/rfe because they
are still deciding how to set up the schema, but that is a very small
change. I refer below to status -- the status is the open/closed/other
states stuff. They haven't yet completely decided what these are.

I can further break down the stats for the open issues by status. I
can show the current status of the created and reopened issues, can
filter out unwanted statuses or priorities, and can do the report for
any date interval. It works off the database, not the email, and so
there is no need for any retained files between one report and the
next.

So, while I haven't exactly duplicated your report it is functionally
equivalent, and I'll be able to duplicate your report quickly when
things settle down.

We can also provide some data not easily possible with the old script,
such as a list of the top ten most discussed issues in the period.
That was the source of my question about your 'real' goal -- I know
that every existing tool is a consequence of its technology and not
necessarily what someone wanted, or perhaps not all of what they
wanted. In any case, we can save enhancements for later.

From nnorwitz at gmail.com  Mon Dec  4 07:02:34 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 3 Dec 2006 22:02:34 -0800
Subject: [Tracker-discuss] Weekly summary progress report
In-Reply-To: <f74a6c2f0612032148w71fff1eg375389c41124d33a@mail.gmail.com>
References: <f74a6c2f0612032148w71fff1eg375389c41124d33a@mail.gmail.com>
Message-ID: <ee2a432c0612032202g26ac377dm22c360238e5dfd52@mail.gmail.com>

I'm quite pleased how things seem to be progressing.  I don't want to
slow up the progress everyone seems to be making on the tracker.
However, once things settle down, I would like to see a bunch of
different metrics like what you mentioned below.

For example, it might be interesting to know if one bug report is
opened (and closed as a duplicate) 10x as often as others.  It means
we need to fix the doc somehow.  Mean/median age of bug reports.  # of
bug reports closed as invalid (ie, how many false positives do we
get).  These metrics might surprise us and indicate where more effort
could yield larger benefits.  If nothing else, I'd like to present the
info in novel ways that can help motivate people to work on bugs and
fix problems.  This may involved finding/defining small categories.
It's always nice to see 0 bugs in some subset.  It's also always nice
to see the total # of bugs (even if in a subset) decreasing.

n
--
On 12/3/06, Paul Dubois <pfdubois at gmail.com> wrote:
> > Your target is to reproduce that report using Roundup and mail it out.
> > If it can be done without using email as an input, that would probably
> > be more reliable and require less ongoing maintenance.
> >
> >
> Kurt,
>
> So far: can make multipart reports and mail them. Or, just make a text
> report and print it. Have not yet separated bug/patch/rfe because they
> are still deciding how to set up the schema, but that is a very small
> change. I refer below to status -- the status is the open/closed/other
> states stuff. They haven't yet completely decided what these are.
>
> I can further break down the stats for the open issues by status. I
> can show the current status of the created and reopened issues, can
> filter out unwanted statuses or priorities, and can do the report for
> any date interval. It works off the database, not the email, and so
> there is no need for any retained files between one report and the
> next.
>
> So, while I haven't exactly duplicated your report it is functionally
> equivalent, and I'll be able to duplicate your report quickly when
> things settle down.
>
> We can also provide some data not easily possible with the old script,
> such as a list of the top ten most discussed issues in the period.
> That was the source of my question about your 'real' goal -- I know
> that every existing tool is a consequence of its technology and not
> necessarily what someone wanted, or perhaps not all of what they
> wanted. In any case, we can save enhancements for later.
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From kbk at shore.net  Mon Dec  4 16:52:09 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 04 Dec 2006 10:52:09 -0500
Subject: [Tracker-discuss] Weekly summary progress report
In-Reply-To: <f74a6c2f0612032148w71fff1eg375389c41124d33a@mail.gmail.com>
	(Paul Dubois's message of "Sun, 3 Dec 2006 21:48:35 -0800")
References: <f74a6c2f0612032148w71fff1eg375389c41124d33a@mail.gmail.com>
Message-ID: <87wt571wwm.fsf@hydra.bayview.thirdcreek.com>

"Paul Dubois" <pfdubois at gmail.com> writes:

> So, while I haven't exactly duplicated your report it is functionally
> equivalent, and I'll be able to duplicate your report quickly when
> things settle down.
>
> We can also provide some data not easily possible with the old script,
> such as a list of the top ten most discussed issues in the period.
> That was the source of my question about your 'real' goal -- I know
> that every existing tool is a consequence of its technology and not
> necessarily what someone wanted, or perhaps not all of what they
> wanted. In any case, we can save enhancements for later.

That's true.  I haven't had a change request that couldn't be
accomodated, so the current report reflects what people wanted to have
(or at least what they thought they could get :).  I think if you start
with that things should be fine, and you can move on from there.  The
original layout as devised and coded by Skip Montanaro has served us
well.

-- 
KBK

From forsberg at efod.se  Wed Dec  6 22:34:30 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 06 Dec 2006 22:34:30 +0100
Subject: [Tracker-discuss] Test import
Message-ID: <87k614vhcp.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo!

If anyone stumbles by http://psf.upfronthosting.co.za/roundup/tracker
and starts to wonder where all the issues came from, they are the
result of a test import by the new importer code.

Unfortunately, it hit a bug which I'll have to fix on issue
1551/11883, and since it's nighty-nighty-time here, you'll have to
wait until later for the remaining issues.

This is just an initial test import of the new importer code, to let
you see some progress.

There's one thing to note about this import - it does _not_ take care
of the 'status' and 'resolution' fields, as the mapping between the
sf.net values and the values in this tracker need some more thought.

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFdzdmrJurFAusidkRApTtAJ9yd2qj6lx8Nz9P93E7EeKnp2SeKgCgjsJA
cLXG00uuxQh6IkDP8oUIGuA=
=RRj1
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Wed Dec  6 23:39:29 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 06 Dec 2006 22:39:29 +0000
Subject: [Tracker-discuss] Test import
In-Reply-To: <87k614vhcp.fsf@uterus.efod.se>
References: <87k614vhcp.fsf@uterus.efod.se>
Message-ID: <457746A1.2070107@gmx.net>

Erik Forsberg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Yo!
> 
> If anyone stumbles by http://psf.upfronthosting.co.za/roundup/tracker
> and starts to wonder where all the issues came from, they are the
> result of a test import by the new importer code.
> 
> Unfortunately, it hit a bug which I'll have to fix on issue
> 1551/11883, and since it's nighty-nighty-time here, you'll have to
> wait until later for the remaining issues.
> 
> This is just an initial test import of the new importer code, to let
> you see some progress.
> 
> There's one thing to note about this import - it does _not_ take care
> of the 'status' and 'resolution' fields, as the mapping between the
> sf.net values and the values in this tracker need some more thought.

I don't know if this is on your to-do list already, but selecting "Show
Unassigned" does not list the unassigned SF items since they are assigned
to "anonymous". The import should clear these fields.

cheers,
Georg

From pfdubois at gmail.com  Thu Dec  7 23:53:53 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 7 Dec 2006 14:53:53 -0800
Subject: [Tracker-discuss] Test import
In-Reply-To: <87k614vhcp.fsf@uterus.efod.se>
References: <87k614vhcp.fsf@uterus.efod.se>
Message-ID: <f74a6c2f0612071453l693ed05ap673bf736709dc671@mail.gmail.com>

Could we get a posting to the meta of the 'final' schema and
semantics, if it is ready? The discussion was extremely long and
involved. If schema.py / initial_data are telling the right story,
then I just need to know that and any semantic / transition stuff you
agreed on.

On 12/6/06, Erik Forsberg <forsberg at efod.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yo!
>
> If anyone stumbles by http://psf.upfronthosting.co.za/roundup/tracker
> and starts to wonder where all the issues came from, they are the
> result of a test import by the new importer code.
>
> Unfortunately, it hit a bug which I'll have to fix on issue
> 1551/11883, and since it's nighty-nighty-time here, you'll have to
> wait until later for the remaining issues.
>
> This is just an initial test import of the new importer code, to let
> you see some progress.
>
> There's one thing to note about this import - it does _not_ take care
> of the 'status' and 'resolution' fields, as the mapping between the
> sf.net values and the values in this tracker need some more thought.
>
> Cheers,
> \EF
> - --
> Erik Forsberg                 http://efod.se
> GPG/PGP Key: 1024D/0BAC89D9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFFdzdmrJurFAusidkRApTtAJ9yd2qj6lx8Nz9P93E7EeKnp2SeKgCgjsJA
> cLXG00uuxQh6IkDP8oUIGuA=
> =RRj1
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From forsberg at efod.se  Fri Dec  8 07:47:06 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Fri, 08 Dec 2006 07:47:06 +0100
Subject: [Tracker-discuss] Test import
In-Reply-To: <f74a6c2f0612071453l693ed05ap673bf736709dc671@mail.gmail.com>
	(Paul Dubois's message of "Thu, 7 Dec 2006 14:53:53 -0800")
References: <87k614vhcp.fsf@uterus.efod.se>
	<f74a6c2f0612071453l693ed05ap673bf736709dc671@mail.gmail.com>
Message-ID: <87wt52yjdh.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Paul Dubois" <pfdubois at gmail.com> writes:

> Could we get a posting to the meta of the 'final' schema and
> semantics, if it is ready? The discussion was extremely long and
> involved. If schema.py / initial_data are telling the right story,
> then I just need to know that and any semantic / transition stuff you
> agreed on.

I'd say that schema.py is final, but there's some work to do on
initial_data.py, mostly because the number of status/resolution
combinations in the sf.tracker (there's 34 different combinations in
use) hardly can be covered by the current list of combinations of
status/resolution values in initial_data.py.

I'm currently working on a proposal.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFeQpqrJurFAusidkRAvgyAKC99XG5qoHfWJ8X1W4D3spTyE0MdgCgsWal
D+m6iahqV/XIyGTfs90Tt8M=
=Hyo7
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sun Dec 10 00:25:49 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 10 Dec 2006 00:25:49 +0100
Subject: [Tracker-discuss] Category -> Component Merge?
Message-ID: <87y7pgejnm.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

The importer will map what sf.net calls Category into the Component
field in the new tracker. The current list of Categories from sf.net
looks like this:

      Library (Lib)
      Installation
      Python Library
      Performance
      Tests
      IDLE
      Threads
      Macintosh
      XML
      None
      Tkinter
      Demos and tools
      Windows
      Documentation
      Modules
      Core (C code)
      Extension Modules
      Demos and Tools
      Distutils
      Regular Expressions
      Type/class unification
      Parser/Compiler
      Distutils and setup.py
      Unicode
      Python Interpreter Core
      Build

If you (the python-dev people) want to, we could easily merge some of
them during import. For example "Library (Lib)" sounds like it could
be merged with "Python Library", but that's just a guess from my side.

Renaming the components can be easily done later using the Roundup web
GUI.

So, if you'd like some categories to end up as fewer components, speak
up now, or forever be silent :-).

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFe0X9rJurFAusidkRAm25AKC4PhNRlt0gQNZfbAiJF6p260rS6wCdFkyS
qK7bKIJQKdCLwuRIUSY4hOk=
=d4pZ
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sun Dec 10 00:30:39 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 10 Dec 2006 00:30:39 +0100
Subject: [Tracker-discuss] How to map "Group"?
Message-ID: <87u004ejfk.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I'm a bit puzzled when it comes to the sf.net "Group" field. Here's
the list of currently used values:

        Python 2.2.2
        Python 2.2.3
        Python 2.2.1
        Python 2.1.2
        Feature Request
        Python 2.1.1
        Irreproducible
        2.0.1 bugfix
        Trash
        AST
        Not a Bug
        Python 2.2.1 candidate
        None
        Python 2.2.x
        3rd Party
        Platform-specific
        Python 2.4
        Python 2.5
        Python 2.6
        Python 3000
        Python 2.2
        Python 2.3

What are these used for today? Should they be mapped to "the version
the bug was found in" in some cases? 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFe0cerJurFAusidkRAhZiAKCIvbF2oLGcyA5nXDUTGJFMVEXbgQCeNvpx
OW0PW0FuCvfkBRsLyzijcRk=
=s8Mp
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sun Dec 10 07:12:03 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Dec 2006 07:12:03 +0100
Subject: [Tracker-discuss] Category -> Component Merge?
In-Reply-To: <87y7pgejnm.fsf@uterus.efod.se>
References: <87y7pgejnm.fsf@uterus.efod.se>
Message-ID: <457BA533.70504@v.loewis.de>

Erik Forsberg schrieb:
> If you (the python-dev people) want to, we could easily merge some of
> them during import. For example "Library (Lib)" sounds like it could
> be merged with "Python Library", but that's just a guess from my side.

These duplicates originate from having different categories in different
trackers. Currently, for Bugs, we have

103173  Build
103200 	Demos and Tools
103199 	Distutils
103191 	Documentation
103170 	Extension Modules
103197 	IDLE
311937 	Installation
345870 	Macintosh
103168 	Parser/Compiler
854539 	Performance
103169 	Python Interpreter Core
103171 	Python Library
105081 	Regular Expressions
105083 	Threads
103198 	Tkinter
347131 	Type/class unification
105082 	Unicode
103174 	Windows
103810 	XML

For Patches, we have

310329  Build
310316 	Core (C code)
310317 	Demos and tools
310254 	Distutils and setup.py
310284 	Documentation
310331 	IDLE
310315 	Library (Lib)
345871 	Macintosh
310328 	Modules
310327 	Parser/Compiler
854540 	Performance
385534 	Tests
310332 	Tkinter
310330 	Windows
310395 	XML

and for Feature Requests, we have

379637  Build
379639 	Demos and Tools
379638 	Distutils
379640 	Documentation
379641 	Extension Modules
379642 	IDLE
379643 	Installation
379644 	Macintosh
379645 	Parser/Compiler
854541 	Performance
379646 	Python Interpreter Core
379647 	Python Library
379648 	Regular Expressions
379649 	Threads
379650 	Tkinter
379651 	Type/class unification
379652 	Unicode
379653 	Windows
379654 	XML

These lists are meant to be equal, but apparently aren't.

The following categories should be unified:

"Demos and Tools" and "Demos and tools"
(should be "Demos and Tools")
"Distutils" and "Distutils and setup.py"
(should be "Distutils", setup.py should really be
 classified into "Installation")
"Python Interpreter Core" and "Core (C code)"
(should be "Interpreter Core")
"Python Library" and "Library (Lib)"
(should be "Library (Lib)")
"Extension Modules" and "Modules"
(should be "Extension Modules")

HTH,
Martin



From martin at v.loewis.de  Sun Dec 10 07:18:36 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Dec 2006 07:18:36 +0100
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87u004ejfk.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se>
Message-ID: <457BA6BC.7010202@v.loewis.de>

Erik Forsberg schrieb:
>         Python 2.2.2
>         Python 2.2.3
>         Python 2.2.1
>         Python 2.1.2
>         Feature Request
>         Python 2.1.1
>         Irreproducible
>         2.0.1 bugfix
>         Trash
>         AST
>         Not a Bug
>         Python 2.2.1 candidate
>         None
>         Python 2.2.x
>         3rd Party
>         Platform-specific
>         Python 2.4
>         Python 2.5
>         Python 2.6
>         Python 3000
>         Python 2.2
>         Python 2.3
> 
> What are these used for today? Should they be mapped to "the version
> the bug was found in" in some cases? 

Definitely, yes. "* candidate" and "Python 3000" are different: they
refer to future versions.

For those that aren't versions, we have this usage:

"Feature Request": this should really have been moved to the
Feature Requests tracker instead.

"3rd Party": this is not a bug in Python, but in some other software
(often the operating system)

"Irreproducable", "Not a Bug": This is part of the resolution.

"AST": not sure where this is; that's really a category.

Regards,
Martin

From forsberg at efod.se  Sun Dec 10 11:38:08 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 10 Dec 2006 11:38:08 +0100
Subject: [Tracker-discuss] Category -> Component Merge?
In-Reply-To: <457BA533.70504@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6wi?=
	=?iso-8859-1?Q?s's?= message of "Sun, 10 Dec 2006 07:12:03 +0100")
References: <87y7pgejnm.fsf@uterus.efod.se> <457BA533.70504@v.loewis.de>
Message-ID: <87d56sdoj3.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:


> The following categories should be unified:
>
> "Demos and Tools" and "Demos and tools"
> (should be "Demos and Tools")
> "Distutils" and "Distutils and setup.py"
> (should be "Distutils", setup.py should really be
>  classified into "Installation")
> "Python Interpreter Core" and "Core (C code)"
> (should be "Interpreter Core")
> "Python Library" and "Library (Lib)"
> (should be "Library (Lib)")
> "Extension Modules" and "Modules"
> (should be "Extension Modules")
>
> HTH,

Very much, thankyou. A merge as specified above has been implemented
in the importer.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFe+OPrJurFAusidkRAhD9AJwJHXGkfGznbIh3dsM2h0pOnOASfACgyEQ4
iQjH3Hh7HnEZPRzCTmiaVjM=
=LdwF
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sun Dec 10 12:17:46 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 10 Dec 2006 12:17:46 +0100
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <457BA6BC.7010202@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 10 Dec 2006 07:18:36 +0100")
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
Message-ID: <87zm9wc84l.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Erik Forsberg schrieb:
>>         Python 2.2.2
>>         Python 2.2.3
>>         Python 2.2.1
>>         Python 2.1.2
>>         Feature Request
>>         Python 2.1.1
>>         Irreproducible
>>         2.0.1 bugfix
>>         Trash
>>         AST
>>         Not a Bug
>>         Python 2.2.1 candidate
>>         None
>>         Python 2.2.x
>>         3rd Party
>>         Platform-specific
>>         Python 2.4
>>         Python 2.5
>>         Python 2.6
>>         Python 3000
>>         Python 2.2
>>         Python 2.3
>> 
>> What are these used for today? Should they be mapped to "the version
>> the bug was found in" in some cases? 
>
> Definitely, yes. 

Should be no trouble to handle. 

>"* candidate" and "Python 3000" are different: they
> refer to future versions.

Hmm.. this is where a milestone or a keyword field would have been
useful. I remember that we discussed this and came to the conclusion
that a "meta bug" should be added, for example for py3k, then adding
dependencies on other bugs for this bug.

I'm not sure that's userfriendly, though. Right now, I'm tempted to
add a keyword field as a multilink to a defined set of keywords, where
"py3k" would be among them.

Better ideas? 

> For those that aren't versions, we have this usage:
>
> "Feature Request": this should really have been moved to the
> Feature Requests tracker instead.

OK. I'll educate the importer to set type = rfe for these bugs.

> "3rd Party": this is not a bug in Python, but in some other software
> (often the operating system)

I think I'll simply handle that by adding a version enumerator, "3rd
party".

>
> "Irreproducable", "Not a Bug": This is part of the resolution.

Hmm.. OK. Sounds like unneeded information - "Works for me" should
cover these cases (and checking out some sample bugs, that's the
resolution they already have). 

>
> "AST": not sure where this is; that's really a category.

I find 28 bugs with Group set to "AST", all of them closed. Checking
out some of them, they seem to sit on the "Parse/Compiler"
component. This leads me to the conclusion that this group value can
be ignored.

My proposal in summary:

* Group == "Python X" will be translated into version.
* Group == "Feature Request" will make sure that bug gets type=rfe.
* Group == AST will be ignored.
* Group == Irreproducable will be ignored.
* Group == Not a Bug will be ignored.
* Group == 3rd party will be translated into the version "3rd party"

I need input on how to handle "* candidate" and "Python 3000", but at
least the above gives me something to work on.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFe+zarJurFAusidkRAtpqAJ0VKjiyWXegXQnU4hFU3di4Oe5jVACfYI38
hAlWwZBBACtbCm05Mi/rdak=
=y0Hy
-----END PGP SIGNATURE-----

From amk at amk.ca  Sun Dec 10 16:16:59 2006
From: amk at amk.ca (A.M. Kuchling)
Date: Sun, 10 Dec 2006 10:16:59 -0500
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87zm9wc84l.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
	<87zm9wc84l.fsf@uterus.efod.se>
Message-ID: <20061210151659.GA1501@Andrew-iBook2.local>

On Sun, Dec 10, 2006 at 12:17:46PM +0100, Erik Forsberg wrote:
> I find 28 bugs with Group set to "AST", all of them closed. Checking
> out some of them, they seem to sit on the "Parse/Compiler"
> component. This leads me to the conclusion that this group value can
> be ignored.

For a while there was a Python branch for changing the parser to use
ASTs instead of a concrete parse tree; these bugs must have been filed
against this branch.  This branch has since been merged to the trunk
and is no longer being used, so the group is probably no longer useful.

--amk

From brett at python.org  Sun Dec 10 21:13:56 2006
From: brett at python.org (Brett Cannon)
Date: Sun, 10 Dec 2006 12:13:56 -0800
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <20061210151659.GA1501@Andrew-iBook2.local>
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
	<87zm9wc84l.fsf@uterus.efod.se>
	<20061210151659.GA1501@Andrew-iBook2.local>
Message-ID: <bbaeab100612101213h13289ab6q8e2c4753bb085ece@mail.gmail.com>

On 12/10/06, A.M. Kuchling <amk at amk.ca> wrote:
>
> On Sun, Dec 10, 2006 at 12:17:46PM +0100, Erik Forsberg wrote:
> > I find 28 bugs with Group set to "AST", all of them closed. Checking
> > out some of them, they seem to sit on the "Parse/Compiler"
> > component. This leads me to the conclusion that this group value can
> > be ignored.
>
> For a while there was a Python branch for changing the parser to use
> ASTs instead of a concrete parse tree; these bugs must have been filed
> against this branch.  This branch has since been merged to the trunk
> and is no longer being used, so the group is probably no longer useful.


This is exactly what it was used for and thus is no longer used.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061210/423d6290/attachment.htm 

From martin at v.loewis.de  Sun Dec 10 23:11:54 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 10 Dec 2006 23:11:54 +0100
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87zm9wc84l.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
	<87zm9wc84l.fsf@uterus.efod.se>
Message-ID: <457C862A.3040208@v.loewis.de>

Erik Forsberg schrieb:
> Hmm.. this is where a milestone or a keyword field would have been
> useful. I remember that we discussed this and came to the conclusion
> that a "meta bug" should be added, for example for py3k, then adding
> dependencies on other bugs for this bug.
> 
> I'm not sure that's userfriendly, though. Right now, I'm tempted to
> add a keyword field as a multilink to a defined set of keywords, where
> "py3k" would be among them.
> 
> Better ideas? 

We definitely need a way to filter Py3k issues. Dropping the *candidate
descriptions should be fine (i.e. make 2.2.1 candidate a description
for "Python 2.2").

>> "Irreproducable", "Not a Bug": This is part of the resolution.
> 
> Hmm.. OK. Sounds like unneeded information - "Works for me" should
> cover these cases (and checking out some sample bugs, that's the
> resolution they already have). 

Sounds fine.

>> "AST": not sure where this is; that's really a category.
> 
> I find 28 bugs with Group set to "AST", all of them closed. Checking
> out some of them, they seem to sit on the "Parse/Compiler"
> component. This leads me to the conclusion that this group value can
> be ignored.

Ok, AST is then "Abstract Syntax Tree". Mapping them to "Interpreter
Core" would be appropriate (if they aren't already mapped so).

> I need input on how to handle "* candidate" and "Python 3000", but at
> least the above gives me something to work on.

Not sure whether that's appropriate, but I think making "py3k" a
"type" might be one solution. At some point, people said they wanted
to have a separate tracker for it entirely.

Adding a Py3k boolean flag would be another solution.

Regards,
Martin

From pfdubois at gmail.com  Mon Dec 11 00:50:22 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 10 Dec 2006 15:50:22 -0800
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
Message-ID: <f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>

It lives. I managed to work around the problem.

If you are seeing html in your mailer and want to see the 'text' form of
this message view the email source; of course this is producible separately
so don't panic if you are in love with the 'traditional' format.

I haven't checked that the 'answers' are right on this tracker, although
they are on another one I have.

---------- Forwarded message ----------
From: Tracker <roundup-admin at psf.upfronthosting.co.za>
Date: Dec 10, 2006 5:44 PM
Subject: Summary of Tracker Issues
To: pfdubois at gmail.com

ACTIVITY SUMMARY ( 4 December 2006 - 11 December 2006) Tracker at
http://psf.upfronthosting.co.za/roundup/tracker/

To view or respond to any of the issues listed below, simply click on the
issue ID. Do *not* respond to this message.

 1605 open (+15) / 8292 closed ( +7) / 9897 total (+22)

Open Issues Statistics STATUS NumberChange open 1605 +15 pending 0 +0

Issues Created Or Reopened (22)  ID  Title  Status  Date  Action  By
1608267 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608267>
Makefile fix   4 December 2006 created hdiwan650
1608579 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608579>  Race
condition in os.makedirs  CLOSED  4 December 2006  created  jbowes
1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758>
Fix pickle doc typo "date", should be "data" CLOSED 4 December 2006
created grahamh
1608805 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608805>
Py_FileSystemDefaultEncoding can be non-canonical   4 December 2006
created sdeibel
1608818 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608818>
Sloppy error checking in listdir() for Posix   4 December 2006 created
sdeibel
1608921 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608921>
PyThread_release_lock with pthreads munges errno   5 December 2006
created sdeibel
1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108>
Docstring support for ctypesgen CLOSED 5 December 2006 created
chmod007
1609282 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609282> #1603424
subprocess.py wrongly claims 2.2 compatibility.     5 December 2006  created
 racarr   1609407<http://psf.upfronthosting.co.za/roundup/tracker/issue1609407>
traceback on exit if syslog handler fails to initialize   5 December
2006 created katzj
1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958>
tarfile archive paths limited to less than 100 chars CLOSED 6 December
2006 created frehberg
1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
tarfile.py: Fix for bug #1609958  CLOSED  6 December 2006  created gustaebel
1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485>  GUI
for Python 2.3, 2.4, and 2.5 is very sluggish  CLOSED  6 December 2006
created g4rlik
1610575 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610575>  C99
_Bool support for struct     7 December 2006  created  chmod007
1610654<http://psf.upfronthosting.co.za/roundup/tracker/issue1610654>
cgi.py multipart/form-data     7 December 2006  created  teyc
1610795<http://psf.upfronthosting.co.za/roundup/tracker/issue1610795>
BSD version of
ctypes.util.find_library     7 December 2006  created  mkam
1611131<http://psf.upfronthosting.co.za/roundup/tracker/issue1611131>
\b in unicode regex gives strange results   7 December 2006 created
akaihola
1611154 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611154>
os.path.exists("file/") failure on Solaris 9     7 December 2006
created eggert
1611753 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611753>
can't pickle NAN's in binary mode CLOSED 8 December 2006 created
wayne606
1611944 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611944>
sndhdr.what() does not recognize wav file     9 December 2006  created
klankschap
1612012 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612012>
builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT   9 December 2006
created anthonybaxter
1612190 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612190>
Py_DEBUG   9 December 2006 created nitrogenycs
1612262 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612262>
Class Browser doesn't show internal classes   9 December 2006 created
taleinat
Issues Now Closed (15)  Issue  Title (Date)  By  Duration
858318<http://psf.upfronthosting.co.za/roundup/tracker/issue858318>
modsupport does not use va_copy when available (11 December 2003)
sf-robot 1094 days
1223238 <http://psf.upfronthosting.co.za/roundup/tracker/issue1223238>  race
in os.makedirs() (18 June 2005)  gbrandl  538 days
1239890<http://psf.upfronthosting.co.za/roundup/tracker/issue1239890>
Prevent race condition in
os.makedirs (17 July 2005)  gbrandl  509 days
1314067<http://psf.upfronthosting.co.za/roundup/tracker/issue1314067>
os.makedirs - robust against partial path (5 October 2005)  gbrandl  429
days   1576657<http://psf.upfronthosting.co.za/roundup/tracker/issue1576657>
dict keyerror formatting and tuples (13 October 2006) rhettinger 56
days
1577756 <http://psf.upfronthosting.co.za/roundup/tracker/issue1577756>
whitespace in `svnversion .` (15 October 2006) gbrandl 54 days
1579931 <http://psf.upfronthosting.co.za/roundup/tracker/issue1579931>  not
configured for tk (18 October 2006)  carlwenrich  46 days
1592899<http://psf.upfronthosting.co.za/roundup/tracker/issue1592899>
"".translate() docs should mention
string.maketrans() (8 November 2006)  gbrandl  28 days
1608579<http://psf.upfronthosting.co.za/roundup/tracker/issue1608579>
Race condition in
os.makedirs (4 December 2006)  gbrandl  4 days
1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758>
Fix pickle doc typo "date", should be "data" (4 December 2006) quiver
0 days
1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108>
Docstring support for ctypesgen (5 December 2006) theller 0 days
1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958>
tarfile archive paths limited to less than 100 chars (6 December 2006)
gbrandl 0 days
1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
tarfile.py: Fix for bug #1609958 (6 December 2006)  gbrandl  0 days
1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485>  GUI
for Python 2.3, 2.4, and 2.5 is very sluggish (6 December 2006)  g4rlik  2
days   1611753<http://psf.upfronthosting.co.za/roundup/tracker/issue1611753>
can't pickle NAN's in binary mode (8 December 2006) mwh 0 days
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061210/3ff971eb/attachment.html 

From nnorwitz at gmail.com  Mon Dec 11 01:09:04 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 10 Dec 2006 16:09:04 -0800
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
Message-ID: <ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>

I like it!  The links help.

Of course, I'd like a few small changes though. :-)  I don't have a problem
with html since I use gmail.  I don't know if we have to keep supporting
text or not.  If we do, I would prefer them formatted somewhat differently.

How about dropping the id column and making the title the link?  It's
basically redundant info.  (If there's a text version, it should probably
maintain the id.)  How about using a shorter version for the date.  My
preferences are:  2006-12-10 (YYYY-MM-DD) or 10-Dec-2006.

Did you mean to keep the summary line of all opened and closed, but only put
the open and pending counts in the table?  I'd prefer to see only one
version.  The table format probably makes more sense, but I don't much care
either way.

The action/status is mostly redundant.  I'm not sure how I'd like it to be.
1) Some ideas are combining the columns, so you see:  created, created &
closed, re-opened, etc. 2) Drop the action column and just keep the status
column which would show:  new, re-opened, closed.  Even a single letter
would be fine with me.  I'd rather have the titles fit on a single line if
possible.

I'd decrease the borders.  I think a mono space font might be nicer (not
sure though).

n
--
On 12/10/06, Paul Dubois <pfdubois at gmail.com> wrote:
>
> It lives. I managed to work around the problem.
>
> If you are seeing html in your mailer and want to see the 'text' form of
> this message view the email source; of course this is producible separately
> so don't panic if you are in love with the 'traditional' format.
>
> I haven't checked that the 'answers' are right on this tracker, although
> they are on another one I have.
>
> ---------- Forwarded message ----------
> From: Tracker <roundup-admin at psf.upfronthosting.co.za>
> Date: Dec 10, 2006 5:44 PM
> Subject: Summary of Tracker Issues
> To: pfdubois at gmail.com
>
> ACTIVITY SUMMARY ( 4 December 2006 - 11 December 2006) Tracker at
> http://psf.upfronthosting.co.za/roundup/tracker/
>
> To view or respond to any of the issues listed below, simply click on the
> issue ID. Do *not* respond to this message.
>
>  1605 open (+15) / 8292 closed ( +7) / 9897 total (+22)
>
> Open Issues Statistics STATUS NumberChange open 1605 +15 pending 0 +0
>
> Issues Created Or Reopened (22)  ID  Title  Status  Date  Action  By
> 1608267 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608267> Makefile fix   4 December 2006 created hdiwan650
> 1608579 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608579> Race condition in
> os.makedirs  CLOSED  4 December 2006  created  jbowes   1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758> Fix pickle doc typo "date", should be "data" CLOSED 4 December 2006 created grahamh
> 1608805 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608805> Py_FileSystemDefaultEncoding can be non-canonical   4 December 2006 created sdeibel
> 1608818 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608818> Sloppy error checking in listdir() for Posix   4 December 2006 created sdeibel
> 1608921 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608921> PyThread_release_lock with pthreads munges errno   5 December 2006 created sdeibel
> 1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108> Docstring support for ctypesgen CLOSED 5 December 2006 created chmod007
> 1609282 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609282> #1603424
> subprocess.py wrongly claims 2.2 compatibility.     5 December 2006 created racarr
> 1609407 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609407> traceback on exit if syslog handler fails to initialize   5 December 2006 created katzj
> 1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958> tarfile archive paths limited to less than 100 chars CLOSED 6 December 2006 created frehberg
> 1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
> tarfile.py: Fix for bug #1609958  CLOSED  6 December 2006  created gustaebel
> 1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485> GUI for Python
> 2.3, 2.4, and 2.5 is very sluggish  CLOSED  6 December 2006  created g4rlik
> 1610575 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610575> C99 _Bool support for struct   7 December 2006 created chmod007
> 1610654 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610654>
> cgi.py multipart/form-data     7 December 2006  created  teyc   1610795<http://psf.upfronthosting.co.za/roundup/tracker/issue1610795> BSD version of
> ctypes.util.find_library     7 December 2006  created  mkam   1611131<http://psf.upfronthosting.co.za/roundup/tracker/issue1611131> \b in unicode regex gives strange results   7 December 2006 created akaihola
> 1611154 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611154>
> os.path.exists("file/") failure on Solaris 9     7 December 2006  created eggert
> 1611753 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611753> can't pickle NAN's in binary mode CLOSED 8 December 2006 created wayne606
> 1611944 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611944>
> sndhdr.what() does not recognize wav file     9 December 2006  created klankschap
> 1612012 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612012> builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT   9 December 2006 created anthonybaxter
> 1612190 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612190> Py_DEBUG   9 December 2006 created nitrogenycs
> 1612262 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612262> Class Browser doesn't show internal classes   9 December 2006 created taleinat
> Issues Now Closed (15)  Issue  Title (Date)  By  Duration   858318<http://psf.upfronthosting.co.za/roundup/tracker/issue858318> modsupport does not use va_copy when available (11 December 2003) sf-robot 1094 days
> 1223238 <http://psf.upfronthosting.co.za/roundup/tracker/issue1223238> race in
> os.makedirs() (18 June 2005)  gbrandl  538 days   1239890<http://psf.upfronthosting.co.za/roundup/tracker/issue1239890> Prevent race condition in
> os.makedirs (17 July 2005)  gbrandl  509 days   1314067<http://psf.upfronthosting.co.za/roundup/tracker/issue1314067>
> os.makedirs - robust against partial path (5 October 2005)  gbrandl  429
> days   1576657<http://psf.upfronthosting.co.za/roundup/tracker/issue1576657> dict keyerror formatting and tuples (13 October 2006) rhettinger 56 days
> 1577756 <http://psf.upfronthosting.co.za/roundup/tracker/issue1577756> whitespace in `svnversion .` (15 October 2006) gbrandl 54 days
> 1579931 <http://psf.upfronthosting.co.za/roundup/tracker/issue1579931> not configured for tk (18 October 2006) carlwenrich 46 days
> 1592899 <http://psf.upfronthosting.co.za/roundup/tracker/issue1592899> "".translate() docs should mention
> string.maketrans() (8 November 2006)  gbrandl  28 days   1608579<http://psf.upfronthosting.co.za/roundup/tracker/issue1608579> Race condition in
> os.makedirs (4 December 2006)  gbrandl  4 days   1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758> Fix pickle doc typo "date", should be "data" (4 December 2006) quiver 0 days
> 1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108> Docstring support for ctypesgen (5 December 2006) theller 0 days
> 1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958> tarfile archive paths limited to less than 100 chars (6 December 2006) gbrandl 0 days
> 1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
> tarfile.py: Fix for bug #1609958 (6 December 2006)  gbrandl  0 days
> 1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485> GUI for Python
> 2.3, 2.4, and 2.5 is very sluggish (6 December 2006)  g4rlik  2 days
> 1611753 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611753> can't pickle NAN's in binary mode (8 December 2006) mwh 0 days
> _______________________________________________
> 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/20061210/102d325a/attachment.htm 

From nnorwitz at gmail.com  Mon Dec 11 01:15:09 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 10 Dec 2006 16:15:09 -0800
Subject: [Tracker-discuss] Fwd: [Python-checkins] r52987 -
	tracker/instances/python-dev/initial_data.py
In-Reply-To: <20061210110130.D134C1E402B@bag.python.org>
References: <20061210110130.D134C1E402B@bag.python.org>
Message-ID: <ee2a432c0612101615g4044c36dmfef7a42243201398@mail.gmail.com>

Eric, I think I'd get rid of some of these:

+component.create(name="Interpreter Core", order="8")

[...]

+component.create(name="Parser/Compiler", order="11")
+component.create(name="Performance", order="12")
+component.create(name="Threads", order="15")
+component.create(name="Type/class unification", order="17")

   These four can be mappend to Interpreter Core.  I don't think there
are many open bugs in the first 3.  For type/class unification, I
don't think we use it at all any more and I don't think it matters for
the old bugs.

I forget if Martin had suggested mapping Distutils to installation or not?

n

From pfdubois at gmail.com  Mon Dec 11 01:16:41 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 10 Dec 2006 16:16:41 -0800
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
Message-ID: <f74a6c2f0612101616i40504efeja9d9d1b9acb7de41@mail.gmail.com>

Thanks for the ideas. I was ordered to KEEP IT THE WAY IT WAS. As I
mentioned, the way it was is there in your message if you view it as plain
text. (it is a multipart message)

The format of the tables is highly reconfigurable.

In the summary, the extra table is a breakdown of the open and pending
issues by status, since both pending and open are considered 'open' in the
summary. I suppose the problem is that if you call open issues both open and
pending then the use of the word open becomes ambiguous, as it is here. If
this extra table is not wanted it is easy not to do it. As you'll see in the
report for the meta, where there are more statuses, it can be more
interesting.

On 12/10/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
>
> I like it!  The links help.
>
> Of course, I'd like a few small changes though. :-)  I don't have a
> problem with html since I use gmail.  I don't know if we have to keep
> supporting text or not.  If we do, I would prefer them formatted somewhat
> differently.
>
> How about dropping the id column and making the title the link?  It's
> basically redundant info.  (If there's a text version, it should probably
> maintain the id.)  How about using a shorter version for the date.  My
> preferences are:  2006-12-10 (YYYY-MM-DD) or 10-Dec-2006.
>
> Did you mean to keep the summary line of all opened and closed, but only
> put the open and pending counts in the table?  I'd prefer to see only one
> version.  The table format probably makes more sense, but I don't much care
> either way.
>
> The action/status is mostly redundant.  I'm not sure how I'd like it to
> be.  1) Some ideas are combining the columns, so you see:  created, created
> & closed, re-opened, etc. 2) Drop the action column and just keep the status
> column which would show:  new, re-opened, closed.  Even a single letter
> would be fine with me.  I'd rather have the titles fit on a single line if
> possible.
>
> I'd decrease the borders.  I think a mono space font might be nicer (not
> sure though).
>
> n
> --
> On 12/10/06, Paul Dubois <pfdubois at gmail.com> wrote:
>
> > It lives. I managed to work around the problem.
> >
> > If you are seeing html in your mailer and want to see the 'text' form of
> > this message view the email source; of course this is producible separately
> > so don't panic if you are in love with the 'traditional' format.
> >
> > I haven't checked that the 'answers' are right on this tracker, although
> > they are on another one I have.
> >
> > ---------- Forwarded message ----------
> > From: Tracker <roundup-admin at psf.upfronthosting.co.za>
> > Date: Dec 10, 2006 5:44 PM
> > Subject: Summary of Tracker Issues
> > To: pfdubois at gmail.com
> >
> > ACTIVITY SUMMARY ( 4 December 2006 - 11 December 2006) Tracker at
> > http://psf.upfronthosting.co.za/roundup/tracker/
> >
> > To view or respond to any of the issues listed below, simply click on
> > the issue ID. Do *not* respond to this message.
> >
> >  1605 open (+15) / 8292 closed ( +7) / 9897 total (+22)
> >
> > Open Issues Statistics STATUS NumberChange open 1605 +15 pending 0 +0
> >
> > Issues Created Or Reopened (22)  ID  Title  Status  Date  Action  By
> > 1608267 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608267> Makefile fix   4 December 2006 created hdiwan650
> > 1608579 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608579> Race condition in
> > os.makedirs  CLOSED  4 December 2006  created  jbowes   1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758> Fix pickle doc typo "date", should be "data" CLOSED 4 December 2006 created grahamh
> > 1608805 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608805> Py_FileSystemDefaultEncoding can be non-canonical   4 December 2006 created sdeibel
> > 1608818 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608818> Sloppy error checking in listdir() for Posix   4 December 2006 created sdeibel
> > 1608921 <http://psf.upfronthosting.co.za/roundup/tracker/issue1608921> PyThread_release_lock with pthreads munges errno   5 December 2006 created sdeibel
> > 1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108> Docstring support for ctypesgen CLOSED 5 December 2006 created chmod007
> > 1609282 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609282> #1603424
> > subprocess.py wrongly claims 2.2 compatibility.     5 December 2006 created racarr
> > 1609407 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609407> traceback on exit if syslog handler fails to initialize   5 December 2006 created katzj
> > 1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958> tarfile archive paths limited to less than 100 chars CLOSED 6 December 2006 created frehberg
> > 1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
> > tarfile.py: Fix for bug #1609958  CLOSED  6 December 2006  created gustaebel
> > 1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485> GUI for Python
> > 2.3, 2.4, and 2.5 is very sluggish  CLOSED  6 December 2006  created g4rlik
> > 1610575 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610575> C99 _Bool support for struct   7 December 2006 created chmod007
> > 1610654 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610654>
> > cgi.py multipart/form-data     7 December 2006  created  teyc   1610795<http://psf.upfronthosting.co.za/roundup/tracker/issue1610795> BSD version of
> > ctypes.util.find_library     7 December 2006  created  mkam   1611131<http://psf.upfronthosting.co.za/roundup/tracker/issue1611131> \b in unicode regex gives strange results   7 December 2006 created akaihola
> > 1611154 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611154>
> > os.path.exists("file/") failure on Solaris 9     7 December 2006 created eggert
> > 1611753 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611753> can't pickle NAN's in binary mode CLOSED 8 December 2006 created wayne606
> > 1611944 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611944>
> > sndhdr.what() does not recognize wav file     9 December 2006  created klankschap
> > 1612012 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612012> builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT   9 December 2006 created anthonybaxter
> > 1612190 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612190> Py_DEBUG   9 December 2006 created nitrogenycs
> > 1612262 <http://psf.upfronthosting.co.za/roundup/tracker/issue1612262> Class Browser doesn't show internal classes   9 December 2006 created taleinat
> >  Issues Now Closed (15)  Issue  Title (Date)  By  Duration   858318<http://psf.upfronthosting.co.za/roundup/tracker/issue858318> modsupport does not use va_copy when available (11 December 2003) sf-robot 1094 days
> > 1223238 <http://psf.upfronthosting.co.za/roundup/tracker/issue1223238> race in
> > os.makedirs() (18 June 2005)  gbrandl  538 days   1239890<http://psf.upfronthosting.co.za/roundup/tracker/issue1239890> Prevent race condition in
> > os.makedirs (17 July 2005)  gbrandl  509 days   1314067<http://psf.upfronthosting.co.za/roundup/tracker/issue1314067>
> > os.makedirs - robust against partial path (5 October 2005)  gbrandl  429
> > days   1576657<http://psf.upfronthosting.co.za/roundup/tracker/issue1576657> dict keyerror formatting and tuples (13 October 2006) rhettinger 56 days
> > 1577756 <http://psf.upfronthosting.co.za/roundup/tracker/issue1577756> whitespace in `svnversion .` (15 October 2006) gbrandl 54 days
> > 1579931 <http://psf.upfronthosting.co.za/roundup/tracker/issue1579931> not configured for tk (18 October 2006) carlwenrich 46 days
> > 1592899 <http://psf.upfronthosting.co.za/roundup/tracker/issue1592899> "".translate() docs should mention
> > string.maketrans() (8 November 2006)  gbrandl  28 days   1608579<http://psf.upfronthosting.co.za/roundup/tracker/issue1608579> Race condition in
> > os.makedirs (4 December 2006)  gbrandl  4 days   1608758<http://psf.upfronthosting.co.za/roundup/tracker/issue1608758> Fix pickle doc typo "date", should be "data" (4 December 2006) quiver 0 days
> > 1609108 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609108> Docstring support for ctypesgen (5 December 2006) theller 0 days
> > 1609958 <http://psf.upfronthosting.co.za/roundup/tracker/issue1609958> tarfile archive paths limited to less than 100 chars (6 December 2006) gbrandl 0 days
> > 1610437 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610437>
> > tarfile.py: Fix for bug #1609958 (6 December 2006)  gbrandl  0 days
> > 1610485 <http://psf.upfronthosting.co.za/roundup/tracker/issue1610485> GUI for Python
> > 2.3, 2.4, and 2.5 is very sluggish (6 December 2006)  g4rlik  2 days
> > 1611753 <http://psf.upfronthosting.co.za/roundup/tracker/issue1611753> can't pickle NAN's in binary mode (8 December 2006) mwh 0 days
> > _______________________________________________
> > 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/20061210/97139556/attachment.html 

From martin at v.loewis.de  Mon Dec 11 04:35:21 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Dec 2006 04:35:21 +0100
Subject: [Tracker-discuss] Fwd: [Python-checkins] r52987
	-	tracker/instances/python-dev/initial_data.py
In-Reply-To: <ee2a432c0612101615g4044c36dmfef7a42243201398@mail.gmail.com>
References: <20061210110130.D134C1E402B@bag.python.org>
	<ee2a432c0612101615g4044c36dmfef7a42243201398@mail.gmail.com>
Message-ID: <457CD1F9.2020700@v.loewis.de>

Neal Norwitz schrieb:
> I forget if Martin had suggested mapping Distutils to installation or not?

No; in one of the trackers, it's "Distutils and setup.py", and I think
problems with setup.py should be recorded as "Installation". IMO,
"Distutils" and "Installation" should be separate components
(although "Installation" and "Build" may be merged into one).

Regards,
Martin

From pfdubois at gmail.com  Mon Dec 11 06:34:58 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 10 Dec 2006 21:34:58 -0800
Subject: [Tracker-discuss] a summary link?
Message-ID: <f74a6c2f0612102134ye0f6aen68275555976867bd@mail.gmail.com>

Hey, you're a bunch of smart guys -- help me figure this out.

Suppose we want to put a link in the page.html file that says "Weekly
Summary" or "Monthly Summary" or "Tracker Stats" or the like, and it
executes my summary program or a simple version of it and displays the
html result or emails it to the user. Although I don't have a lot of
experience with CGI I think I could figure that out but of course we
aren't doing that. The program would have to execute on the server
machine but since it isn't instantaneous you don't want the Roundup
server involved.

Anyway, I'm not even saying I think this is a good idea, it just got
me to thinking about what one could do from the roundup home page.

I wish this project required some numerical programming so I wouldn't
always be the stupidest one. (:->

Paul

From forsberg at efod.se  Mon Dec 11 10:35:47 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 11 Dec 2006 10:35:47 +0100
Subject: [Tracker-discuss] a summary link?
In-Reply-To: <f74a6c2f0612102134ye0f6aen68275555976867bd@mail.gmail.com>
References: <f74a6c2f0612102134ye0f6aen68275555976867bd@mail.gmail.com>
Message-ID: <200612111035.47350.forsberg@efod.se>

m?ndag 11 december 2006 06:34 skrev Paul Dubois:
> Hey, you're a bunch of smart guys -- help me figure this out.
>
> Suppose we want to put a link in the page.html file that says "Weekly
> Summary" or "Monthly Summary" or "Tracker Stats" or the like, and it
> executes my summary program or a simple version of it and displays the
> html result or emails it to the user. Although I don't have a lot of
> experience with CGI I think I could figure that out but of course we
> aren't doing that. The program would have to execute on the server
> machine but since it isn't instantaneous you don't want the Roundup
> server involved.

You could implement this as an extra view for the issue class. That would make 
it run inside roundup, which should be able to do several things 
simultaneously. 

The page would then have access to the roundup database just as any other page 
template. 

You could do this by creating a html/issue.weeklyreport.html, and the url 
would be something like 
http://psf.upfronthosting.co.za/trackers/tracker/issue?@template=weeklyreport.

You would probably want to add something in extensions/ as well, to avoid 
having to do too much programming in TAL.

At least, I think you can do the above, I haven't really tested it.

>
> I wish this project required some numerical programming so I wouldn't
> always be the stupidest one. (:->

All help with this project is highly appreciated! Keep asking questions on how 
to do things, and we'll try to answer!

(And trust me, if it comes to numerical programming, I will definitely be the 
most stupid one! :)  )

\Ef
-- 
http://efod.se/

From forsberg at efod.se  Mon Dec 11 12:21:51 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 11 Dec 2006 12:21:51 +0100
Subject: [Tracker-discuss] Priorities in the meta tracker
Message-ID: <200612111221.51839.forsberg@efod.se>

Yo!

(Bah! Managed to send this to roundup-admin at psf instead of to tracker-discuss. 
Stupid kmail (which I use at work). Gnus much better is!)

When I've been fiddling around with the issues in the meta tracker, I've set 
priorities as follows:

urgent: Like bug, but extra, uhm, "urgent" :-)

bug: Issues that we need to deal with before going live with the tracker.

feature: issues that deals with things that would be nice to have before going      
live, but which are not showstoppers.

wish: issues that would be nice to have, sometime.

It makes for a nice way to list bugs that need to be done ASAP, so if we could 
agree on using the above meanings for the priorites, that would be nice.

Cheers,
\EF
-- 
http://efod.se/

From forsberg at efod.se  Mon Dec 11 16:20:14 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 11 Dec 2006 16:20:14 +0100
Subject: [Tracker-discuss] Fwd: [Python-checkins] r52987 -
	tracker/instances/python-dev/initial_data.py
In-Reply-To: <ee2a432c0612101615g4044c36dmfef7a42243201398@mail.gmail.com>
	(Neal Norwitz's message of "Sun, 10 Dec 2006 16:15:09 -0800")
References: <20061210110130.D134C1E402B@bag.python.org>
	<ee2a432c0612101615g4044c36dmfef7a42243201398@mail.gmail.com>
Message-ID: <87fybmsbm9.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Neal Norwitz" <nnorwitz at gmail.com> writes:

> Eric, I think I'd get rid of some of these:
>
> +component.create(name="Interpreter Core", order="8")
>
> [...]
>
> +component.create(name="Parser/Compiler", order="11")
> +component.create(name="Performance", order="12")
> +component.create(name="Threads", order="15")
> +component.create(name="Type/class unification", order="17")
>
>    These four can be mappend to Interpreter Core.  I don't think there
> are many open bugs in the first 3.  For type/class unification, I
> don't think we use it at all any more and I don't think it matters for
> the old bugs.

This has been implemented in the importer. 

> I forget if Martin had suggested mapping Distutils to installation or not?

There has been posts on this, but I have not seen any definitive
conclusion on which components should be merged. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFfXcurJurFAusidkRAm2GAJwIZnvkGj72HFPGbGFaD9s0jZeLOQCggfFL
CAv1nPhiK0IdHanE9CSzYyg=
=DgWp
-----END PGP SIGNATURE-----

From roundup-admin at psf.upfronthosting.co.za  Mon Dec 11 03:02:53 2006
From: roundup-admin at psf.upfronthosting.co.za (Meta Tracker)
Date: Mon, 11 Dec 2006 02:02:53 +0000 (UTC)
Subject: [Tracker-discuss] Summary of Meta Tracker Issues
Message-ID: <20061211020253.AA7DB78522@psf.upfronthosting.co.za>


ACTIVITY SUMMARY ( 4 December 2006 - 11 December 2006)
Meta Tracker at http://psf.upfronthosting.co.za/roundup/meta/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


   30 open ( +8) /    34 closed ( +2) /    64 total (+10)

Open Issues Statistics
     unread     6 ( +3)
   deferred     0 ( +0)
   chatting    19 ( +5)
    need-eg     0 ( +0)
in-progress     3 ( +0)
    testing     2 ( +0)

Issues Created Or Reopened (12)
_______________________________

Poor performance when displaying issues - assignee list rend (10 December 2006)
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue3  reopened stefan     

Best way to get files to the roundup user area? and other qu (10 December 2006)
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue53 reopened stefan     

Required issue property title not supplied (7 December 2006)
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue57 created  loewis     

Time on tracker machine is incorrect (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue58 created  loewis     

Set assignee to None for unassigned items (7 December 2006)
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue59 created  forsberg   

password reset procedure confusing (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue60 created  loewis     

Order of messages reversed (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue61 created  loewis     

Can't follow-up per email (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue62 created  loewis     

List of roles in user search popup is incorrect (9 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue63 created  forsberg   

Many classes invisible to anonymous users (10 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue64 created  forsberg   

issue.search.html and issue.index.html not in sync (10 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue65 created  forsberg   

Where in the world is our Python, etc. (10 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue66 created  dubois     



Issues Now Closed (6)
_____________________

Poor performance when displaying issues - assignee list rend (10 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue3  forsberg    0 days   

Default value of status in search form should be 'open' (31 July 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue24 forsberg    131 days 

Add link to Upfront Systems in tracker (19 November 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue49 forsberg    21 days  

Best way to get files to the roundup user area? and other qu (10 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue53 forsberg    0 days   

Required issue property title not supplied (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue57 forsberg    3 days   

Set assignee to None for unassigned items (7 December 2006)
       http://psf.upfronthosting.co.za/roundup/meta/issue59 forsberg    0 days   



Top Issues Most Discussed (6)
_____________________________

13  import sf.net data
in-progress http://psf.upfronthosting.co.za/roundup/meta/issue55 dubois      8 days   

11  Poor performance when displaying issues - assignee list renders slowly
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue3  forsberg    0 days   

6   Can't follow-up per email
chatting    http://psf.upfronthosting.co.za/roundup/meta/issue62 stefan      1 days   

5   Time on tracker machine is incorrect
chatting    http://psf.upfronthosting.co.za/roundup/meta/issue58 loewis      3 days   

4   Best way to get files to the roundup user area? and other questions
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue53 forsberg    0 days   

3   Required issue property title not supplied
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue57 forsberg    3 days   



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061211/46859df0/attachment.htm 

From kbk at shore.net  Tue Dec 12 01:46:07 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 11 Dec 2006 19:46:07 -0500
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	(Neal Norwitz's message of "Sun, 10 Dec 2006 16:09:04 -0800")
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
Message-ID: <87vekivt4g.fsf@hydra.bayview.thirdcreek.com>

"Neal Norwitz" <nnorwitz at gmail.com> writes:

> Of course, I'd like a few small changes though. :-)  I don't have a problem
> with html since I use gmail.  I don't know if we have to keep supporting
> text or not.  If we do, I would prefer them formatted somewhat differently.

I don't have much of a problem with html email (outside of the fact that
it's an abomination wrt bandwidth and access time ;) but it's important
to me to keep the text version.  I don't use web mail - it's way too
slow and missing too many features.  I use gnus.

I don't want to open a browser just to read email.  If I see a link in
the report that I like I right click on it and it opens in my browser
which is already running on another desktop.  Looking at the Meta
Tracker Activity Summary which followed your email, right now the url is
too long compared to www.python.org/sf/1234456 etc.  Try to keep the
text version of the report to 72 columns.  I imagine you will set up
an alias or route through p.o eventually.

I'm pulling mail from five servers into about 40 groups with features
that gmail never thought of.  If I want more, I program them.  When
I do toggle html email on, it's with lynx :-) and the report is rather
ugly in lynx!  I have no problems with speed, virus, trojans, or
phishing. (I do occasionally have problems with gnus biting me in the
tail and sending unwanted mail to python-dev, but that's pebkac :)

How would you format it differently?

-- 
KBK

From pfdubois at gmail.com  Tue Dec 12 02:00:27 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Mon, 11 Dec 2006 17:00:27 -0800
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	<87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <f74a6c2f0612111700i3cb8d13as5e191887cf0376ac@mail.gmail.com>

Perhaps I didn't explain clearly enough but I do have a text version
that is the same as the one you had before. When sending it by email I
send both as a multipart so if you are not viewing your mail with html
you should see the text one. When we are ready to deploy you can
decide if you want just text, just html, or both.

The tables are driven off of some specifiers as to field titles,
contents, and widths so it is trivial to adjust.

For the html table I plan to have the title be the link, I think, so
the length of the URL does not matter. The report gets the URL from
the Roundup configuration so when that changes to a python.org alias
the report will change too.

Next time I make an improvement I'll send you just the text.

From kbk at shore.net  Tue Dec 12 02:27:24 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 11 Dec 2006 20:27:24 -0500
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <f74a6c2f0612111700i3cb8d13as5e191887cf0376ac@mail.gmail.com>
	(Paul Dubois's message of "Mon, 11 Dec 2006 17:00:27 -0800")
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	<87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
	<f74a6c2f0612111700i3cb8d13as5e191887cf0376ac@mail.gmail.com>
Message-ID: <87r6v5x5s3.fsf@hydra.bayview.thirdcreek.com>

"Paul Dubois" <pfdubois at gmail.com> writes:

> Perhaps I didn't explain clearly enough but I do have a text version
> that is the same as the one you had before. When sending it by email I
> send both as a multipart so if you are not viewing your mail with html
> you should see the text one. When we are ready to deploy you can
> decide if you want just text, just html, or both.

I understood you with no problem.  And I saw the text version in the
mail that followed this thread.  It worked fine, but it was a little
wide.

It was Neal who questioned whether we need to continue to send the text
multipart, if I understood what he said correctly.  I'm requesting that
we continue to send it.  There are many who prefer ascii email clients
like pine.  Personally, I use an xterm to ssh into a box running gnus;
that box doesn't have to run an X client.

> The tables are driven off of some specifiers as to field titles,
> contents, and widths so it is trivial to adjust.

I'm only talking about the width of the text version.  72 columns is
standard, mostly to allow for quoting in clients that can't reformat.
For the html version, you should do what you want to make it look good.
I can always hit Opera's '-' key :-)

> For the html table I plan to have the title be the link, I think, so
> the length of the URL does not matter. 

Good idea!

> The report gets the URL from the Roundup configuration so when that
> changes to a python.org alias the report will change too.
>
> Next time I make an improvement I'll send you just the text.

How would you know which a user wants?  I just tell gnus to display text
in preference to html.  It displays 'buttons' for both.  If there is
no text multipart, it will display html, but that's not preferred for
me.  I didn't even see the html version until I switched it on.  So
send me both.

You've made excellent progress on this, by the way.

-- 
KBK

From nnorwitz at gmail.com  Tue Dec 12 05:53:52 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 11 Dec 2006 20:53:52 -0800
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	<87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <ee2a432c0612112053n3095d203i17b142fba0c6ccc7@mail.gmail.com>

On 12/11/06, Kurt B. Kaiser <kbk at shore.net> wrote:
> "Neal Norwitz" <nnorwitz at gmail.com> writes:
>
> > Of course, I'd like a few small changes though. :-)  I don't have a problem
> > with html since I use gmail.  I don't know if we have to keep supporting
> > text or not.  If we do, I would prefer them formatted somewhat differently.

Just to clarify, I wasn't suggesting dropping or keeping the text
version.  I don't care either way.  If people want it, I think it's
fine to keep it.

What I really wanted was the HTML version to be modified (thus
diverging from the text based version).  Paul made some of the changes
already.  For example, I didn't want to see the id.  A link is much
better since it's already HTML.

n

From kbk at shore.net  Tue Dec 12 06:43:17 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Tue, 12 Dec 2006 00:43:17 -0500
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <ee2a432c0612112053n3095d203i17b142fba0c6ccc7@mail.gmail.com>
	(Neal Norwitz's message of "Mon, 11 Dec 2006 20:53:52 -0800")
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	<87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
	<ee2a432c0612112053n3095d203i17b142fba0c6ccc7@mail.gmail.com>
Message-ID: <87irghwtxm.fsf@hydra.bayview.thirdcreek.com>

"Neal Norwitz" <nnorwitz at gmail.com> writes:

> On 12/11/06, Kurt B. Kaiser <kbk at shore.net> wrote:
>> "Neal Norwitz" <nnorwitz at gmail.com> writes:
>>
>> > Of course, I'd like a few small changes though. :-) I don't have a
>> > problem with html since I use gmail.  I don't know if we have to
>> > keep supporting text or not.  If we do, I would prefer them
>> > formatted somewhat differently.
>
> Just to clarify, I wasn't suggesting dropping or keeping the text
> version.  I don't care either way.  If people want it, I think it's
> fine to keep it.
>
> What I really wanted was the HTML version to be modified (thus
> diverging from the text based version).  Paul made some of the changes
> already.  For example, I didn't want to see the id.  A link is much
> better since it's already HTML.

Yes, agreed, no problem!  Make the html as capable and beautiful as you
can, that's what it's good for.  (Some of us like to trade beauty off
for other qualities and click on the link if we want more :)

-- 
KBK

From forsberg at efod.se  Tue Dec 12 07:49:38 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 12 Dec 2006 07:49:38 +0100
Subject: [Tracker-discuss] Fwd: Summary of Tracker Issues
In-Reply-To: <87vekivt4g.fsf@hydra.bayview.thirdcreek.com> (Kurt B. Kaiser's
	message of "Mon, 11 Dec 2006 19:46:07 -0500")
References: <20061211014418.5B71D783B8@psf.upfronthosting.co.za>
	<f74a6c2f0612101550p216bfb04pd41431e46a54628a@mail.gmail.com>
	<ee2a432c0612101609k4fc611fdw4b67bb68028bd193@mail.gmail.com>
	<87vekivt4g.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <87d56pr4l9.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Kurt B. Kaiser" <kbk at shore.net> writes:

> Tracker Activity Summary which followed your email, right now the url is
> too long compared to www.python.org/sf/1234456 etc.  

Don't worry, URLs will be considerably shorter once we go live. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFflECrJurFAusidkRAhQMAKC8gLj52Hmi5D8q7T/VFZUueze8mACbBizZ
pTdPhYuBLU6WP6gsoRHb6/s=
=YkYA
-----END PGP SIGNATURE-----

From forsberg at efod.se  Wed Dec 13 21:12:22 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 13 Dec 2006 21:12:22 +0100
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <457C862A.3040208@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 10 Dec 2006 23:11:54 +0100")
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
	<87zm9wc84l.fsf@uterus.efod.se> <457C862A.3040208@v.loewis.de>
Message-ID: <87ejr3pnbt.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Ok, AST is then "Abstract Syntax Tree". Mapping them to "Interpreter
> Core" would be appropriate (if they aren't already mapped so).
>
>> I need input on how to handle "* candidate" and "Python 3000", but at
>> least the above gives me something to work on.
>
> Not sure whether that's appropriate, but I think making "py3k" a
> "type" might be one solution. At some point, people said they wanted
> to have a separate tracker for it entirely.

Hmm.. as I don't know what kind of issues are filed on py3k, I don't
know how appropriate it is, but I presume that it's of value to
classify py3k bugs as 'crash', 'rfe', 'resource behaviour' et. al,
which would be impossible with this solution?
>
> Adding a Py3k boolean flag would be another solution.

I see a boolean/checkbox as a very simplified and restricted keyword
mechanism, so I'd rather add a keyword mechanism than a boolean.

With "keyword mechanism", I mean a field where a list of 0..n keyword
can be added per bug. The list available keywords is defined via the
web interface, and can have a description. The search interface then
allows search for bugs with specific keywords. 

I think this is a powerful mechanism that eases tracker use. If a
group of developers need to mark a bunch of bugs to be able to find
them, it's very easy to do that - just a matter of minutes. It makes
the tracker flexible. 

Keywords are part of the "classic" roundup schema, but was removed by
Stefan when he designed the current schema. I don't know if there was
a specific reason for that. Stefan?

Do we have any strong opinions _against_ (re)adding keywords? If not,
I'll implement, and let issues with the "py3k" group get a "py3k"
keyword.

Regards,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFgF6lrJurFAusidkRArCZAKCPHVez6oOqy1E2IgBP9aWgcJtPWACgzJNC
/Y8+I2H3OJSBNpbcbLFTuS0=
=vU33
-----END PGP SIGNATURE-----

From forsberg at efod.se  Wed Dec 13 21:39:22 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 13 Dec 2006 21:39:22 +0100
Subject: [Tracker-discuss] Tracker status
Message-ID: <87ac1rpm2t.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Some reflections on how far we are from going live with the tracker:

* The importer is well underway, with some minor issues left to
  discuss and implement. I suspected that (re)writing the importer
  would lead to a lot of questions that needed answers and that was a
  correct assumption :-).

  http://psf.upfronthosting.co.za/roundup/meta/issue55 has all the details.

* We have a number of issues that need to be resolved before going
  live. 

  I think the current list of issues with priority "bug" and "urgent"
  on http://psf.upfronthosting.co.za/roundup/meta/ reflect what needs
  to be done. Feel free to assign yourself to one of them!

  Please review the list of issues with lower priorites and move them
  up if you believe they are showstoppers.

* I don't think we'll be able to reach the goal of going live before
  the end of this year, but hopefully we'll be able to do it during
  the first half of January.

Right now, what needs to be done are:

 1) Finalize importer. I will probably be able to do that tomorrow,
    unless there's a long discussion on my keyword proposal.

1?) Work on issues with priority "bug".

 2) Once 1) is finished, I'll do an import. Then it's time for some
    hard testing by the python-dev members on this mailinglist. We
    need answers to questions like:

    *) Can you do your work using the new tracker?

    *) Can releases be done using the new tracker?

    If there are any "No!" in the answers, they should be added as
    issues to the meta tracker with priority "bug" and we'll have to
    sort them out.

 3) When 1,1?, and 2 are finished, do final import and go live.

Regards,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFgGT5rJurFAusidkRApUFAJ4m9x9cIg+/5d0obqYMZ93ernP1rwCff0HF
T1lKW5+OBTCUi/7hpBy8dyA=
=Nc1Y
-----END PGP SIGNATURE-----

From pfdubois at gmail.com  Wed Dec 13 21:49:27 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 13 Dec 2006 12:49:27 -0800
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87ejr3pnbt.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se> <457BA6BC.7010202@v.loewis.de>
	<87zm9wc84l.fsf@uterus.efod.se> <457C862A.3040208@v.loewis.de>
	<87ejr3pnbt.fsf@uterus.efod.se>
Message-ID: <f74a6c2f0612131249o3143fa30l7d40bfb7777504ae@mail.gmail.com>

I strongly favor keywords; in my own tracker, I have some detectors
that do different things depending on keywords. As Erik says, this
mechanism is highly flexible.

One example is our 'Status Reports'. This is a periodically posted
issue, begun by the project leader. Then all the developers add their
report to the issue. At the end the project has an archived,
searchable set of progress reports -- invaluable when it is time for
the annual review. The project leader gives these reports a
statusreports keyword, and then the nosy detector does NOT send mail
on such an issue, so that everyone can contribute without causing a
lot of email.

One can restrict the *creation* of new keywords to a subset of the
users, to prevent redundancies, etc. One can decide who can apply a
keyword to an issue, too, if desired.

On 12/13/06, Erik Forsberg <forsberg at efod.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "Martin v. L?wis" <martin at v.loewis.de> writes:
>
> > Ok, AST is then "Abstract Syntax Tree". Mapping them to "Interpreter
> > Core" would be appropriate (if they aren't already mapped so).
> >
> >> I need input on how to handle "* candidate" and "Python 3000", but at
> >> least the above gives me something to work on.
> >
> > Not sure whether that's appropriate, but I think making "py3k" a
> > "type" might be one solution. At some point, people said they wanted
> > to have a separate tracker for it entirely.
>
> Hmm.. as I don't know what kind of issues are filed on py3k, I don't
> know how appropriate it is, but I presume that it's of value to
> classify py3k bugs as 'crash', 'rfe', 'resource behaviour' et. al,
> which would be impossible with this solution?
> >
> > Adding a Py3k boolean flag would be another solution.
>
> I see a boolean/checkbox as a very simplified and restricted keyword
> mechanism, so I'd rather add a keyword mechanism than a boolean.
>
> With "keyword mechanism", I mean a field where a list of 0..n keyword
> can be added per bug. The list available keywords is defined via the
> web interface, and can have a description. The search interface then
> allows search for bugs with specific keywords.
>
> I think this is a powerful mechanism that eases tracker use. If a
> group of developers need to mark a bunch of bugs to be able to find
> them, it's very easy to do that - just a matter of minutes. It makes
> the tracker flexible.
>
> Keywords are part of the "classic" roundup schema, but was removed by
> Stefan when he designed the current schema. I don't know if there was
> a specific reason for that. Stefan?
>
> Do we have any strong opinions _against_ (re)adding keywords? If not,
> I'll implement, and let issues with the "py3k" group get a "py3k"
> keyword.
>
> Regards,
> \EF
> - --
> Erik Forsberg                 http://efod.se
> GPG/PGP Key: 1024D/0BAC89D9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFFgF6lrJurFAusidkRArCZAKCPHVez6oOqy1E2IgBP9aWgcJtPWACgzJNC
> /Y8+I2H3OJSBNpbcbLFTuS0=
> =vU33
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From martin at v.loewis.de  Wed Dec 13 21:53:33 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 13 Dec 2006 21:53:33 +0100
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87ejr3pnbt.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se>
	<457BA6BC.7010202@v.loewis.de>	<87zm9wc84l.fsf@uterus.efod.se>
	<457C862A.3040208@v.loewis.de> <87ejr3pnbt.fsf@uterus.efod.se>
Message-ID: <4580684D.1000308@v.loewis.de>

Erik Forsberg schrieb:
> Hmm.. as I don't know what kind of issues are filed on py3k, I don't
> know how appropriate it is, but I presume that it's of value to
> classify py3k bugs as 'crash', 'rfe', 'resource behaviour' et. al,
> which would be impossible with this solution?

So far, py3k implies "new feature". That may change over time.

> I see a boolean/checkbox as a very simplified and restricted keyword
> mechanism, so I'd rather add a keyword mechanism than a boolean.

That's fine with me, as long as it is possible to filter for them.
I personally never want to see any py3k issues, except when I click
on a query named "py3k".

> I think this is a powerful mechanism that eases tracker use.

I trust you on that, so go ahead.

Regards,
Martin

From seefeld at sympatico.ca  Wed Dec 13 22:04:44 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 13 Dec 2006 16:04:44 -0500
Subject: [Tracker-discuss] How to map "Group"?
In-Reply-To: <87ejr3pnbt.fsf@uterus.efod.se>
References: <87u004ejfk.fsf@uterus.efod.se>
	<457BA6BC.7010202@v.loewis.de>	<87zm9wc84l.fsf@uterus.efod.se>
	<457C862A.3040208@v.loewis.de> <87ejr3pnbt.fsf@uterus.efod.se>
Message-ID: <45806AEC.8060407@sympatico.ca>

Erik Forsberg wrote:

> Keywords are part of the "classic" roundup schema, but was removed by
> Stefan when he designed the current schema. I don't know if there was
> a specific reason for that. Stefan?

I hoped to be able to capture all issue metadata in typed properties,
hoping that such constrains would help avoid errors, and guide users
of the tracker. (As you can guess I'm a fan of strong & static typing :-) )


> Do we have any strong opinions _against_ (re)adding keywords? If not,
> I'll implement, and let issues with the "py3k" group get a "py3k"
> keyword.

Well, if the schema isn't expressive enough then we clearly need to
enhance it. And, if everybody else is more comfortable with keywords,
go for it.

Thanks,
		Stefan

-- 

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

From roundup-admin at psf.upfronthosting.co.za  Thu Dec 14 05:58:02 2006
From: roundup-admin at psf.upfronthosting.co.za (Tracker)
Date: Thu, 14 Dec 2006 04:58:02 +0000 (UTC)
Subject: [Tracker-discuss] Summary of Tracker Issues
Message-ID: <20061214045802.E851A78522@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (12/07/06 - 12/14/06)
Tracker at http://psf.upfronthosting.co.za/roundup/tracker/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1605 open ( +9) /  8292 closed ( +1) /  9897 total (+10)

Average duration of open issues: 695 days.
Median duration of open issues: 639 days.

Open Issues Breakdown
   open  1605 ( +9)
pending     0 ( +0)

Issues Created Or Reopened (10)
_______________________________

C99 _Bool support for struct                                     12/07/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1610575 created  chmod007       

cgi.py multipart/form-data                                       12/07/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1610654 created  teyc           

BSD version of ctypes.util.find_library                          12/07/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1610795 created  mkam           

\b in unicode regex gives strange results                        12/07/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1611131 created  akaihola       

os.path.exists("file/") failure on Solaris 9                     12/07/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1611154 created  eggert         

can't pickle NAN's in binary mode                                12/08/06
CLOSED http://psf.upfronthosting.co.za/roundup/tracker/issue1611753 created  wayne606       

sndhdr.what() does not recognize wav file                        12/09/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1611944 created  klankschap     

builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT               12/09/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1612012 created  anthonybaxter  

Py_DEBUG                                                         12/09/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1612190 created  nitrogenycs    

Class Browser doesn't show internal classes                      12/09/06
       http://psf.upfronthosting.co.za/roundup/tracker/issue1612262 created  taleinat       



Issues Now Closed (10)
______________________

modsupport does not use va_copy when available                  1094 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue858318  sf-robot       

race in os.makedirs()                                            539 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1223238 gbrandl        

Prevent race condition in os.makedirs                            510 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1239890 gbrandl        

os.makedirs - robust against partial path                        430 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1314067 gbrandl        

dict keyerror formatting and tuples                               56 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1576657 rhettinger     

whitespace in `svnversion .`                                      54 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1577756 gbrandl        

"".translate() docs should mention string.maketrans()             29 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1592899 gbrandl        

Race condition in os.makedirs                                      5 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1608579 gbrandl        

GUI for Python 2.3, 2.4, and 2.5 is very sluggish                  3 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1610485 g4rlik         

can't pickle NAN's in binary mode                                  1 days
       http://psf.upfronthosting.co.za/roundup/tracker/issue1611753 mwh            



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061214/4959df32/attachment.html 

From roundup-admin at psf.upfronthosting.co.za  Thu Dec 14 07:06:01 2006
From: roundup-admin at psf.upfronthosting.co.za (Meta Tracker)
Date: Thu, 14 Dec 2006 06:06:01 +0000 (UTC)
Subject: [Tracker-discuss] Summary of Meta Tracker Issues
Message-ID: <20061214060601.ED68C78522@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (12/07/06 - 12/14/06)
Meta Tracker at http://psf.upfronthosting.co.za/roundup/meta/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


   26 open ( +5) /    39 closed ( +6) /    65 total (+11)

Average duration of open issues:  55 days.
Median duration of open issues:  27 days.

Open Issues Breakdown
     unread     4 ( +2)
   deferred     0 ( +0)
   chatting    17 ( +3)
    need-eg     0 ( +0)
in-progress     2 ( +0)
    testing     3 ( +0)

Issues Created Or Reopened (13)
_______________________________

Poor performance when displaying issues - assignee list renders  12/10/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue3  reopened stefan     

Best way to get files to the roundup user area? and other questi 12/11/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue53 reopened dubois     

Required issue property title not supplied                       12/07/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue57 created  loewis     

Time on tracker machine is incorrect                             12/07/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue58 created  loewis     

Set assignee to None for unassigned items                        12/07/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue59 created  forsberg   

password reset procedure confusing                               12/07/06
       http://psf.upfronthosting.co.za/roundup/meta/issue60 created  loewis     

Order of messages reversed                                       12/07/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue61 created  loewis     

Can't follow-up per email                                        12/07/06
       http://psf.upfronthosting.co.za/roundup/meta/issue62 created  loewis     

List of roles in user search popup is incorrect                  12/09/06
       http://psf.upfronthosting.co.za/roundup/meta/issue63 created  forsberg   

Many classes invisible to anonymous users                        12/10/06
       http://psf.upfronthosting.co.za/roundup/meta/issue64 created  forsberg   

issue.search.html and issue.index.html not in sync               12/10/06
       http://psf.upfronthosting.co.za/roundup/meta/issue65 created  forsberg   

Where in the world is our Python, etc.                           12/10/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue66 created  dubois     

svn commit failed                                                12/11/06
CLOSED http://psf.upfronthosting.co.za/roundup/meta/issue67 reopened dubois     



Issues Now Closed (11)
______________________

Poor performance when displaying issues - assignee list renders    1 days
       http://psf.upfronthosting.co.za/roundup/meta/issue3  forsberg   

bug in display of issue 1462525                                  139 days
       http://psf.upfronthosting.co.za/roundup/meta/issue22 forsberg   

Default value of status in search form should be 'open'          132 days
       http://psf.upfronthosting.co.za/roundup/meta/issue24 forsberg   

Add link to Upfront Systems in tracker                            21 days
       http://psf.upfronthosting.co.za/roundup/meta/issue49 forsberg   

Best way to get files to the roundup user area? and other quest    2 days
       http://psf.upfronthosting.co.za/roundup/meta/issue53 forsberg   

Required issue property title not supplied                         3 days
       http://psf.upfronthosting.co.za/roundup/meta/issue57 forsberg   

Time on tracker machine is incorrect                               4 days
       http://psf.upfronthosting.co.za/roundup/meta/issue58 forsberg   

Set assignee to None for unassigned items                          1 days
       http://psf.upfronthosting.co.za/roundup/meta/issue59 forsberg   

Order of messages reversed                                         6 days
       http://psf.upfronthosting.co.za/roundup/meta/issue61 forsberg   

Where in the world is our Python, etc.                             3 days
       http://psf.upfronthosting.co.za/roundup/meta/issue66 forsberg   

svn commit failed                                                  0 days
       http://psf.upfronthosting.co.za/roundup/meta/issue67 dubois     



Top Issues Most Discussed (8)
_____________________________

 17 Best way to get files to the roundup user area? and other quest    2 days
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue53

 15 import sf.net data                                                12 days
in-progress http://psf.upfronthosting.co.za/roundup/meta/issue55

 11 Poor performance when displaying issues - assignee list renders    1 days
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue3 

  8 Time on tracker machine is incorrect                               4 days
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue58

  6 Can't follow-up per email                                          6 days
chatting    http://psf.upfronthosting.co.za/roundup/meta/issue62

  5 svn commit failed                                                  0 days
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue67

  3 password reset procedure confusing                                 6 days
chatting    http://psf.upfronthosting.co.za/roundup/meta/issue60

  3 Required issue property title not supplied                         3 days
resolved    http://psf.upfronthosting.co.za/roundup/meta/issue57



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061214/51ae417c/attachment.htm 

From isburger at gmail.com  Wed Dec 20 10:37:30 2006
From: isburger at gmail.com (Izak Burger)
Date: Wed, 20 Dec 2006 11:37:30 +0200
Subject: [Tracker-discuss] PSF host down
Message-ID: <e2e2e5500612200137g70b04eb0x21f748a7e11cd62d@mail.gmail.com>

Hi all,

Hetzner in Germany has a problem with their network infrastructure.
It would seem a router is down and we cannot reach any of our servers
there.  This includes the machine on which psf.upfronthosting.co.za is
hosted as well as our own mail server.  We've reported the problem and
we're holding thumbs for a speedy resolution.

regards,
Izak Burger

From izak at upfrontsystems.co.za  Wed Dec 20 12:26:14 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Wed, 20 Dec 2006 13:26:14 +0200
Subject: [Tracker-discuss] PSF host down
In-Reply-To: <e2e2e5500612200137g70b04eb0x21f748a7e11cd62d@mail.gmail.com>
References: <e2e2e5500612200137g70b04eb0x21f748a7e11cd62d@mail.gmail.com>
Message-ID: <45891DD6.1070206@upfrontsystems.co.za>

Izak Burger wrote:
> Hetzner in Germany has a problem with their network infrastructure.
> It would seem a router is down and we cannot reach any of our servers
> there.  This includes the machine on which psf.upfronthosting.co.za is
> hosted as well as our own mail server.  We've reported the problem and
> we're holding thumbs for a speedy resolution.

Turns out it was human error.  Someone thought we forgot to pay the 
water and lights... all is well again.

From forsberg at efod.se  Thu Dec 21 14:21:53 2006
From: forsberg at efod.se (forsberg at efod.se)
Date: Thu, 21 Dec 2006 14:21:53 +0100 (CET)
Subject: [Tracker-discuss] Tracker status
In-Reply-To: <87ac1rpm2t.fsf@uterus.efod.se>
References: <87ac1rpm2t.fsf@uterus.efod.se>
Message-ID: <54945.217.28.34.132.1166707313.squirrel@efod.se>

> Right now, what needs to be done are:
>
>  1) Finalize importer. I will probably be able to do that tomorrow,
>     unless there's a long discussion on my keyword proposal.

"tomorrow" as usual appeared much later than expected :-).

Anyway, changes on tracker to re-add keyword support has been commited.
Importer has been enhanced to set the keyword py3k on all issues that had
"Python 3000" as group.

A new import has been run, with data from 2006-12-19.

I don't know how much I'll be able to work on the tracker during the
weekends, as I'll be spending a lot of time in the deep woods of Sweden
with my parents, where the only network available is a 56k winmodem.
Urgl.. I'm writing this on the train, where there's at least half a
megabit wireless network =).

Cheers,
\EF





From roche at upfrontsystems.co.za  Wed Dec 27 07:37:25 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Wed, 27 Dec 2006 08:37:25 +0200
Subject: [Tracker-discuss] PSF host down
Message-ID: <1167201445.5256.3.camel@kwaaitjie>

We noticed that psf.upfronthosting.co.za is not reachable. We can reach
the server via some of our other server in Hetzner's data center. This
suggests that they might have problems with their firewall. We logged a
support issue with the data center and await their response.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From pfdubois at gmail.com  Wed Dec 27 19:13:59 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 27 Dec 2006 10:13:59 -0800
Subject: [Tracker-discuss] roundup summary to be run weekly on test tracker
Message-ID: <f74a6c2f0612271013t41b24e8bhc8d65798482414b8@mail.gmail.com>

If all goes well you will see email to this list once a week running the
proposed roundup summary on the test tracker. Please note that since the
default time period of a week will result in no changes most of the time,
since this tracker is not 'live'.

When we deploy I will change the destination email. For now this will verify
that there are no bad problems cropping up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061227/a05a1caa/attachment.html