[Distutils] Annoucing distribute project

Phillip J. Eby pje at telecommunity.com
Thu Sep 25 00:36:03 CEST 2008

At 11:56 PM 9/24/2008 +0200, Tarek Ziadé wrote:
>On Wed, Sep 24, 2008 at 11:34 PM, Phillip J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>In other words, I don't recommend mixing fork goals.  If the goal is 
>merely to have more-frequent releases of setuptools, it would be 
>better to have a snapshot facility for same, and release dev-tagged 
>eggs.  Conversely, if the goal is to prototype new features, then it 
>doesn't make a lot of sense to advertise it as a stable or 
>up-to-date setuptools.
>So, my personal hope is that the persons doing the fork will make it 
>clear to their users which it is: unstable feature prototype, or 
>simple release snapshots?  (Where the latter could just as easily be 
>The point is that the stability you are claiming means that the 
>whole community depends on your actions. The fact that you were busy
>lately made things even slower.

Actually, it was the community that slowed down 0.6c9, in that I 
would have released it last month, except that certain contributors 
were not ready.  As it is, I ended up giving up waiting for one of 
them to come through -- ironically, it was someone who used to 
complain a lot about delays.  ;-)

>  That is my whole point. Even if you set up a snapshot facility, 
> the only person that is able to make changes in setuptools is you 
> and only you.

Sigh.  That's simply not true, as has been discussed here before -- 
more than once.  If you check the commit logs, you'll see that other 
people HAVE made changes to setuptools, and are still quite able to 
do so.  Jim Fulton is already a "blessed" committer, and I'm quite 
close to blessing P. Jenvey (if he wants it).

And, when somebody else steps up with a series of quality patches 
(backed with pre-reviewed specs in the case of features with 
significant interactions), then that person can get blessed too.

>So I'll make it clear to our users: it will be a project with stable 
>releases, and unstable features in branches, and a trunk to merge 
>everything, like all the open source project out there.

Great.  Just please make sure that you ask your contributors and 
users NOT to expect support from me, and to not use the setuptools 
bug tracker for non-setuptools issues.  It's not reasonable to expect 
me to support the fork in addition to the original version.

(I'm also somewhat concerned about what issue the OS vendors will 
blame me or "Python eggs" in general for next, even though I've got 
nothing to do with the fork.)

More information about the Distutils-SIG mailing list