At 07:52 AM 9/25/2008 +0200, Tarek Ziadé wrote:
Anyway, that sounds great indeed. But since setuptools is not on the top of your priority sometimes (you said it wasn't, and we could see it wasn't), are those people blessed to release it as well ?
I don't see a problem with that, although the actual release process itself is nearly 100% automated. (See the 'release.sh' file.) Assuming that there is a releasable distribution in SVN, it takes maybe 15 minutes for me to cut a release and bump the version, if that long. (And it could probably be further automated.)
By the way, you'll notice if you inspect the distutils-sig archives carefully, I'm *extremely* responsive when people post questions or report bugs that haven't been previously answered or fixed. I simply don't have a lot of time to drive new development.
There are few people qualified to do the design vetting and testing that needs to happen for major new features to be added atop the existing code base, and that's 100% independent of any forking. If the persons existed who could actually do this, there is no technical reason why they couldn't have been doing it prior to the fork. (Which leads me to believe that they don't exist or have the time, and thus, the fork will not actually help anything.)
Personally, I would rather see not a "fork", but development of an entirely new disutils replacement, and then not worry at all about backward compatibility at the setup.py level. Apart from the pkg_resources module, I would treat setuptools and distutils as legacy infrastructure, and explore better ways to build and manage distributions (including eggs).
If I had the time, that's what I'd be doing.
I mean, if we have a clear roadmap of the next releases of setuptools, with dates, and if you are unable to release it yourself, can we count on them to do so ? If so I'd be more than happy to stop that fork, and to continue happily to work in the bug tracker if I have a visible roadmap.
Feel free to create such a roadmap; as you can see, I do have time to answer a few emails and give feedback. And if somebody responsible wants to take over the job of deciding whether a release is "ready", I can certainly pull the trigger.
The bottleneck is not me per se; it's having qualified parties. In the long run, having more tests would help a lot with that, as I've said before. In the short run, it's people with strong multi-platform, multi-distribution, multi-project, multi-Python-version experience that are sorely lacking in the patch contribution, vetting, and design departments.
And right now, the only way for me to evaluate such contributors is on the basis of their submitted patches and design proposals... which are few and far between. Historically, most of the patches I get are poorly thought-out even on the level of what the patch does for that one person; i.e., there will be cases that that very person will have problems with, let alone what problems other people will have. This does not give me great hope for the viability of a fork whose expressed purpose is to accept more patches, faster. :)
(This situation is due largely to the flexibility of distutils, by the way. The distutils accepts an utterly ridiculous number of possible source trees, for example. It also supports a ridiculous number of installation targets, formats, etc. On the other hand, this same flexibility also makes it virtually impossible for a competitor to "take over the market" unless it provides near-100% backward compatibility, as setuptools does.)
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
