On 2015-01-14 12:25 PM, Guido van Rossum wrote:
I'm not sure how commit privileges would help you -- can't you just fork the CPython (I'm sure there's already a Bitbucket mirror that you can fork easily) and do your work there? Even with commit privileges you wouldn't be committing partial work unreviewed.
The friendly module fork allows for others to easily (or at least the intention is to do it easily) use the module with the new, backwards compatible features as a drop in replacement for the stdlib module. Giving others the ability to do this would lend itself to the adoption of the module and bug reports and such before upstream patches are produced.
That said, the main downside to the friendly fork is the patch submission process: After changes have been merged to the fork, there's bound to be churn during the upstream patch submission, which would likely lead to something that looks like:
Implement feature/bug fix  Commit changes to httlib3 Generate patch for CPython Import patch to local CPython Run unit tests  Generate hg patch (patchA) for submission to bug tracker Upload patchA patchA is reviewed Implement review changes and generate patchB  Upload patchB [...wait for merge...] Merge delta of patchB and patchA to httplib3 Test/upload new PyPI package
I see commit privileges helping in two ways:
1. I've experienced lag on a few occasions between review and merge. I'm assuming that this is largely due to a lack of dotted line maintainer of the http package (although I believe that the general consensus is that Senthil is the de facto maintainer of the package). Commit privileges would help in getting the patches merged once reviews are complete.
2. It would help my own workflow. While feature development can be done in httplib3, I do also tend to swap between issues in the bug tracker and large feature work. Because I have two lines of work (CPython/bug tracker and Github), I run into issues around where these changes should be made: Should the bug fixes live in CPython/bug tracker or should I fix the issue in httplib3 and go through the submission workflow above? Either way, I'm signing myself up for a good deal of headache managing the httplib3 work, especially when development work across feature branches is dependent on patches submitted to CPython.
I definitely don't mind the extra work if there are no other options, but my end goal is to be a maintainer of the http package and core developer, not to maintain a third party fork.