[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github (original) (raw)

Brett Cannon brett at python.org
Mon Dec 1 16:07:47 CET 2014

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>

More information about the Python-Dev mailing list