On Wed Jan 14 2015 at 4:08:52 PM Demian Brecht <demianbre...@gmail.com> wrote:
> 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 [1] > > Commit changes to httlib3 > > Generate patch for CPython > > Import patch to local CPython > > Run unit tests [1] > > Generate hg patch (patchA) for submission to bug tracker > > Upload patchA > > patchA is reviewed > > Implement review changes and generate patchB [1] > > 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
