On Wed Jan 14 2015 at 4:08:52 PM Demian Brecht <firstname.lastname@example.org
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.
But as Guido pointed out, we _like_ it being difficult to do because we don't want this kind of substitution happening as code ends up depending on bugs and quirks that you may fix.
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.
How many other modules are dependent on the http module in the stdlib that are going to be affected by your changes? One option is you fork http **and** and modules in the stdlib that are dependent on it. You don't really have to change the other modules beyond their import statement of using http -- you can even do `import http3 as http` or something to minimize the changes -- but you at least don't have to monkeypatch sys.modules for others to gain from your http changes. Plus as you patch stuff in http you may find you have/want to patch other dependent modules as well and so you will have already done that.