On 2 December 2014 at 01:38, Guido van Rossum gu...@python.org wrote:
As far as I'm concerned I'm just waiting for your decision now.
The RhodeCode team got in touch with me offline to suggest the
possibility of using RhodeCode Enterprise as a self-hosted solution
rather than a
So I was waiting for Nick to say what he wanted to do for the peps repo
since I view it as I get 2/3 of the choices and he gets the other third.
The way I view it, the options are:
1. Move to GitHub
2. Move to Bitbucket
3. Improve our current tooling (either through new hosting setup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2014 11:50 AM, Brett Cannon wrote:
So do people want PEPs or experimentation first?
I'd vote for experimentation, to ground the discussion in actual practice.
Tres.
- --
===
On Tue, Dec 2, 2014 at 9:23 AM, Tres Seaver tsea...@palladion.com wrote:
I'd vote for experimentation, to ground the discussion in actual practice.
+1. There may be a number of practical gotchas that very well might
not surface in PEPs and should be documented and planned for. Likewise
with
Thanks for taking charge, Brett.
I personally think this shouldn't be brought up at the summit -- it's
likely to just cause lots of heat about git vs. hg, free vs. not-free,
loyalty to free or open tools, the weighing of core committers'
preferences vs. outside contributors' preferences, GitHub's
On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum gu...@python.org wrote:
Thanks for taking charge, Brett.
I personally think this shouldn't be brought up at the summit -- it's
likely to just cause lots of heat about git vs. hg, free vs. not-free,
loyalty to free or open tools, the weighing
On Tue, Dec 2, 2014 at 10:21 AM, Brett Cannon br...@python.org wrote:
On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum gu...@python.org
wrote:
Thanks for taking charge, Brett.
I personally think this shouldn't be brought up at the summit -- it's
likely to just cause lots of heat about
On Tue, 02 Dec 2014 18:21:39 +
Brett Cannon br...@python.org wrote:
So if we did have a discussion at the summit and someone decided to argue
for FLOSS vs. not as a key factor then I would politely cut them off and
say that doesn't matter to me and move on. As I said, I would moderate
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote:
Well, if I'm going to be the Great Decider on this then I can say upfront
I'm taking a pragmatic view of preferring open but not mandating it,
preferring hg over git but not ruling out a switch, preferring Python-based
tools but not viewing it as
On Tue Dec 02 2014 at 1:52:49 PM Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 02 Dec 2014 18:21:39 +
Brett Cannon br...@python.org wrote:
So if we did have a discussion at the summit and someone decided to argue
for FLOSS vs. not as a key factor then I would politely cut them off
On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org wrote:
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote:
Well, if I'm going to be the Great Decider on this then I can say upfront
I'm taking a pragmatic view of preferring open but not mandating it,
preferring hg over git but
On Dec 2, 2014, at 2:09 PM, Brett Cannon br...@python.org wrote:
On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote:
Well, if I'm going to be the Great Decider on this then I can say upfront
On Tue Dec 02 2014 at 2:15:09 PM Donald Stufft don...@stufft.io wrote:
On Dec 2, 2014, at 2:09 PM, Brett Cannon br...@python.org wrote:
On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw ba...@python.org wrote:
On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote:
Well, if I'm going to be the
I should say I will take a few days to think about this and then I will
start a new thread outlining what I think we should be aiming for to help
frame the whole discussion and to give proponents something to target.
On Tue Dec 02 2014 at 2:20:16 PM Brett Cannon br...@python.org wrote:
On Tue
On 12/02/2014 11:21 AM, Brett Cannon wrote:
I should say I will take a few days to think about this and then I will start
a new thread outlining what I think we should be aiming for to help frame the
whole discussion and to give proponents something to target.
Thanks for taking this on,
On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote:
No because only two people have said they like the experiment idea so
that's not exactly enough to say it's worth the effort. =) Plus GitHub
could be chosen in the end.
Experimenting could be useful, although if the traffic is disproportionate
Brett Cannon br...@python.org writes:
Well, if I'm going to be the Great Decider on this then I can say
upfront I'm taking a pragmatic view of preferring open but not
mandating it, preferring hg over git but not ruling out a switch,
preferring Python-based tools but not viewing it as a
On 12/02/2014 08:50 AM, Brett Cannon wrote:
So do people want PEPs or experimentation first?
Experiments are good -- then we'll have real (if limited) data... which is
better than no data. ;)
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
On Tue Dec 02 2014 at 3:14:20 PM Barry Warsaw ba...@python.org wrote:
On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote:
No because only two people have said they like the experiment idea so
that's not exactly enough to say it's worth the effort. =) Plus GitHub
could be chosen in the end.
On Tue, Dec 2, 2014 at 6:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
P.S. I'll also bring up some of the RFEs raised in this discussion
around making it possible for folks to submit pull requests via
GitHub/BitBucket, even if the master repositories are hosted on PSF
infrastructure.
In case
On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon br...@python.org wrote:
So I was waiting for Nick to say what he wanted to do for the peps repo
since I view it as I get 2/3 of the choices and he gets the other third.
The way I view it, the options are:
Move to GitHub
Move to Bitbucket
Improve
Before anyone gets too excited about Rietveld (which I originally wrote as
an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis
can maintain -- and it's a dead-end fork because the Rietveld project
itself only supports App Engine, but Martin's fork runs on our own server
On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org wrote:
Before anyone gets too excited about Rietveld (which I originally wrote as an
APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can
maintain -- and it's a dead-end fork because the Rietveld project
On 12/02/2014 02:47 PM, Donald Stufft wrote:
On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
Before anyone gets too excited about Rietveld (which I originally
wrote as an APp Engine demo), AFAIK we're using a fork that only
Martin von Loewis can
On 3 Dec 2014 08:47, Donald Stufft don...@stufft.io wrote:
On Dec 2, 2014, at 5:42 PM, Guido van Rossum gu...@python.org wrote:
Before anyone gets too excited about Rietveld (which I originally wrote
as an APp Engine demo), AFAIK we're using a fork that only Martin von
Loewis can maintain --
On Sun, 30 Nov 2014 22:06:03 -0500
Terry Reedy tjre...@udel.edu wrote:
If the mirror experiment is successful, the devguide might be the next
experiment. It does not have any one maintainer, and *is* tied to the
tracker. But herein lies the problem with the devguide. There are 22
On 2014-11-30, 11:18 GMT, Ben Finney wrote:
Donald Stufft don...@stufft.io writes:
I think there is a big difference here between using a closed source
VCS or compiler and using a closed source code host. Namely in that
the protocol is defined by git so switching from one host to another
is
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote:
Migrating the DVCS content is usually easy.
This is lovely mantra, but do you speak from your own
experience? I did move rope from Bitbucket to
https://github.com/python-rope and it was A LOT of work
(particularly issues, existing pull
On 2014-12-01, 00:50 GMT, Donald Stufft wrote:
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.
And I would
On Mon, 1 Dec 2014 08:46:46 +0100
Matěj Cepl mc...@cepl.eu wrote:
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote:
Migrating the DVCS content is usually easy.
This is lovely mantra, but do you speak from your own
experience? I did move rope from Bitbucket to
On Sun, Nov 30, 2014 at 02:56:22PM -0500, Donald Stufft wrote:
As I mentioned in my other email, we’re already supporting two
different tools, and it’s a hope of mine to use this as a sort of
testbed to moving the other repositories as well.
If we go down this path, can we have some
On Tue, Dec 02, 2014 at 12:37:22AM +1100, Steven D'Aprano wrote:
[...]
It's one thing to say that using hg is discouraging contributors, and
that hg is much more popular.
/s/more/less/
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
On Mon, Dec 1, 2014 at 12:25 AM, Ethan Furman et...@stoneleaf.us wrote:
One argument that keeps coming up is transferability of knowledge:
knowing git and/or GitHub, as many seem to, it
therefore becomes easier to commit to the Python ecosystem.
What about the transferability of Python
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.
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
On 2014-12-01, 07:43 GMT, Donald Stufft wrote:
I do not choose tools simply because they are written in
Python -- I choose them because, being written in Python, I
I can work on them if I need to: I can enhance them, I can
fix them, I can learn from them.
Git uses the idea of small
Here's a roundup of tools links, to make sure we're all on the same page:
Git HG Rosetta Stone
===
https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone
BugWarrior
===
BugWarrior works with many issue tracker APIs
On 12/01/2014 01:05 PM, Matěj Cepl wrote:
On 2014-12-01, 07:43 GMT, Donald Stufft wrote:
I do not choose tools simply because they are written in
Python -- I choose them because, being written in Python, I
I can work on them if I need to: I can enhance them, I can
fix them, I can learn from
On 12/01/2014 08:42 AM, Wes Turner wrote:
Here's a roundup of tools links, to make sure we're all on the same page:
Thanks!
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
Hi!
On Mon, Dec 01, 2014 at 10:42:16AM -0600, Wes Turner wes.tur...@gmail.com
wrote:
Here's a roundup of tools links, to make sure we're all on the same page:
Very nice!
Is there an issue ticket or a wiki page that supports
Markdown/ReStructuredText,
where I could put this? Which URI do
On 12/1/2014 11:42 AM, Wes Turner wrote:
Here's a roundup of tools links, to make sure we're all on the same page:
Git HG Rosetta Stone
===
https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone
BugWarrior
===
BugWarrior works with many issue tracker
On Mon, Dec 01, 2014 at 03:52:21PM -0500, Terry Reedy tjre...@udel.edu wrote:
On 12/1/2014 11:42 AM, Wes Turner wrote:
Is there an issue ticket or a wiki page that supports
https://wiki.python.org/moin/
Markdown/ReStructuredText,
whoops, I am not sure what moin uses.
Let's see...
On Sun, Nov 30, 2014 at 10:25 AM, Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 1:05 PM, Guido van Rossum gu...@python.org wrote:
I don't feel it's my job to accept or reject this PEP, but I do have an
opinion.
So here’s a question. If it’s not your job to accept or reject
On 11/29/2014 04:37 PM, Donald Stufft wrote:
On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@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
On 29 Nov 20:13, Donald Stufft wrote:
I think one of the issues with Reitveld isn’t related to Reitveld itself at
all, it’s all the *other* stuff you have to do to get a patch into Reitveld to
allow someone to review it at all. Generating a patch and uploading it to
Roundup is a pain and it’s
On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote:
Python is already using quite a bit of non-free software in its
ecosystem. The Windows builds of CPython are made with Microsoft's
compiler, and the recent discussion about shifting to Cygwin or MinGW
basically boiled down to
On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote:
Python is already using quite a bit of non-free software in its
ecosystem. The Windows builds of CPython are made with Microsoft's
compiler, and the
I have some questions and/or issues with the PEP, but first I'm going to
add something to Nick's comments:
On Sun, Nov 30, 2014 at 11:12:17AM +1000, Nick Coghlan wrote:
Beyond that, GitHub is indeed the most expedient option. My two main
reasons for objecting to taking the expedient path are:
Chris Angelico ros...@gmail.com writes:
But what non-free software is required to use the community design
processes? The GitHub client is entirely optional; I don't use it, I
just use git itself. Using a free client to access a proprietary
server isn't the same as using non-free software.
Donald Stufft don...@stufft.io writes:
I think there is a big difference here between using a closed source
VCS or compiler and using a closed source code host. Namely in that
the protocol is defined by git so switching from one host to another
is easy.
GitHub deliberately encourages
On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote:
In previous years there was concern about how well supported git was on
Windows
in comparison to Mercurial. However git has grown to support Windows as a
first
class citizen. In addition to that, for Windows users who are
On Sun, 30 Nov 2014 16:23:08 +1100
Chris Angelico ros...@gmail.com wrote:
Yes, GitHub is proprietary. But all of your actual code is stored in
git, which is free, and it's easy to push that to a new host somewhere
else, or create your own host. This proposal is for repositories that
don't
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 30 Nov 2014 16:23:08 +1100
Chris Angelico ros...@gmail.com wrote:
Yes, GitHub is proprietary. But all of your actual code is stored in
git, which is free, and it's easy to push that to a new host somewhere
Larry Hastings la...@hastings.org writes:
On 11/29/2014 04:37 PM, Donald Stufft wrote:
On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@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
- [ ] Markdown
- [ ] ReStructuredText
- [ ] Review (why are these out of band?)
On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote:
Specifically, which features are most ideal here?
- [ ] Userbase
- [ ] TTW editing only over SSL (see: Zope 2)
- [ ] Pull Requests (see
- [ ] Stable URIs
- [ ] Commit hashes
On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote:
- [ ] Markdown
- [ ] ReStructuredText
- [ ] Review (why are these out of band?)
On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner wes.tur...@gmail.com wrote:
Specifically, which
Is there a kalithea celery task to mirror / SYNC with github, for pull
requests and/or issues?
https://pypi.python.org/pypi/Kallithea/
https://kallithea-scm.org/
https://kallithea-scm.org/repos/kallithea
https://bitbucket.org/conservancy/kallithea
http://pythonhosted.org//Kallithea
https://kallithea-scm.org/repos/kallithea/files/tip/setup.py
https://github.com/codeinn/vcs/blob/master/setup.py
On Sun, Nov 30, 2014 at 1:16 AM, Wes Turner wes.tur...@gmail.com wrote:
Is there a kalithea celery task to mirror / SYNC with github, for pull
requests and/or issues?
- [ ] Paste-able links
On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner wes.tur...@gmail.com wrote:
- [ ] Stable URIs
- [ ] Commit hashes
On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner wes.tur...@gmail.com wrote:
- [ ] Markdown
- [ ] ReStructuredText
- [ ] Review (why are these out of band?)
On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote:
In previous years there was concern about how well supported git was on
Windows
in comparison to Mercurial. However git has grown to support Windows as a
On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com wrote:
Donald Stufft donald at stufft.io writes:
[words words words]
I strongly support this PEP. I'd like to share two pieces of information.
Both
of these are personal anecdotes:
For the past several years, I've
On Nov 30, 2014, at 2:08 AM, Larry Hastings la...@hastings.org wrote:
On 11/29/2014 04:37 PM, Donald Stufft wrote:
On Nov 29, 2014, at 7:15 PM, Alex Gaynor alex.gay...@gmail.com
mailto:alex.gay...@gmail.com wrote:
Despite being a regular hg
user for years, I have no idea how to create
On Nov 30, 2014, at 6:18 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Donald Stufft don...@stufft.io writes:
I think there is a big difference here between using a closed source
VCS or compiler and using a closed source code host. Namely in that
the protocol is defined by git so
On Sun Nov 30 2014 at 10:28:50 AM Brett Cannon br...@python.org wrote:
Why specifically? Did you have a web UI for reviewing patches previously?
Do you have CI set up for patches now and didn't before? What features did
you specifically gain from the switch to GitHub that you didn't have
On Nov 30, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote:
On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com
mailto:alex.gay...@gmail.com wrote:
Donald Stufft donald at stufft.io http://stufft.io/ writes:
[words words words]
I strongly support this
On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com
wrote:
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Sun, 30 Nov 2014 16:23:08 +1100
Chris Angelico ros...@gmail.com wrote:
Yes, GitHub is proprietary. But all of your actual code
On Sun, Nov 30, 2014, at 11:45, Donald Stufft wrote:
On Nov 30, 2014, at 11:28 AM, Brett Cannon br...@python.org wrote:
On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor alex.gay...@gmail.com
mailto:alex.gay...@gmail.com wrote:
Donald Stufft donald at stufft.io http://stufft.io/
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
- Migrating data from GitHub is easy. There are free-as-in-freedom
tools to do it and the only cost is the time it would take to monitor
the process
*Extracting* data may be easy, but migrating it is a different story. As the
Mailman project has
On Nov 30, 2014, at 11:44 AM, Brett Cannon br...@python.org wrote:
On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com
mailto:graffatcolmin...@gmail.com wrote:
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote:
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
- Migrating data from GitHub is easy. There are free-as-in-freedom
tools to do it and the only cost is the time it would take to monitor
the process
*Extracting* data
On Nov 30, 2014, at 12:09 PM, Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote:
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
- Migrating data from GitHub is easy. There are free-as-in-freedom
tools to do it and the only cost
On Nov 30, 2014 11:09 AM, Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote:
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
- Migrating data from GitHub is easy. There are free-as-in-freedom
tools to do it and the only cost is
On Nov 30, 2014, at 11:30 AM, Donald Stufft don...@stufft.io wrote:
Comments like this make me feel like I didn’t explain myself very well in the
PEP.
It’s been pointed out to me that Mercurial bookmarks have been core since 1.8
and since I felt like the technical arguments were really
On 11/29/2014 10:14 PM, Demian Brecht wrote:
On Sat, Nov 29, 2014 at 3:27 PM, Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
As promised in the Move selected documentation repos to PSF BitBucket
account? thread I've written up a PEP for moving selected repositories from
On Nov 30, 2014, at 11:17, Chris Angelico ros...@gmail.com wrote:
On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 November 2014 at 15:23, Chris Angelico ros...@gmail.com wrote:
Python is already using quite a bit of non-free software in its
ecosystem. The
I don't feel it's my job to accept or reject this PEP, but I do have an
opinion.
The scope of the PSF organization is far beyond just the Python language --
it includes the Python developer community, the Python user community, 3rd
party Python packages and their communities (even if some have
On 30 November 2014 at 16:08, Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote:
In previous years there was concern about how well supported git was on
Windows
in
Can this discussion be split off into a separate discussion. It's
tangential to the PEP and clearly not actively progressing so it
doesn't seem productive. I don't care where it's taken, but I don't
think this belongs here. Speculation on the actions of the msysgit
project are not fair talk for
On Nov 30, 2014, at 1:05 PM, Guido van Rossum gu...@python.org wrote:
I don't feel it's my job to accept or reject this PEP, but I do have an
opinion.
So here’s a question. If it’s not your job to accept or reject this PEP, whose
is it? This is probably an issue we’re never going to get
On Sun Nov 30 2014 at 12:00:20 PM Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 11:44 AM, Brett Cannon br...@python.org wrote:
On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco graffatcolmin...@gmail.com
wrote:
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net
On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org wrote:
All very true, but if we can't improve both sides then we are simply going to
end up with even more patches that we take a while to get around to. I want
to end up with a solution that advances the situation for *both*
On Nov 30, 2014, at 2:28 PM, Ethan Furman et...@stoneleaf.us wrote:
On 11/30/2014 10:05 AM, Guido van Rossum wrote:
Python has a long history (all the way back to my choice of a MIT-style
license for the first release) of mixing free
and non-free uses and tools -- for example on Windows
On Mon, Dec 1, 2014 at 6:28 AM, Ethan Furman et...@stoneleaf.us wrote:
My issues with GitHub range from selfish to philosophical:
- (selfish) I don't want to learn git
This ties in directly with the popularity argument. How many people
are there who know hg and don't know git? How many who
On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft don...@stufft.io wrote:
On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org wrote:
All very true, but if we can't improve both sides then we are simply going
to end up with even more patches that we take a while to get around to. I
want
On 11/30/2014 11:56 AM, Donald Stufft wrote:
On Nov 30, 2014, at 2:28 PM, Ethan Furman et...@stoneleaf.us wrote:
My issues with GitHub range from selfish to philosophical:
- (selfish) I don't want to learn git
Note: That you don’t actually have to learn git, you can clone a git
On Sun, 30 Nov 2014 19:19:50 +
Brett Cannon br...@python.org wrote:
As the PEP points out, the devguide, devinabox, and the PEPs have such a
shallow development process that hosting them on Bitbucket wouldn't be a
big thing. But if we don't view this as a long-term step towards moving
On Sun, 30 Nov 2014 10:05:01 -0800
Guido van Rossum gu...@python.org wrote:
I bring this up to emphasize that (unlike GNU software and the FSF) Python
has no additional hidden agenda of bringing freedom to all software.
As far as GNU and the FSF are concerned, I don't think the agenda is
On Nov 30, 2014, at 4:05 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 30 Nov 2014 10:05:01 -0800
Guido van Rossum gu...@python.org wrote:
I bring this up to emphasize that (unlike GNU software and the FSF) Python
has no additional hidden agenda of bringing freedom to all
On Nov 30, 2014, at 3:26 PM, Brett Cannon br...@python.org wrote:
On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft don...@stufft.io
mailto:don...@stufft.io wrote:
On Nov 30, 2014, at 2:19 PM, Brett Cannon br...@python.org
mailto:br...@python.org wrote:
All very true, but if we
On 11/30/2014 2:33 PM, Donald Stufft wrote:
So a goal of mine here is to sort of use these as a bit of a test bed.
Moving CPython itself is a big and drastic change with a lot of
implications, but moving the “support” repositories is not nearly as
much, especially with a read only mirror on
On Sun, Nov 30, 2014 at 10:55 AM, Barry Warsaw ba...@python.org wrote:
On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
- Migrating data from GitHub is easy. There are free-as-in-freedom
tools to do it and the only cost is the time it would take to monitor
the process
*Extracting* data
On 11/30/2014 1:05 PM, Guido van Rossum wrote:
I don't feel it's my job to accept or reject this PEP, but I do have an
opinion.
...
- I am basically the only remaining active PEP editor, so I see most PEP
contributions by non-core-committers. Almost all of these uses github.
Not bitbucket, not
Donald Stufft don...@stufft.io writes:
I have never heard of git losing history.
In my experience talking with Git users about this problem, that depends
on a very narrow definition of “losing history”.
Git encourages re-writing, and thereby losing prior versions of, the
history of a branch.
On Nov 30, 2014, at 7:17 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Donald Stufft don...@stufft.io writes:
I have never heard of git losing history.
In my experience talking with Git users about this problem, that depends
on a very narrow definition of “losing history”.
Git
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
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
On 11/30/2014 04:31 AM, Paul Moore wrote:
On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote:
In previous years there was concern about how well supported git was on Windows
in comparison to Mercurial. However git has grown to support Windows as a first
class citizen. In
On 11/30/2014 08:45 AM, Donald Stufft wrote:
I don’t make branches in Mercurial because
i’m afraid I’m going to push a permanent branch to hg.python.org
http://hg.python.org and screw
something up.
There is no need to be afraid there, Mercurial is not going to let you
push new head/branch
On 11/30/2014 04:31 AM, Paul Moore wrote:
On 29 November 2014 at 23:27, Donald Stufftdon...@stufft.io wrote:
In previous years there was concern about how well supported git was on Windows
in comparison to Mercurial. However git has grown to support Windows as a first
class citizen. In
On Nov 30, 2014, at 8:11 PM, Pierre-Yves David
pierre-yves.da...@ens-lyon.org wrote:
On 11/30/2014 08:45 AM, Donald Stufft wrote:
I don’t make branches in Mercurial because
i’m afraid I’m going to push a permanent branch to hg.python.org
http://hg.python.org and screw
something up.
1 - 100 of 134 matches
Mail list logo
