[Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)

[Brian Curtin]

On Fri, Jun 18, 2010 at 07:44, anatoly techtonik <techtonik at gmail.com>wrote:

> On Fri, Jun 18, 2010 at 8:07 AM, Stephen Thorne <stephen at thorne.id.au>
> wrote:
> >> We are also attempting to enable tax-deductible fund raising to increase
> >> the likelihood of David's finding support. Perhaps we need to think
> >> about a broader campaign to increase the quality of the python 3
> >> libraries. I find it very annoying that the #python IRC group still has
> >> "Don't use Python 3" in it's topic.  They adamantly refuse to remove it
> >> until there is better library support, and they are the guys who see the
> >> issues day in day out so it is hard to argue with them (and I don't
> >> think an autocratic decision-making process would be appropriate).
> >
> > Yes, #python keeps the text "It's too early to use Python 3.x" in its
> topic.
> > Library support is the only reason.
>
> I do not know what are you intending to do, but my opinion that fund
> raising for patching library is a waste of money. PSF should
> concentrate on enhancing tools to make lives of library supporters
> easier. I do not want to become a maintainer, and I believe there was
> a lot of spam about this topic from me. The latest thread was in
> http://bugs.python.org/issue9008 in short:
>
> `pydotorg` tools - theres is no:
> 1. separate commit notifications for the module with ability to reply
> to dedicated group for review


If you know how to set this up, feel free to implement it.


> 2. separate bug tracker category for my module with giving users
> ability to change every property of it
>

The Python bug tracker isn't the place for "my module".
The second part of this sentence has been brought up and I think it's a good
point. For example, those who lack developer privileges can't assign issues
to themselves. I think Twisted's tracker does well in this area, as the
fields are inclusive rather than exclusive. Assignment is open to anyone
willing to work on it, and the field is used to prod the next responsible
person into acting (I think, correct me if I'm wrong).


> 3. bug tracker timeline for the module that includes ticket changes,
> wiki edits, commits and everything else. Filtered.


That seems like information overload. It might be cool to see all of that,
but I'm not sure what the gain is. Some modules get worked on in spurts and
sometimes modules don't see action for months. It doesn't actually mean
anything, though.


> 4. roadmap page with actual status, plans and coverage
> 5. dashboard page with links to all the above
>

If you know how to do this, you are more than welcome to whip up some code
and show how it would help.

`python development tools`:
> 1. no way to get all related code for the module
>  1.1. source code location (repository, branches)
>  1.2. source code components (source file, tests, documentation)
>

What exactly do you mean? Since you have submitted several issues, some with
patches, I have a hard time believing that you've done all of that work
without knowing where any of that information was.


> 2. no code coverage (test/user story/rfc/pep)
>

If you know of a way to incorporate code coverage tools and metrics into the
current process, I believe a number of people would be interested. There
currently exists some coverage tool that runs on the current repository, but
I'm not sure of its location or status.


> 4. no code review management process
>

I agree, this is an area that could use work. It has been suggested that
Rietveld be incorporated into Roundup both visually ("upload to Rietveld"
button) and as a part of the workflow (possible requirement before commit).
As with many of these comments, lack of time and a lack of available
volunteers are two of many answers as to why there is no traction on this.


> 5. no way to notify interested parties
>

I'm not sure what this is specifically addressing.

anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100618/91ab25fb/attachment.html>