Re: [Python-Dev] Tracker archeology

[Rodrigo Bernardo Pimentel]

[Sorry for stepping in so late]

On Thu, Feb 12 2009 at 02:05:23PM BRST, "Daniel (ajax) Diniz" 
 wrote:
> Victor Stinner wrote:
> > Oh, I realized that there is a component called "Unicode". So it should be
> > possible to write a request to list all issues related to unicode.
> 
> Nice, I'll add set this component for issues that don't have it. I can
> still add people to these issues, if they want.

I think this one might be considered a Unicode issue:

http://bugs.python.org/issue1293741 "doctest runner cannot handle non-ascii
characters"


rbp
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

> But no way to share aggregated search results (I've sent some
> off-list), 'follow' users (i.e., be added as nosy for issues where
> user A is nosy), auto-add as nosy based on keywords, etc. Someday we
> could have these nosy features hosted externally, e.g. as an AppEngine
> app that subscribes to python-bugs and sends alerts to users matching
> the message (by keyword, performed action, new stage, etc.).

Please, please, no. If you can add it to an external application,
please, pretty pretty please, add it to roundup directly (or, rather,
to this specific tracker).

> 
>>> Right now, more efficient searching and aggregation along with some
>>> (local, flexible) UI tweaks sum it up.
>> Efficient in what way?
> 
> Having those complex searches in a less convoluted workflow, allowing
> more work to be done faster and in a less error prone way.

If it's useful to you, it might be useful to others as well. So consider
contributing free-form searches to roundup (in addition to form-based
searches).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Daniel (ajax) Diniz wrote:
> Status report and roadmap to be posted later today, before date +%s
> turns 1234567890 :)

Missed that and got almost no tracker work done. Postponed to Monday,
after some weekend cleaning.

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Hi Martin,
Sorry about being so brief, I got a lot of unexpected interruptions
and was rushing things.

"Martin v. Löwis" wrote:
>> For starters, free form searches, aggregation and filtering of
>> results.
>
> What is "free form searches" (example)? What is aggregation?
> What results do you want to filter? (roundup can already filter
> results quite well)

By free form searches I meant complex queries with more flexible criteria.

A real example: "find any issue that has words A and B in juxtaposed
in messages, containing words starting with 'url' [ but not ending
with 'lib' in title (, unless version >= 3)], where jjlee isn't nosy".
Or "issues with less than 5 replies, all from a single user". Lastly,
"issues where no Developer is nosy, with messages covering an interval
longer than a week".

These are useful a few times, but hard to predict and not so recurrent
searches, so free form makes more sense than adding support for each
combination.

By aggregation I meant performing a few disjunct searches and
combining them in a result set, eliminating duplication, to process as
a unit. Then, add issues A,B and C to that. Free form searches cover
this by allowing one to perform a query that gives the result set
directly, but combining previous searches sounds more pleasant.

And by filtering, I meant refining a set of search results and/or
searching over a restricted set of issues, on criteria that are
present in them. I.e., I'd like to search for segfault and be given a
choice box with the all nosy people in  the result set, and exclude or
only display issues  based choosing one of them.

All of the above seems trivial with a database-like interface. I have
pretty much emulated them with the current search, the handy CSV
results downloads, a text editor and a Python shell.

>> The web interface is pretty good for handling individual
>> issues, but not so good for adding someone as nosy to lots of issues.
>
> Please consider contributing a mass-update template then, perhaps
> based on search results, with check boxes to include or exclude
> individual issues from the mass update.

OK, I saw one of these at http://roundup.sf.net/ and will study and
adapt it. But it'll solve the 'commit changes' part of the equation,
not the 'select set of issues to change'.

>>  Send emails before they were done :D
>
> Again: what's that?

That's me trying to sound witty after sending the email before finishing it :)

>>  Use a VCS for in-progress activities
>
> Hmm. Why do you need a database copy for that?

I don't, the database if for selecting issues to edit. But I'd like to
be able to submit bulk changes, and a (local, D) VCS is how I imagine
storing these locally should be done. For rollbacks, merges and that
sort of thing, besides being able to save incomplete work to continue
later.

>>  Figure out how to serialize and submit the work done locally
>
> Again, don't understand. too brief.

The serialization idea comes from this: one would assemble a 'patch'
containing different changes to different issues. It's an extension of
the mass-update idea, but for non-uniform changes. The deserialization
would either happen through a mass-update interface or by running a
script to submit them one by one.

>>  Share results with interested parties off-tracker (e.g., the
>> auto-nosy mentioned up-thread)
>
> The tracker already has auto-assignments based on components.

But no way to share aggregated search results (I've sent some
off-list), 'follow' users (i.e., be added as nosy for issues where
user A is nosy), auto-add as nosy based on keywords, etc. Someday we
could have these nosy features hosted externally, e.g. as an AppEngine
app that subscribes to python-bugs and sends alerts to users matching
the message (by keyword, performed action, new stage, etc.).

>> Right now, more efficient searching and aggregation along with some
>> (local, flexible) UI tweaks sum it up.
>
> Efficient in what way?

Having those complex searches in a less convoluted workflow, allowing
more work to be done faster and in a less error prone way.

>> Maybe I can offer a patch for something like PyPI's 'simple' interface?
>
> Please, no. Contribute the interface you want locally instead as a
> feature for all users of the tracker.

OK, after some more cleaning up I'll work on the mass-update, my local
searches and report back.

Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

>  Send emails before they were done :D

Again: what's that?

>  Use a VCS for in-progress activities

Hmm. Why do you need a database copy for that?

>  Figure out how to serialize and submit the work done locally

Again, don't understand. too brief.

>  Share results with interested parties off-tracker (e.g., the
> auto-nosy mentioned up-thread)

The tracker already has auto-assignments based on components.

> Right now, more efficient searching and aggregation along with some
> (local, flexible) UI tweaks sum it up.

Efficient in what way?

> Maybe I can offer a patch for something like PyPI's 'simple' interface?

Please, no. Contribute the interface you want locally instead as a
feature for all users of the tracker.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

> For starters, free form searches, aggregation and filtering of
> results.

What is "free form searches" (example)? What is aggregation?
What results do you want to filter? (roundup can already filter
results quite well)

> The web interface is pretty good for handling individual
> issues, but not so good for adding someone as nosy to lots of issues.

Please consider contributing a mass-update template then, perhaps
based on search results, with check boxes to include or exclude
individual issues from the mass update.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Steve Holden wrote:
> Can I just say (without in any way wanting to get involved in what might
> be considered as "work") that it's encouraging the tracker received a
> bit more TLC we might eventually be able to see at least the occasional
> week where the issue count increment was negative :)

That would be cool. It's also a shiny goal that can be used on a
call-for-help later on the cleanup road.

> So thanks to everyone who's taking the time to deal with this
> low-profile not-very-glamorous issue. I, for one, appreciate it.

For my part, glad to help. And thanks to all developers, issue
reporters and cleanup supporters that are making this work :)

tlc'ing-got-me-punched-in-the-face-before-so-this-one-is-a-breeze-ly y'rs
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Brett Cannon wrote:
> On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz  wrote:
>> I have to test my patch against a good
>> representation of the issue, regression tests must pass, 'automated
>> test needed' fits well :)
>
> Go with "Unit test needed" so it's short and to the point and you have a 
> deal. =)

I don't think a real name change is necessary, the help from clicking
on 'Stage' says it.
Your explanation at https://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw
makes it crystal  clear.

Also, I've realized just now that 'Status: pending' covers both my
'will close unless someone objects' and 'cannot tell if this ancient
bug on a antediluvian platform still exists' rather well. So I'll be
setting such issues as pending from now on.

I'll try to find a way to display the help tips inline, perhaps on
selection or hover (has to be unobtrusive). That would be helpful for
stages, components and versions (I think users should know that 2.5 is
in security-fix-only mode and that feature requests need latest
version + 1).

Status report and roadmap to be posted later today, before date +%s
turns 1234567890 :)

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Daniel (ajax) Diniz wrote:
> "Martin v. Löwis" wrote:
>> I think HTML scraping is a really bad idea. What is it that you
>> specifically want to do with these data?
>
> For starters, free form searches, aggregation and filtering of
> results. The web interface is pretty good for handling individual
> issues, but not so good for adding someone as nosy to lots of issues.

I should have thought of this earlier: I'm downloading A CSV file
(displaying all fields) with all issues and will insert that into a DB
(maybe through my local tracker instance). Thanks for asking the
'think about it' question! :)

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Georg Brandl]

Daniel (ajax) Diniz schrieb:

> Over-spammig:
>   Sorry, Georg! I only noticed all issues in the Documentation
> component are auto-assigned to you today. This meant dozens of unasked
> for assignments :-/

That's okay, I'll go through them at the weekend and just unassign what
I won't manage to do.

But the nice thing about documentation changes is that while writing the
change takes about as long as changing an equivalent piece of Python code,
there's no new test and waiting for the testsuite needed (except sometimes
a spellchecker wouldn't hurt), so it's much quicker :)

Thank you for your efforts, they are much appreciated!

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Daniel (ajax) Diniz wrote:
> "Martin v. Löwis" wrote:
>>> Now, getting into pie-in-the-sky territory, if someone (not logged in)
>>>  was to download all issues for scrapping and feeding to a local
>>> database, what time of day would be less disastrous for the server? :)
>>
>> I think HTML scraping is a really bad idea. What is it that you
>> specifically want to do with these data?
>
> For starters, free form searches, aggregation and filtering of
> results. The web interface is pretty good for handling individual
> issues, but not so good for adding someone as nosy to lots of issues.
>
> With some more time and effort, I'd be able to:
> Organize a local workflow with tweaked UI
>
 Send emails before they were done :D
 Use a VCS for in-progress activities
 Figure out how to serialize and submit the work done locally
 Share results with interested parties off-tracker (e.g., the
auto-nosy mentioned up-thread)

Right now, more efficient searching and aggregation along with some
(local, flexible) UI tweaks sum it up.

Maybe I can offer a patch for something like PyPI's 'simple' interface?

Cheers,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

"Martin v. Löwis" wrote:
>> Now, getting into pie-in-the-sky territory, if someone (not logged in)
>>  was to download all issues for scrapping and feeding to a local
>> database, what time of day would be less disastrous for the server? :)
>
> I think HTML scraping is a really bad idea. What is it that you
> specifically want to do with these data?

For starters, free form searches, aggregation and filtering of
results. The web interface is pretty good for handling individual
issues, but not so good for adding someone as nosy to lots of issues.

With some more time and effort, I'd be able to:
Organize a local workflow with tweaked UI
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

> Now, getting into pie-in-the-sky territory, if someone (not logged in)
>  was to download all issues for scrapping and feeding to a local
> database, what time of day would be less disastrous for the server? :)

I think HTML scraping is a really bad idea. What is it that you
specifically want to do with these data?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Steve Holden]

Brett Cannon wrote:
> 
> 
> On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz  > wrote:
> 
> Stephen J. Turnbull wrote:
> > Reproduction really is the same thing as providing a test.
> 
> That was where I got confused: many issues are easy to reproduce
> ('test'), but need some thinking to get automated tests right.
> 
> urllib always feels like this to me, except 'thinking' -> 'getting
> lost over and over'. Reading 'test needed' as 'automated test needed',
> things make a lot of sense. I have to test my patch against a good
> representation of the issue, regression tests must pass, 'automated
> test needed' fits well :)
> 
> 
> Go with "Unit test needed" so it's short and to the point and you have a
> deal. =)
> 
Can I just say (without in any way wanting to get involved in what might
be considered as "work") that it's encouraging the tracker received a
bit more TLC we might eventually be able to see at least the occasional
week where the issue count increment was negative :)

So thanks to everyone who's taking the time to deal with this
low-profile not-very-glamorous issue. I, for one, appreciate it.

regards
 Steve

-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 16:45, Daniel (ajax) Diniz  wrote:

> Stephen J. Turnbull wrote:
> > Reproduction really is the same thing as providing a test.
>
> That was where I got confused: many issues are easy to reproduce
> ('test'), but need some thinking to get automated tests right.
>
> urllib always feels like this to me, except 'thinking' -> 'getting
> lost over and over'. Reading 'test needed' as 'automated test needed',
> things make a lot of sense. I have to test my patch against a good
> representation of the issue, regression tests must pass, 'automated
> test needed' fits well :)
>

Go with "Unit test needed" so it's short and to the point and you have a
deal. =)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Stephen J. Turnbull wrote:
> Reproduction really is the same thing as providing a test.

That was where I got confused: many issues are easy to reproduce
('test'), but need some thinking to get automated tests right.

urllib always feels like this to me, except 'thinking' -> 'getting
lost over and over'. Reading 'test needed' as 'automated test needed',
things make a lot of sense. I have to test my patch against a good
representation of the issue, regression tests must pass, 'automated
test needed' fits well :)

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 16:22, Stephen J. Turnbull wrote:

> Brett Cannon writes:
>
>  > Sounds like a "*verify issue* stage is needed. Although I guess I kind
> of
>  > assumed as part of the triage issue verification would happen as well,
> but
>  > that might be too much as a single step.
>
> Are you confusing "reproduce" with "verify"?  Remember, one of the
> three classes for triage is "not a problem we need to deal with".
> Reproduction really is the same thing as providing a test.
>

I was aiming toward Daniel's issue of whether the bug could be reproduced
and thus verified as an issue when it is an old issue. But hopefully that
won't happen too often so adding a new stage is probably a bit much.


>
>  > All the other ones can use the current stages (e.g. a missing test with
> a
>  > patch is still at a *test needed* stage, it just happens to be able to
> skip
>  > to review once that test is ready).
>
> What I did with XEmacs's tracker (which has borrowed a lot from
> Python's, thank you all *very* much!) is to have an "in progress"
> stage, with "needs test|patch|doc" and "has test|patch|doc"
> *keywords*.  The difference in semantics is that "needs" is a judgment
> by the supervising reviewer, and the change (in theory) shouldn't be
> committed until all "needs" are satisfied, while "has" is what the
> contributor submitted.  So they are independent, and you could even
> have both "has patch" and "needs patch" present if the current patch
> isn't good enough.
>
> This is too complex to expect people to execute, even IMO, but maybe
> there's the germ of an idea there?  For example you could tell
> contributors that if the "has patch" flag isn't set, the patch won't
> get noticed by anybody.
>

It's a question of whether we can stay on top of updating issues or not. If
we can actually stay on the ball and update the status of issues then having
the OP update something shouldn't be needed as that is too easy of an
oversight for a casual contributor; minimizing the burden on contributions
by making the issue workflow easy for the contributor and efficient for us
is the top priority, but I think it is reasonable for us to do a little bit
more to make it easier on others.

And while you are right that the test/patch/doc stages can be view more in a
parallel fashion than the linear one the stage drop-down provides,
specifying the easiest of what is needed should help get more people
involved. Plus they are in the order things should be done in the ideal
situation.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Stephen J. Turnbull]

Brett Cannon writes:

 > Sounds like a "*verify issue* stage is needed. Although I guess I kind of
 > assumed as part of the triage issue verification would happen as well, but
 > that might be too much as a single step.

Are you confusing "reproduce" with "verify"?  Remember, one of the
three classes for triage is "not a problem we need to deal with".
Reproduction really is the same thing as providing a test.

 > All the other ones can use the current stages (e.g. a missing test with a
 > patch is still at a *test needed* stage, it just happens to be able to skip
 > to review once that test is ready).

What I did with XEmacs's tracker (which has borrowed a lot from
Python's, thank you all *very* much!) is to have an "in progress"
stage, with "needs test|patch|doc" and "has test|patch|doc"
*keywords*.  The difference in semantics is that "needs" is a judgment
by the supervising reviewer, and the change (in theory) shouldn't be
committed until all "needs" are satisfied, while "has" is what the
contributor submitted.  So they are independent, and you could even
have both "has patch" and "needs patch" present if the current patch
isn't good enough.

This is too complex to expect people to execute, even IMO, but maybe
there's the germ of an idea there?  For example you could tell
contributors that if the "has patch" flag isn't set, the patch won't
get noticed by anybody.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Martin v. Löwis wrote:
>>> Oh, I realized that there is a component called "Unicode". So it should be
>>> possible to write a request to list all issues related to unicode.
>>
>> Nice, I'll add set this component for issues that don't have it. I can
>> still add people to these issues, if they want.
>
> We can also add more components if this would support your triage.
>
> As a necessary condition, I'd ask that there would be a "significant"
> number of issues classified under such a new component.

Thanks, Martin. I don't have any request for new components so far,
but would be happy to set new ones that might be created from other
people's suggestions. I think some statistics could help us.

I have a couple of suggestions regarding the UI, I should submit
issues and patches to the meta-tracker sometime next week (got a
python-dev instance running here, but haven't even looked at it).
Mostly things like checkboxes for components, 'no version' being
displayed, easier searches for missing/nothing (-1, right?), and a
'search in all issues' button for logged in users.

Now, getting into pie-in-the-sky territory, if someone (not logged in)
 was to download all issues for scrapping and feeding to a local
database, what time of day would be less disastrous for the server? :)

Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Brett Cannon wrote:
> Sounds like a "*verify issue* stage is needed. Although I guess I kind of
> assumed as part of the triage issue verification would happen as well, but
> that might be too much as a single step.

I'd rather think about it a bit more, available stages cover the vast
majority of the issues. When more people have spent spend some time
setting and querying stages, new ones will be proposed to fill
eventual gaps.

> All the other ones can use the current stages (e.g. a missing test with
> a patch is still at a *test needed* stage, it just happens to be able to
> skip to review once that test is ready).

Yes, it makes a lot of sense. These milestones will help getting
things done, anything more fine-grained should have a good,
well-thougth use case (tracker-discuss is efficient for this).

I have a couple of ideas for the work I'm doing, but they mostly
revolve around client-side optimizations. Something like a DVCS flavor
to triaging :)

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Martin v. Löwis]

>> Oh, I realized that there is a component called "Unicode". So it should be
>> possible to write a request to list all issues related to unicode.
> 
> Nice, I'll add set this component for issues that don't have it. I can
> still add people to these issues, if they want.

We can also add more components if this would support your triage.

As a necessary condition, I'd ask that there would be a "significant"
number of issues classified under such a new component.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Thu, Feb 12, 2009 at 05:08, Daniel (ajax) Diniz  wrote:

> Brett Cannon wrote:
> > One thing to keep an eye on for old issues, Daniel, is the Stage
> > field. Setting that is nice for Bug Days as people can see what
> > issues still need a test written or could use a review, etc.
>
> OK, I'll try to set a useful Stage for bugs I edit. I'll reread your
> blog post on stages and study the discussion.
>
> > I have a doc I am writing up at
> > http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines
> > what the various Stage values should mean. Feedback from you and
> > anybody else is welcome, although realize it is rough as I was not
> > planning to make this public quite yet.
>
> Looking good, I'll collect doc feedback as I learn Stages better.
>
> Here's some feedback on Stages themselves (still learning, probably
> misguided).
>
> Many old issues have patches without tests, or have patches and tests
> that are outdated. Others have patches (and sometimes tests), but
> aren't confirmed as bugs. So the Stage field would be easier to use if
> it included: 'not reproduced in current releases', 'reproduced, needs
> updating', 'is this really a bug?' (i.e., should I be writing a
> test/confirming or discussing the issue?), 'on hold/blocked' (has a
> blocking dependency).
>

Sounds like a "*verify issue* stage is needed. Although I guess I kind of
assumed as part of the triage issue verification would happen as well, but
that might be too much as a single step.

All the other ones can use the current stages (e.g. a missing test with a
patch is still at a *test needed* stage, it just happens to be able to skip
to review once that test is ready).


>
> I'm not sure those would be useful for new issues, I think handling
> the important cases efficiently is more desirable than tuning the
> workflow for old issues. It's telling that the Stage that caught my
> attention was [triage] :D
>

=)


>
> Thank you for the support and feedback (and Stages guide!), it helps a lot
> :)


Glad it's helpful!

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Victor Stinner wrote:
> Oh, I realized that there is a component called "Unicode". So it should be
> possible to write a request to list all issues related to unicode.

Nice, I'll add set this component for issues that don't have it. I can
still add people to these issues, if they want.

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Victor Stinner]

Le Thursday 12 February 2009 14:10:32, vous avez écrit :
> Victor Stinner wrote:
> > I like everything related to Unicode and the separation of byte and
> > character strings in Python3 :-)
>
> That's a big one. But Ezio  Melotti already asked for Unicode, so I
> have some 75 issues selected and ready to add you two to, but I'll do
> it later today or after 3.0.1 tomorrow. Might find some more until
> then :)

Oh, I realized that there is a component called "Unicode". So it should be 
possible to write a request to list all issues related to unicode.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Victor Stinner wrote:
> I like everything related to Unicode and the separation of byte and character
> strings in Python3 :-)

That's a big one. But Ezio  Melotti already asked for Unicode, so I
have some 75 issues selected and ready to add you two to, but I'll do
it later today or after 3.0.1 tomorrow. Might find some more until
then :)

Anyone else interested in Unicode? There's locale, gettext, codecs,
the Unicode databases, support for Unicode in tools (network protocols
and/or file formats, mostly: email, base64).

Thanks for stepping up!

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Senthil Kumaran wrote:
> For urllib,urllib2 and urlparse related, please add me (orsenthil) to
> nosy list. I should already there.
> I shall test and provide patches.

Great! I always find it harder to test urllib[x] than to fix the bug.
I'm in the process of gluing some tools and scripts together to help
with the search/triage/update process, so I'll add you and Victor a
later today. Might hold until after 3.0.1 (due tomorrow) if having the
tracker less noisy would be better.

In the meantime, other people interested in being added to
urllib,urllib2 and urlparse are eligible for discounted prices :)

Thanks for claiming these!
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Brett Cannon wrote:
> One thing to keep an eye on for old issues, Daniel, is the Stage
> field. Setting that is nice for Bug Days as people can see what
> issues still need a test written or could use a review, etc.

OK, I'll try to set a useful Stage for bugs I edit. I'll reread your
blog post on stages and study the discussion.

> I have a doc I am writing up at
> http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines
> what the various Stage values should mean. Feedback from you and
> anybody else is welcome, although realize it is rough as I was not
> planning to make this public quite yet.

Looking good, I'll collect doc feedback as I learn Stages better.

Here's some feedback on Stages themselves (still learning, probably misguided).

Many old issues have patches without tests, or have patches and tests
that are outdated. Others have patches (and sometimes tests), but
aren't confirmed as bugs. So the Stage field would be easier to use if
it included: 'not reproduced in current releases', 'reproduced, needs
updating', 'is this really a bug?' (i.e., should I be writing a
test/confirming or discussing the issue?), 'on hold/blocked' (has a
blocking dependency).

I'm not sure those would be useful for new issues, I think handling
the important cases efficiently is more desirable than tuning the
workflow for old issues. It's telling that the Stage that caught my
attention was [triage] :D

Thank you for the support and feedback (and Stages guide!), it helps a lot :)

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Victor Stinner]

Hi Daniel,

> Good:
>   Many requested assignments:
> Thanks everyone that asked for bugs. If anyone else wants more,
> just let me know :)

I like everything related to Unicode and the separation of byte and character 
strings in Python3 :-)

I already have some pending issues..

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Senthil Kumaran]

On Thu, Feb 12, 2009 at 4:11 AM, Daniel (ajax) Diniz  wrote:
>
> Now will I'll start verifying, adding tests, updating or closing as
> needed the recently changed old issues, until I've taken a good look
> at these. Then, if there's still time left before Saturday, I'll focus
> on  verifying/flagging more ancient ones.
>
> during-bug-season-every-day-is-bug-day-ly y'rs,

For urllib,urllib2 and urlparse related, please add me (orsenthil) to
nosy list. I should already there.
I shall test and provide patches.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Terry Reedy]

Jim Baker wrote:
+1 on the cleanup: reading the bug description of 
http://bugs.python.org/issue1533164, this will also help Jython. Now I 
know why we see scenarios of package with setup.cfg with optimize=1:


Indeed, this is a well-known issue. Many packages put an "optimize=1" in
their setup.cfg in order to solve it.

Unfortunately that breaks the setup process on Jython, since we don't 
support -O. And unfortunately it's not as easy to ignore the flag 
either, this can then break in other ways.


-  Jim


Add this comment to tracker if you want to be sure anyone reading it 
sees this ;-)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Jim Baker]

+1 on the cleanup: reading the bug description of
http://bugs.python.org/issue1533164, this will also help Jython. Now I know
why we see scenarios of package with setup.cfg with optimize=1:

Indeed, this is a well-known issue. Many packages put an "optimize=1" in
their setup.cfg in order to solve it.

Unfortunately that breaks the setup process on Jython, since we don't
support -O. And unfortunately it's not as easy to ignore the flag either,
this can then break in other ways.

-  Jim


On Wed, Feb 11, 2009 at 2:08 AM, Tarek Ziadé  wrote:

> On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne 
> wrote:
> > On 2009-02-10, Tarek Ziadé wrote:
> >> On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz 
> wrote:
> >>
> >> >
> >> > If anyone is interested in being added as nosy for any category of
> >> > bugs, let me know and I'll do that as I scan the tracker.
> >>
> >> I'll take Distutils related issues,
> >
> > If you could look at a solution for http://bugs.python.org/issue1533164
> > I would be eternally grateful.
>
> ok, that would be the next one I am working on in that case,
>
> Regards
> Tarek
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com
>



-- 
Jim Baker
jba...@zyasoft.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

2009/2/11 Daniel (ajax) Diniz 

> Hi,
>
> Here's a status report about the digging. Thanks  Benjamin, Antoine,
> Martin, Raymond, Guilherme, Georg, Brett, Mark and everyone else for
> helping :)
>
> Good:
>  Many requested assignments:
>Thanks everyone that asked for bugs. If anyone else wants more,
> just let me know :)
>
>  Old issues closed:
>ajaksu2 - 3
>Everyone else - about 14 :)
>
>  Checking and screening:
>> 100 issues on the 'verify and close or update' queue (most of
> what is popping up as changed)
>
> Bad:
>  Assignment mistakes:
>Two issues reassigned to Brett (from MvL and JvR) because I didn't
> see they were already assigned:
> http://bugs.python.org/issue1419652 PyImport_AppendInittab stores
> pointer to parameter
> http://bugs.python.org/issue616247 More documentation for the imp module
>Sorry about that :-/
>

No big deal.


>
> Over-spammig:
>  Sorry, Georg! I only noticed all issues in the Documentation
> component are auto-assigned to you today. This meant dozens of unasked
> for assignments :-/
>

I think Georg at this point is the only auto-assignment.


>
> Now will I'll start verifying, adding tests, updating or closing as
> needed the recently changed old issues, until I've taken a good look
> at these. Then, if there's still time left before Saturday, I'll focus
> on  verifying/flagging more ancient ones.
>

One thing to keep an eye on for old issues, Daniel, is the Stage field.
Setting that is nice for Bug Days as people can see what issues still need a
test written or could use a review, etc. I have a doc I am writing up at
http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the
various Stage values should mean. Feedback from you and anybody else is
welcome, although realize it is rough as I was not planning to make this
public quite yet.


>
> during-bug-season-every-day-is-bug-day-ly y'rs,
>

So true. =)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Raymond Hettinger]

[Daniel (ajax) Diniz]

Now will I'll start verifying, adding tests, updating or closing as
needed the recently changed old issues, until I've taken a good look
at these. Then, if there's still time left before Saturday, I'll focus
on  verifying/flagging more ancient ones.


Thanks for your efforts.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Hi,

Here's a status report about the digging. Thanks  Benjamin, Antoine,
Martin, Raymond, Guilherme, Georg, Brett, Mark and everyone else for
helping :)

Good:
  Many requested assignments:
Thanks everyone that asked for bugs. If anyone else wants more,
just let me know :)

  Old issues closed:
ajaksu2 - 3
Everyone else - about 14 :)

  Checking and screening:
> 100 issues on the 'verify and close or update' queue (most of
what is popping up as changed)

Bad:
  Assignment mistakes:
Two issues reassigned to Brett (from MvL and JvR) because I didn't
see they were already assigned:
http://bugs.python.org/issue1419652 PyImport_AppendInittab stores
pointer to parameter
http://bugs.python.org/issue616247 More documentation for the imp module
Sorry about that :-/

Over-spammig:
  Sorry, Georg! I only noticed all issues in the Documentation
component are auto-assigned to you today. This meant dozens of unasked
for assignments :-/

Now will I'll start verifying, adding tests, updating or closing as
needed the recently changed old issues, until I've taken a good look
at these. Then, if there's still time left before Saturday, I'll focus
on  verifying/flagging more ancient ones.

during-bug-season-every-day-is-bug-day-ly y'rs,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Tarek Ziadé]

On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne  wrote:
> On 2009-02-10, Tarek Ziadé wrote:
>> On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz  
>> wrote:
>>
>> >
>> > If anyone is interested in being added as nosy for any category of
>> > bugs, let me know and I'll do that as I scan the tracker.
>>
>> I'll take Distutils related issues,
>
> If you could look at a solution for http://bugs.python.org/issue1533164
> I would be eternally grateful.

ok, that would be the next one I am working on in that case,

Regards
Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Benjamin Peterson wrote:
> Adding/assigning to me on 2to3 bugs is fine, but usually I notice
> stuff I'm interested in as it rises to the top.

Done, found a couple more. There are also some -3 warnings open, if
that interests you :)

Thanks for the support, I only saw it was a +10 now :D

Cheers,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Tarek Ziadé wrote:
> I'll take Distutils related issues,

Done. Since Akira Kitada is helping with many distutils issues, I'll
skip looking at them for now. Ping me if you need tests or simple
patches :)

Regards,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Brett Cannon wrote:
> Warnings and import for me.

Done. Tomorrow I'll see what I can triage/test in those.

>> Talking about Bug Days, I see lots of easy bugs, some with outdated
>> patches. Is there any plan of doing a Bug Day around PyCon time?
>
> Well, the sprints at PyCon are Bug Days themselves really, although they 
> happen during the week so that tends to cause problems. As of right now there 
> are no plans but someone can obviously plan one if they feel up for it.

OK, sometime later I'll try to flag Easy bugs, then.

Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Stephen Thorne]

On 2009-02-10, Tarek Ziadé wrote:
> On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz  wrote:
> 
> >
> > If anyone is interested in being added as nosy for any category of
> > bugs, let me know and I'll do that as I scan the tracker.
> 
> I'll take Distutils related issues,

If you could look at a solution for http://bugs.python.org/issue1533164
I would be eternally grateful.

-- 
Regards,
Stephen Thorne
Development Engineer
NetBox Blue - 1300 737 060

NetBox Blue is proud to be a sponsor and exhibitor at IBM's Solutions 
Showcase 2009 events. These are held in Perth, Adelaide, Brisbane, Sydney and 
Melbourne in February and March. 
For more details and to register please visit: 
http://www.ibm.com/solutionsshowcase/au


Scanned by the NetBox from NetBox Blue
(http://netboxblue.com/)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Brett Cannon wrote:
> OK, three enthusiastic votes to give them is plenty for me. You should have 
> the Developer role now, Daniel. Let me know if I screwed up at all in 
> switchng the role on for you.

Thanks a lot! Looks like it worked fine :)

Let me try the new thing, then: warnings and import for you, distutils
for Tarek, 2to3 (if any left) for Benjamin and Unicode for Ezio (and
patches for Antoine!).

If anyone else wants to claim or be added to dusty bugs, just give me a shout :)

Cheers,
Daniel
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Tarek Ziadé]

On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz  wrote:

>
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.

I'll take Distutils related issues,

Thank you

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz  wrote:

> [SNIP]
> Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real
> work and people agree the workflow would be better, I'd like to have
> developer rights in the tracker, as per Antoine's suggestion. FWIW, I
> have no problem with the current situation.
>

OK, three enthusiastic votes to give them is plenty for me. You should have
the Developer role now, Daniel. Let me know if I screwed up at all in
switchng the role on for you.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Benjamin Peterson]

On Tue, Feb 10, 2009 at 8:23 AM, Daniel (ajax) Diniz  wrote:
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.

Adding/assigning to me on 2to3 bugs is fine, but usually I notice
stuff I'm interested in as it rises to the top.

> Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real
> work and people agree the workflow would be better, I'd like to have
> developer rights in the tracker, as per Antoine's suggestion. FWIW, I
> have no problem with the current situation.

+10 for tracker access for you. This is the kind of work is something
I think everybody has on their lists and really needs some TLC. Thank
you!



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Brett Cannon]

On Tue, Feb 10, 2009 at 05:23, Daniel (ajax) Diniz  wrote:

> Hi all,
>
> For the past two days I've been doing some housekeeping
> *cough*spamming*cough* on the tracker, mostly on ancient and/or easy
> bugs. So far, ten bugs have been closed (thanks Antoine, Barry,
> Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs
> (below) for closing and added a few simple patches, with a couple more
> pending feedback.
>
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.
>

Warnings and import for me.


>
> Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real
> work and people agree the workflow would be better, I'd like to have
> developer rights in the tracker, as per Antoine's suggestion. FWIW, I
> have no problem with the current situation.
>

It's been asked on python-committers; just have to wait for any potential
objections (really doubt there will be any, though).


>
> Talking about Bug Days, I see lots of easy bugs, some with outdated
> patches. Is there any plan of doing a Bug Day around PyCon time?
>

Well, the sprints at PyCon are Bug Days themselves really, although they
happen during the week so that tends to cause problems. As of right now
there are no plans but someone can obviously plan one if they feel up for
it.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Mark Dickinson]

On Tue, Feb 10, 2009 at 1:23 PM, Daniel (ajax) Diniz  wrote:
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.

Feel free to assign anything math-related (math and cmath modules,
float and complex objects) to me.

Thanks for this!

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Guido van Rossum]

Thanks Daniel! This kind of work is never fun but very much needed and
I'm very glad you did it. A round of applause!!

On Tue, Feb 10, 2009 at 5:23 AM, Daniel (ajax) Diniz  wrote:
> Hi all,
>
> For the past two days I've been doing some housekeeping
> *cough*spamming*cough* on the tracker, mostly on ancient and/or easy
> bugs. So far, ten bugs have been closed (thanks Antoine, Barry,
> Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs
> (below) for closing and added a few simple patches, with a couple more
> pending feedback.
>
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.
>
> Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real
> work and people agree the workflow would be better, I'd like to have
> developer rights in the tracker, as per Antoine's suggestion. FWIW, I
> have no problem with the current situation.
>
> Talking about Bug Days, I see lots of easy bugs, some with outdated
> patches. Is there any plan of doing a Bug Day around PyCon time?
>
> Best regards,
> Daniel
>
> Bugs nominated for express closing:
>
> http://bugs.python.org/issue1103926 email.base64MIME.header_encode vs RFC 1522
>
> http://bugs.python.org/issue727898 Support for sending multipart form data
>
> http://bugs.python.org/issue713169 test_pty fails on HP-UX and AIX
> when run after test_openpty
>
> http://bugs.python.org/issue816059 popen2 work, fixes bugs 768649 and 761888
>
> http://bugs.python.org/issue1911 webbrowser.open firefox 3 issues
>
> http://bugs.python.org/issue1170065 HTTPResponse.getheaders() returns
> lowercased header names
>
> http://bugs.python.org/issue1175686 add "reload" function
>
> http://bugs.python.org/issue779191 BasicModuleLoader behaviour in Python 2.3c2
>
> http://bugs.python.org/issue1327971 HTTPResponse instance has no
> attribute 'fileno'
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker archeology

[Facundo Batista]

2009/2/10 Daniel (ajax) Diniz :

> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.

Anything related to Decimal, add me.

Thanks!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tracker archeology

[Daniel (ajax) Diniz]

Hi all,

For the past two days I've been doing some housekeeping
*cough*spamming*cough* on the tracker, mostly on ancient and/or easy
bugs. So far, ten bugs have been closed (thanks Antoine, Barry,
Benjamin, Guilherme, Martin and Raymond). I nominated some other bugs
(below) for closing and added a few simple patches, with a couple more
pending feedback.

If anyone is interested in being added as nosy for any category of
bugs, let me know and I'll do that as I scan the tracker.

Iff this kind of Bug-Day-ish work is desirable, doesn't disrupt real
work and people agree the workflow would be better, I'd like to have
developer rights in the tracker, as per Antoine's suggestion. FWIW, I
have no problem with the current situation.

Talking about Bug Days, I see lots of easy bugs, some with outdated
patches. Is there any plan of doing a Bug Day around PyCon time?

Best regards,
Daniel

Bugs nominated for express closing:

http://bugs.python.org/issue1103926 email.base64MIME.header_encode vs RFC 1522

http://bugs.python.org/issue727898 Support for sending multipart form data

http://bugs.python.org/issue713169 test_pty fails on HP-UX and AIX
when run after test_openpty

http://bugs.python.org/issue816059 popen2 work, fixes bugs 768649 and 761888

http://bugs.python.org/issue1911 webbrowser.open firefox 3 issues

http://bugs.python.org/issue1170065 HTTPResponse.getheaders() returns
lowercased header names

http://bugs.python.org/issue1175686 add "reload" function

http://bugs.python.org/issue779191 BasicModuleLoader behaviour in Python 2.3c2

http://bugs.python.org/issue1327971 HTTPResponse instance has no
attribute 'fileno'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com