[Python-Dev] API refactoring tracker field for Python4

[Giampaolo Rodolà]

> Module split:
>  try to get all issues for 'os' module
>  try to subscribe to all commits for 'CGIHTTPServer'

+1
I've been thinking about such a thing as well and I think it would be useful.
Every now and then I go to the bug tracker to see whether the modules
I usually maintain (mainly ftplib, asyncore, asynchat) need some
attention.
I do this by using the plain text search but a select box containing
all the module names would be better.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/


2011/1/7 anatoly techtonik <techtonik at gmail.com>:
> On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
>>>
>>> There are many API changes and proposals that were forgotten and
>>> didn't get into Python 3, although they should be, because it was the
>>> only chance to change things with backwards compatibility break. For
>>> example http://bugs.python.org/issue1559549
>>
>> That can be added in 3.3.
>> To answer your comment on the issue: no investigation is needed. It didn't
>> make it in yet because there was no code written for it. It's really not a
>> big deal, it happens all the time.
>
> Don't you think that if more people were aware of this issue, the
> patch could be made faster?
>
>>> This happened, because of poor bug management, where community doesn't
>>> play any role in determining which issues are desired.
>>
>> The community absolutely plays a role in determining which issues are
>> desired. They do this by action when they want something. A patch says a
>> whole lot about desire.
>>
> Don't you think that if people could review issues and "star" them
> then such minor issues could be scheduled for release not only by
> "severity" status as decided be release manager and several core
> developers, but also by community vote?
>
> Patch requires time, experience and approved contribution agreement,
> which you've sent using ground mail beforehand. Voting doesn't require
> any of this, but helps core developers see what user community wants.
> With the list of desired features Jesse Noller sponsored sprints will
> have more value for all of us.
>
>>>
>>> This mostly because of limitation of our tracker and desire of people
>>> to extend it to get damn "stars", module split, sorting, digging and
>>> tagging options.
>>
>> I have no idea what any of this means.
>
> Stars:
>  go http://code.google.com/p/support/issues/list
>  find Stars column
>  guess
>
> Module split:
>  try to get all issues for 'os' module
>  try to subscribe to all commits for 'CGIHTTPServer'
>
> Sorting:
>  click on column titles in bug tracker search results
>
> Tagging:
>  as a tracker user, try to add tag 'easy' to some easy issue
>
>>>
>>> I won't be surprised if things won't change in the next couple of
>>> years, that's why I'd like to propose a very small change, so that
>>> when time will come to create Python4 (and standard library won't be
>>> separated from interpreter by this time), everybody can get quickly
>>> get a list of proposed API enhancements and filter which are eligible
>>> for the next BC API break. This change is a simple "api-refactoring"
>>> flag that could be added to corresponding issues by tracker users.
>>
>> I'm not sure I see the need for such a flag, as there are probably too few
>> cases for this in the first place.
>
> I haven't started using Python 3 yet, but I already know some annoying
> API issues that are not fixed there. Unfortunately, I don't remember
> them to give you a list. That's why I asked for a flag.
> --
> anatoly t.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>