On Sun, 22 Jan 2006 02:53:12 +0100, Andrea Arcangeli <andrea@cpushare.com> wrote:
if you've pending patches that have not been applied or you've no time for unittests until your project works, you can consider switching to CPUShare-Twisted. Mercurial allows distributed development so we can merge our branches against each other with very little effort.
If you've pending patches that have not been applied, would you please consider instead to agitate for those patches on the mailing lists, and add information to them in the tracker? Discussing an abandoned patch can cast some light where it is needed. Putting it into the CPUShare fork rather than the bugtracker virtually guarantees that no core Twisted developer will ever look at it. Not that you can't do both - I just want to make it clear that we're going to keep working off the bugtracker and SVN, not off of random mercurial (or git or bzr or monotone - not to pick on hg) repositories run by users. Also, Andrea, would you mind making sure that your codebase is visually distinct from Twisted in some way that is identifiable when it is run? My main concern here is that if CPUShare-Twisted is to become popular, it seems likely that users might confuse it with the actual Twisted. Since you have loudly declared your animosity towards filing bugs, I assume CPUShare-Twisted will not have its own bugtracker, and since you are opposed to test-driven development, I am sure that it will be full of bugs. I would prefer it if we could avoid asking the Twisted team to deal with those bugs as well as actual bugs in Twisted, when users discover the only Twisted bugtracker is on twistedmatrix.com. The best option would be to avoid using the same module name, but I understand that tracking trunk would be made more difficult with a diff that touched every import. Perhaps instead you could change the version from SVN-Trunk to 'HG-CPUShare', so that the CPUShare-ness of the code is visible at the beginning of any logs, and change the names of the command line tools to e.g. cpushare-twistd and cpushare-mktap? This would save time since developers could reject bugs immediately upon seeing one of those commands or the telltale log message rather than having to identify that the line numbers are all wrong before doing so.