P.J. Eby writes:

Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't even object to him Pronouncing it or cutting off the discussion! My only issue on Python-Dev was his inaccurate implication that it was a SIG consensus rather than a pronouncement on it. There is and was no need for any of this to get personal, and I have continually strived to keep my posts here and distutils-sig civil, even when I didn't feel like being civil in response to Tarek's jabs. I have in fact bent over backwards to be *nice* to Tarek, because he seemed so damn sensitive about everything. Apparently, however, this does not actually help things.

Ok, so Tarek and Philip, are you both ok that those little disagreements should belong to the past now? :) Philip did an important job in bringing setuptools to the Python community, and Tarek took a difficult decision when he finally decided to fork setuptools (he had probably been privately encouraged for months by people like me, and was still reluctant to do it AFAICT). Both of you have been tremendously helpful to Python, and I'm sure we can move forward graciously. Regards Antoine.

P.J. Eby wrote:

Here's what actually happened, if anyone cares. Tarek and friends announced a fork of setuptools. I reviewed the work and saw that -- for the most part -- I was happy with it, and opined as how I might be willing to bless the the "package inquisition" team as official maintainers of the 0.6 branch of setuptools, so that I could work on the fun bits I've long planned for 0.7, but never felt free to start on while there was so much still needing to be done on 0.6.

If this offer is still available, I'd lake to take you up on it. I'd be more than willing to merge changes on the 0.6 distribute branch back into the setuptools codebase and do whatever is needed to get a new setuptools release out. Why? Because there are a *lot* of copies of ez_setup.py and buildout's bootstrap.py that will need replacing if it doesn't happen. I think it'd be better for the python community all round if setuptools just continued in maintenance mode until whatever-ends-up-in-the-core exists and people want to use... I'm happy to submit to whatever supervision is needed for you to trust me to do this, and I promise to be as careful as I can with this. I *know* how important this is and want to make it work...

All I want is for good stuff to happen for setuptools users and Python users in general, so I don't think all the suspicion and backbiting is merited.

Fine, if that's true, I apologize (even spelled correctly!) for any previous involvement in this, but please help me help you achieve your aims... To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can. Again, I feel I need to stress that the *only* reason I want to do this is to bring the benefits of the distribute work to the existing setuptools codebase, with appropriate attribution if that makes a difference. Apologies if any of this is offensive to anyone. For once (really!) I really mean that :-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:

...

To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.

That may not be as easy as it sounds; Distribute deleted various things from the setuptools tree (e.g. the release.sh script, used for issuing releases) and of course it adds other stuff (e.g. stuff to overwrite setuptools). So you'd need to screen the diffs. Second, I still intend to move setuptools 0.7 forward at some point, which means the patches also need to go to the trunk. If I had the time to co-ordinate and supervise all this, I'd have the time to just do it myself. If you want to help with that, the most helpful thing would be for you to consolidate all the changes into a pair of patches: one for the 0.6 branch and one for the 0.7 trunk. These patches would also need to exclude the SVN 1.6 changes (as I already have a change for that in my working copy, not yet checked in). They would also need to include appropriate changelog and documentation updates. If you can get those to me by Friday, I'll have them reviewed, applied, and released by Monday. I was already planning to spend a little time on bug closing and patch application this coming weekend, so if you can do this for me first, it will maximize the number I can get done.

On Tue, Oct 6, 2009 at 2:16 PM, Guido van Rossum wrote:

On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby wrote:

...

At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:

...

...

To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.

That may not be as easy as it sounds; Distribute deleted various things from the setuptools tree (e.g. the release.sh script, used for issuing releases) and of course it adds other stuff (e.g. stuff to overwrite setuptools).  So you'd need to screen the diffs.

Second, I still intend to move setuptools 0.7 forward at some point, which means the patches also need to go to the trunk.

Dream on.

...

If I had the time to co-ordinate and supervise all this, I'd have the time to just do it myself.

I think at this point the community should not be forced wait for you to get a new supply of round tuits. The wait has been too long already. You can stay on in an advisory role, but I don't think it's reasonable to block development or decisions until you have time.

Is it possible to fork `setuptools` somehow ? This way : - patches may be built for setuptools 0.7 if it evolves - community can continue development in the «new» branch. all this easy if a DVCS is used ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Nabble - Trac Users - Coupling trac and symfony framework - http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-an...