<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Sep 25, 2008 at 12:36 AM, Phillip J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 11:56 PM 9/24/2008 +0200, Tarek Ziadé wrote:<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Sep 24, 2008 at 11:34 PM, Phillip J. Eby <<mailto:<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>><a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>> wrote:<br>
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.<br>
<br>
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 automated.)<br>
<br>
The point is that the stability you are claiming means that the whole community depends on your actions. The fact that you were busy<br>
lately made things even slower.<br>
</blockquote>
<br></div>
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. ;-)<div class="Ih2E3d">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
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).<br>
<br>
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.</blockquote><div><br> iirc Jim just worked on a particular point back then.<br>
<br>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 ?<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
(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.)</blockquote><div><br>I understand, and I would prefer not having to fork. But I don't want to be locked on this particular area because a package depends on some persons that are busy elsewhere. imho setuptools became a sensible package used by many developers; so unless it opens a bit I don't see how this is going to work. It really need to be boosted at this point.<br>
<br>Tarek<br></div></div><br>-- <br>Tarek Ziadé | Association AfPy | <a href="http://www.afpy.org">www.afpy.org</a><br>Blog FR | <a href="http://programmation-python.org">http://programmation-python.org</a><br>Blog EN | <a href="http://tarekziade.wordpress.com/">http://tarekziade.wordpress.com/</a><br>
</div>