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 <br...@python.org> wrote:
> > > On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum <gu...@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@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 <don...@stufft.io> wrote: >> >>> >>> > On Nov 30, 2014, at 7:43 PM, Ben Finney <ben+pyt...@benfinney.id.au> >>> wrote: >>> > >>> > Donald Stufft <don...@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@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
