Example of data to collect

[Toshio Kuratomi]

I've put together a few entries for a table of useful information on python3
module status:

http://wiki.python.org/moin/PortingToPy3k/Modules

It involves some labor to create and manage that sort of table so there may
be a better way. Not sure whether the wiki is the best place to track it.

What do people think? There's plenty more information just in Fedora, let
alone the other distros about the python3 module packages that we've created
but it would be nice to figure out what data we're targetting and how we
want to organize it before doing the data entry work.

-Toshio

[Piotr Ożarowski]

[Toshio Kuratomi, 2010-10-26]

Post by Toshio Kuratomi
I've put together a few entries for a table of useful information on python3
http://wiki.python.org/moin/PortingToPy3k/Modules
It involves some labor to create and manage that sort of table so there may
be a better way. Not sure whether the wiki is the best place to track it.
What do people think?

there's similar table on Fedora's wiki¹ and on Debian's², but having a
central place on python.org is a good idea (just added my tiny Mako
patch there). IMO, this page is not the best place for a discussion/questions/etc.
though. I, for example, would want to know why do you invoke `2to3 --write
--nobackups . ` in Beaker - I didn't need that in my package, isn't
use_2to3=True in setup.py enough? Should questions like this be sent to
this mailing list or added to the wiki?

[¹] https://fedoraproject.org/wiki/Features/Python3F13
[²] http://wiki.debian.org/Python/SqueezePy3k

[Piotr Ożarowski]

[Piotr Ożarowski, 2010-10-26]

Post by Piotr Ożarowski
[¹] https://fedoraproject.org/wiki/Features/Python3F13

should be https://fedoraproject.org/wiki/Python3

[Toshio Kuratomi]

Post by Piotr Ożarowski
[Toshio Kuratomi, 2010-10-26]

Post by Toshio Kuratomi
I've put together a few entries for a table of useful information on python3
http://wiki.python.org/moin/PortingToPy3k/Modules
It involves some labor to create and manage that sort of table so there may
be a better way. Not sure whether the wiki is the best place to track it.
What do people think?

there's similar table on Fedora's wiki¹ and on Debian's², but having a
central place on python.org is a good idea (just added my tiny Mako
patch there).

Okay, I'll continue adding the information from Fedora's wiki of known
status. Anyone care to add information from the Debian page? I'll also see
about getting Fedora people to add their information to the python.org page
instead and deprecate the Fedora-specific page so that we don't get out of
sync.

Post by Piotr Ożarowski
IMO, this page is not the best place for a discussion/questions/etc.
though. I, for example, would want to know why do you invoke `2to3 --write
--nobackups . ` in Beaker - I didn't need that in my package, isn't
use_2to3=True in setup.py enough? Should questions like this be sent to
this mailing list or added to the wiki?

I vote mailing list for lack of a better place. Ideally, someone would
bring up the issue:

"Hey, why is running 2to3 on beaker necessary? I don't run it in the
Debian package and it seems to work fine. This is with Beaker version
1.5.3."

Then other people with beaker packages/builds would try it out and say:

"You're right. I just tried it and it works here too. I'll correct it in
our packages as well."

The data on the wiki would be updated for future users and all of the beaker
packagers would be notified and update their packages.

Better than either the mailing list or wiki page would probably be an issue
tracker where we could assign the people building/packaging the modules for
each Linux distribution (and other interested parties) to the issues. That
way we'd be sure that the right people were getting contacted about each
package.

Using the mailing list as the medium, it'll probably fall to certain contact
people to make sure that the right people are being told of these issues
which is less efficient and leads to single points of failure. Doable in
the short term but we'd be better off with something else in the long term.

-Toshio