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.)