Friendpaste

--- Revision None
+++ Revision 326563653164
@@ -0,0 +1,44 @@
+On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby <pje@telecommunity.com> 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.
+
+> 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.
+
+That's great, but I don't think it solves the structural problem,
+which is that you don't have enough time to devote to the project.
+
+--
+--Guido van Rossum (home page: http://www.python.org/~guido/)
a	b
	0	+	On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby <pje@telecommunity.com> wrote:
	0	+	> At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
	0	+	>>>
	0	+	>>> To put this into a way that makes sense to me: I'm volunteering to keep
	0	+	>>> distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and
	0	+	>>> keep that as uncontroversial as possible, and get setuptools 0.6 releases
	0	+	>>> out to match distribute 0.6 releases as soon as I can.
	0	+	>
	0	+	> That may not be as easy as it sounds; Distribute deleted various things from
	0	+	> the setuptools tree (e.g. the release.sh script, used for issuing releases)
	0	+	> and of course it adds other stuff (e.g. stuff to overwrite setuptools). So
	0	+	> you'd need to screen the diffs.
	0	+	>
	0	+	> Second, I still intend to move setuptools 0.7 forward at some point, which
	0	+	> means the patches also need to go to the trunk.
	0	+
	0	+	Dream on.
	0	+
	0	+	> If I had the time to co-ordinate and supervise all this, I'd have the time
	0	+	> to just do it myself.
	0	+
	0	+	I think at this point the community should not be forced wait for you
	0	+	to get a new supply of round tuits. The wait has been too long
	0	+	already. You can stay on in an advisory role, but I don't think it's
	0	+	reasonable to block development or decisions until you have time.
	0	+
	0	+	> If you want to help with that, the most helpful thing would be for you to
	0	+	> consolidate all the changes into a pair of patches: one for the 0.6 branch
	0	+	> and one for the 0.7 trunk.
	0	+	>
	0	+	> These patches would also need to exclude the SVN 1.6 changes (as I already
	0	+	> have a change for that in my working copy, not yet checked in). They would
	0	+	> also need to include appropriate changelog and documentation updates.
	0	+	>
	0	+	> If you can get those to me by Friday, I'll have them reviewed, applied, and
	0	+	> released by Monday. I was already planning to spend a little time on bug
	0	+	> closing and patch application this coming weekend, so if you can do this for
	0	+	> me first, it will maximize the number I can get done.
	0	+
	0	+	That's great, but I don't think it solves the structural problem,
	0	+	which is that you don't have enough time to devote to the project.
	0	+
	0	+	--
	0	+	--Guido van Rossum (home page: http://www.python.org/~guido/)
...