On 04:23 pm, wolfgang.kde@rohdewald.de wrote:
Am Sonntag, 5. Oktober 2014, 13:48:12 schrieb exarkun@twistedmatrix.com:
On 3 Oct, 11:09 pm, wolfgang.kde@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