[Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

M.-A. Lemburg mal at egenix.com
Sun Aug 16 16:36:10 CEST 2015


On 16.08.2015 16:08, Guido van Rossum wrote:
> I presume the issue here is that Hg is so complicated that everyone knows a
> different subset of the commands and semantics.
> 
> I personally don't know what the commands for cherry-picking a revision
> would be.
> 
> I also don't know exactly what happens when you merge a PR using bitbucket.
> (I'm only familiar with the GitHub PR flow, and I don't like its behavior,
> which seems to always create an extra merge revision for what I consider as
> logically a single commit.)
> 
> BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I
> see (in a very big bold font) is "This is Python version 3.6.0 alpha 1".
> What's going on here? It doesn't inspire confidence.

You are probably looking at the default branch within that repo fork.

This is the 3.5 branch:

https://bitbucket.org/larry/cpython350/branch/3.5

> On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings <larry at hastings.org> wrote:
> 
>>
>>
>> So far I've accepted two pull requests into bitbucket.com/larry/cpython350
>> in the 3.5 branch, what will become 3.5.0rc2.  As usual, it's the
>> contributor's responsibility to merge forward; if their checkin goes in to
>> 3.5, it's their responsibility to also merge it into the
>> hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch
>> (which right now is 3.6).
>>
>> But... what's the plan here?  I didn't outline anything specific, I just
>> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and
>> merging.  But of the two pull requests so far accepted, one was merged this
>> way, though it cherry-picked the revision (skipping the pull request merge
>> revision Bitbucket created), and one was checked in to 3.5.1 directly (no
>> merging).
>>
>> I suppose we can do whatever we like.  But it'd be helpful if we were
>> consistent.  I can suggest three approaches:
>>
>>    1. After your push request is merged, you cherry-pick your revision
>>    from bitbucket.com/larry/cpython350 into hg.python.org/cpython and
>>    merge.  After 3.5.0 final is released I do a big null merge from
>>    bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>>    2. After your push request is merged, you manually check in a new
>>    equivalent revision into hg.python.org/cpython in the 3.5 branch.  No
>>    merging necessary because from Mercurial's perspective it's unrelated to
>>    the revision I accepted.  After 3.5.0 final is released I do a big null
>>    merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython.
>>    3. After your push request is merged, you pull from
>>    bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge
>>    into 3.5.  In this version I don't have to do a final null merge!
>>
>> I'd prefer 3; that's what we normally do, and that's what I was
>> expecting.  So far people have done 1 and 2.
>>
>> Can we pick one approach and stick with it?  Pretty-please?
>>
>>
>> */arry*
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>>
>>
> 
> 
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 16 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2015-08-12: Released mxODBC 3.3.4 ...             http://egenix.com/go80
2015-08-22: FrOSCon 2015 ...                                6 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the Python-Dev mailing list