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

[Guido van Rossum]

As far as I'm concerned I'm just waiting for your decision now.

On Mon, Dec 1, 2014 at 7:07 AM, Brett Cannon <brett at python.org> wrote:

>
>
> On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum <guido at python.org>
> wrote:
>
>> Can we please stop the hg-vs-git discussion? We've established earlier
>> that the capabilities of the DVCS itself (hg or git) are not a
>> differentiator, and further he-said-she-said isn't going to change
>> anybody's opinion.
>>
>
> +1 from me as well. I view this as a discussion of platforms and not DVCSs.
>
>
>>
>> What's left is preferences of core developers, possibly capabilities of
>> the popular websites (though BitBucket vs. GitHub seems to be a wash as
>> well), and preferences of contributors who aren't core developers (using
>> popularity as a proxy). It seems the preferences of the core developers are
>> mixed, while the preferences of non-core contributors are pretty clear, so
>> we have a problem weighing these two appropriately.
>>
>> Also, let's not get distracted by the needs of the CPython repo, issue
>> tracker, and code review tool. Arguments about core developers vs.
>> contributors for CPython shouldn't affect the current discussion.
>>
>> Next, two of the three repos mentioned in Donald's PEP 481 are owned by
>> Brett Cannon, according to the Contact column listed on hg.python.org. I
>> propose to let Brett choose whether to keep these on hg.python.org, move
>> to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm
>> tired of the whole thread." :-)
>>
>
> You do one or two nice things for python-dev and you end up being saddled
> with them for life. ;)
>
> Sure, I can handle the devguide and devinabox decisions since someone has
> to and it isn't going to be more "fun" for someone else compared to me.
>
>
>>
>> The third one is the peps repo, which has python-dev at python.org as
>> Contact. It turns out that Nick is by far the largest contributor (he
>> committed 215 of the most recent 1000 changes) so I'll let him choose.
>>
>
> "Perk" of all those packaging PEPs.
>
>
>>
>> Finally, I'd like to get a few more volunteers for the PEP editors list,
>> preferably non-core devs: the core devs are already spread too thinly, and
>> I really shouldn't be the one who picks new PEP numbers and checks that
>> PEPs are well-formed according to the rules of PEP 1. A PEP editor
>> shouldn't have to pass judgment on the contents of a PEP (though they may
>> choose to correct spelling and grammar). Knowledge of Mercurial is a plus.
>> :-)
>>
>
> And based on how Nick has been talking, will continue to be at least in
> the medium term. =)
>
> -Brett
>
>
>>
>> On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>>>
>>> > On Nov 30, 2014, at 7:43 PM, Ben Finney <ben+python at benfinney.id.au>
>>> wrote:
>>> >
>>> > Donald Stufft <donald at stufft.io> writes:
>>> >
>>> >> It’s not lost, [… a long, presumably-accurate discourse of the many
>>> >> conditions that must be met before …] you can restore it.
>>> >
>>> > This isn't the place to discuss the details of Git's internals, I
>>> think.
>>> > I'm merely pointing out that:
>>> >
>>> >> The important thing to realize is that a “branch” isn’t anything
>>> >> special in git.
>>> >
>>> > Because of that, Ethan's impression – that Git's default behaviour
>>> > encourages losing history (by re-writing the history of commits to be
>>> > other than what they were) is true, and “Git never loses history”
>>> simply
>>> > isn't true.
>>> >
>>> > Whether that is a *problem* is a matter of debate, but the fact that
>>> > Git's common workflow commonly discards information that some consider
>>> > valuable, is a simple fact.
>>> >
>>> > If Ethan chooses to make that a factor in his decisions about Git, the
>>> > facts are on his side.
>>>
>>> Except it’s not true at all.
>>>
>>> That data is all still there if you want it to exist and it’s not a real
>>> differentiator between Mercurial and git because Mercurial has the
>>> ability
>>> to do the same thing. Never mind the fact that “lose” your history makes
>>> it
>>> sound accidental instead of on purpose. It’s like saying that ``rm
>>> foo.txt``
>>> will “lose” the data in foo.txt. So either it was a misunderstanding in
>>> which case I wanted to point out that those operations don’t magically
>>> lose
>>> information or it’s a purposely FUDish statement in which case I want to
>>> point out that the statement is inaccurate.
>>>
>>> The only thing that is true is that git users are more likely to use the
>>> ability to rewrite history than Mercurial users are, but you’ll typically
>>> find that people generally don’t do this on public branches, only on
>>> private
>>> branches. Which again doesn’t make much sense in this context since
>>> generally
>>> currently the way people are using Mercurial with CPython you’re using
>>> patches to transfer the changes from the contributor to the committer so
>>> you’re
>>> “losing” that history regardless.
>>>
>>> ---
>>> Donald Stufft
>>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>>
>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141201/f53c9bd5/attachment-0001.html>