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

[Brett Cannon]

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141201/b31b3e46/attachment.html>