[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Pierre-Yves David]

On 11/30/2014 08:30 AM, Donald Stufft wrote:
>
>> On Nov 30, 2014, at 2:08 AM, Larry Hastings <larry at hastings.org
>> <mailto:larry at hastings.org>> wrote:
>>
>>
>> On 11/29/2014 04:37 PM, Donald Stufft wrote:
>>> On Nov 29, 2014, at 7:15 PM, Alex Gaynor<alex.gaynor at gmail.com>  wrote:
>>>> Despite being a regular hg
>>>> user for years, I have no idea how to create a local-only branch, or a branch
>>>> which is pushed to a remote (to use the git term).
>>> I also don’t know how to do this.
>>
>> Instead of collectively scratching your heads, could one of you guys
>> do the research and figure out whether or not hg supports this
>> workflow?  One of the following two things must be true:
>>
>>  1. hg supports this workflow (or a reasonable fascimile), which may
>>     lessen the need for this PEP.
>>  2. hg doesn't support this workflow, which may strengthen the need
>>     for this PEP.
>>
>> Saying "I've been using hg for years and I don't know whether it
>> supports this IMPORTANT THING" is not a particularly compelling argument.
>>
>
> Comments like this make me feel like I didn’t explain myself very well
> in the
> PEP.
>
> While I do think that supporting this workflow via an extension is worse
> than
> supporting it in core,

I was about to point that bookmark are no longer an extension for more 
than 3 years, but someone was faster than me.

But I would like to reply a bit more on this extension FUD. There is 
three kind of Mercurial feature:

1) The one in Mercurial core
2) The one in official extension
3) the one in third party extension

(1) and (2) Have the -same- level of support and stability. All of them 
are part of the same repo and same test suite, offer the same backward 
compatibility promise and are installed as part of the same package.

Official extensions are usually not in core for various reasons:

1) It is exotic feature (eg: communication bugzilla extension)
2) Nobody did the work to move it into core (unfortunatly) (eg: progress 
bar extension) (similar situation: how long did it took to get pip 
shipped with python?)
3) We think it is a important feature but we are not happy with the 
current UX and would like somethign better before moving it into core 
(eg: histedit)

Not using official extensions because they are extensions is similar to 
not use the python standard library because "They are modules, not part 
of the core language"

> this isn’t why this PEP exists. The current
> workflow for
> contributing is painful, for the repositories this is talking about if I’m a
> non-comitter I have to email patches to a particular closed mailing list and
> then sit around and wait.

Your workflow issue does not seems to be particularly tied to the tool 
(Mercurial) itself but more to (1) very partial usage of the tool (2) 
current project workflow. It would not be hard to (1) use the tools in a 
less painful way (2) rethink project workflow to reduce the pain. This 
seems orthogonal to changing the tool.

> The Pull Request based workflow is *massively* better than
> uploading/emailing
> patches around. So the question then becomes, if we're going to move to a PR
> based workflow how do we do it? PEP 474 says that we should install some
> software that works with Mercurial and supports Pull Requests. Another
> thread
> suggested that we should just use to bitbucket which also supports
> Mercurial
> and use that.

(note: Yes Manual upload of patch is terrible and tracking email by 
patch is terrible too. But github is fairly bad at doing pull request. 
It emphasis the final result instead of the actual pull request content. 
Encouraging massive patches and making the history muddier.)

> This PEP says that git and Github have the popular vote, which is extremely
> compelling as a feature because:

Sure, Git//Github is more popular than Mercurial nowaday. But can I 
point to the irony of Python using the "more popular" argument? If most 
of people here would have seen this definitive argument, they would been 
currently writing Java code instead of discussing Python on this list.

-- 
Pierre-Yves David