On Jul 1, 2011, at 2:06 PM, Tom Davis wrote:

On Jul 1, 2011, at 1:41 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:

On Jul 1, 2011, at 1:08 PM, chris wrote:

doing continuous development based on tools like 
svn and trac is really painful and it's really difficult to motivate 
yourself to work on a once rejected ticket

Can you be more specific, please?  What's painful?

I always found it especially irritating to come back to a patch later. If I don't already have a patched checkout of Twisted, I need to figure out what revision I was at before (or to actually be safe, make a HEAD checkout), then reapply my patch, hoping it is still valid.  

With a fork I can check it out any time, rebase to the current master (or branch I'm working on), having my changes reapplied for me. When I have made more changes I just push it up. No changes to tickets or switching keywords or watching Trac reject my patch file 10 times then clearing all my cookies or whatever.

Wow, does that actually happen?  The rejecting the patchfile, I mean.  That's terrible.

In any case, that should not be important.  You _should_ be able to use the DVCS of your choice to work on Twisted.[1]  As I said in the previous message:

Plus, you can use the DVCS of your choice to actually author the patch.

Lots of people do submit patches using Git; I reviewed one earlier this week.

One thing I think this thread has inspired is a prompt move to make it clearer how to do this.  It would be great if you could help out lvh in producing some good copy for the various workflow-documentation pages so that it's clear to people how to use their favorite VCS if they already have one; the SVN-based diff-and-ptach instructions that are already there are meant for users who may not be familiar with _any_ kind of version control.  (Just to forestall any objections: this is a realistic audience, lots of Twisted contributors have been in secondary school when they started.)

I've always admired Twisted's standards and process; I think they have made it possible for such a huge project to maintain working order for so long. The tools could use an upgrade, though.

Thanks for that :).  And my earlier post notwithstanding, I agree.  In fact, the tools have improved significantly, but many of them are things that contributors don't see (build system upgrades, release process improvements) but core developers, and therefore eventually users, do benefit from.


[1]: Your choice, of course, should be Bazaar, as all other choices are wrong.  But we can work around your Git habit ;-).