Hi, On Saturday 12 October 2013 14:19:57 you wrote:
Hi Sascha !
Is there any possibility we (all python maintainers) discuss our goals both python2 and python3 ?
sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you guys prefer it, we could have an IRC meeting at some point but I guess it's easier to stay with mails just now. Therefore I added opensuse-packaging@ because that's really where we should discuss things.
We receive requests sometimes update and/or new packages which are Python3 compatible.
From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling.
Should we allow new packages for devel:languages:python or directly impose python3-only packaging ?
A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people.
I mean we have a lot of packages to maintain, and to do it for both python2 and 3 is long and tedius.
In the long run, py3k will gradually replace py2k in openSUSE, that means if the critical mass is reached and most upstreams moved on, py2k pkgs will slowly fade from Factory. Meanwhile, some pkg upstreams already stopped caring for py2k, so their pkgs simply stay with the last working version. Currently it's more manual work, I agree. A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level. On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-) -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)