Revision 326563653164 () - Diff

Link to this snippet: https://friendpaste.com/2oin5vpeFnRvnDIjZ8WXqb
Embed:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
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/)