(in other stuff i've worked on testing a deep issue with realtek wireless devices on mini-PCIe bus that wsa recently fixed by kernel developers, helped a Nepal deployment of Sugar to build an operating system, and established a backup in australia of all critical content and git repositories.)

Quozl_: I have a proposal in my email drafts to send to sugar-devel to match up the pinned repos at github.com/sugarlabs with the list of repos you indicated in recent email are either core to sugar, or core activities. The proposal is to create a meta-repo pointing to one or more of these sets, since we are restricted to 6 pinned repos.

so i created a set of repository issues to formally describe the port to Python 3, and this was in response to private mail with a potential contributor who proposed a draft project response for GSoC, which didn't have any scheduling or division of the work.

As far as I know, six is module to provide compatibility to Python3 and Python2, if six is used to port anything, I think parallel support will help as no activity will be affected and subsequent changes in activities can be made.

walter__: yes, that is what we will desire, but the sugar-toolkit-gtk3 shall have both python2 and python3 bindings, so until python2 actually disappears from linux distributions both pythons should work for any activities.

i'm imagining that the sugar-toolkit-gtk3 sources will be built twice by the makefiles and thus the debian and fedora packages; once for python2, once for python3. debian have a strategy of naming packages python-foo for python2, and python3-foo for python3. fedora probably don't have a strategy for mixing python versions, but i'm happy to lose fedora on this.