[Twisted-Python] porting twisted.spread to Python3

[exarkun at twistedmatrix.com]

On 04:23 pm, wolfgang.kde at rohdewald.de wrote:
>Am Sonntag, 5. Oktober 2014, 13:48:12 schrieb 
>exarkun at twistedmatrix.com:
>>On 3 Oct, 11:09 pm, wolfgang.kde at rohdewald.de wrote:
>> >I now have a local git branch with about 70 commits, always
>> >rebased onto current trunk.
>>
>>It makes me sad to learn you're carrying so many patches to Twisted. 
>>It
>>might be useful to the project if you could share why this development
>>was easier to do outside the tree rather than contributing it to the
>>project as you developed it.
>
>This is just my personal style of development. A bit chaotic. Sometimes
>trial and error. And really a lot of git rebase -i. Whenever I find
>some necessary or helpful change that could be done before porting,
>put that at the top of the patch list and readjust everything.
>The methodic part comes last: Look at what I changed, rethink why that
>is really needed, and look for similar places I overlooked. Then 
>generate
>tickets for things that seem ready.
>
>BTW what about Ticket 7628, news extension "port"? I could soon start
>feeding porting tickets but if this extension is useful, I guess it
>should be applied first.

Looks like Kevin is working on it.  I'll review it when it comes up.
>
>>I think that before the Twisted project wants to call a particular
>>module ported, we want it to have test coverage that can run on Python
>>3.
>
>I was afraid you'd say that.
>https://twistedmatrix.com/trac/wiki/Plan/Python3 does not explicitly
>say so, maybe this should be changed. I can do that, but then I
>have no write permission for the wiki.

Ah.  I didn't think anyone was paying any attention to the plan anymore 
(and I've run out of energy to try to get people to stick to it).

For example, following the plan, I would have expected to see perhaps 
two patches to port the banana module: one to add the missing test 
coverage and one to make any and all changes necessary to get the test 
suite to pass on Python 3.

(Note, I'm just pointing this out for the sake of clarity.  I'm not 
complaining about the tickets/patches you recently contributed.  As I 
said, I'm out of energy for that).

As far as wiki access goes, I'm not clear on how those permissions work 
anymore.  Perhaps someone else can chime in.  If not, consider asking on 
#twisted-dev.
>
>>I'll let other people volunteer projects they know of - but I strongly
>>suspect there are few or no such applications.
>
>That makes me wonder if I really should have used PB at all. But
>now I do and have no plans to change that.

Sorry about this.  For anyone who's reading and thinking about starting 
a project, I personally recommend you not use PB.  It's almost certainly 
not the right tool to solve the problem you have (if you think your 
problem is so unique and challenging it needs a tool like PB, maybe it 
is!  Feel free to start a discussion about the specifics on this list. 
Maybe you've got one of the rare problems where PB makes sense.)
>
>>Again, it seems unfortunate that you have all of this work ...
>>somewhere.  Somewhere only you  (as far as I can tell) can see it.
>>Somewhere only you can test it.  Somewhere only you can work on it and
>>get it contributed to Twisted.
>
>I believe I saw some mailing list posts where many years ago somebody
>said he has spread running with PY3 but as it seems nothing of that
>got into trunk. Be assured that I want to avoid that.
>
>What is the preferred place for Twisted public repositories?
>No svn please, only git.

Anywhere public.  Collaboration can't take place when things are 
private.
>
>But first I want to do some more cleaning and reshuffling, I cannot
>really do that anymore with commits already pushed to a public
>repository. Maybe 2 or 3 weeks.

Pushing something isn't a promise not to abandoning, screw it up, rebase 
it, delete it later, whatever.

I think that the notion that before something is shared it has to be 
carefully arranged and re-arranged to make it look like it was developed 
by an all-knowing, all-programming super being.

Real software doesn't get built one perfect, self-contained step at a 
time.  The construction of real software is messy.

Jean-Paul