devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.)
On Tue, Jan 18, 2011 at 2:35 PM, Antoine Pitrou
On Tue, 18 Jan 2011 07:14:51 +0100 Ezio Melotti
wrote: + +Committing Patches +================== [...] + + svnmerge.py merge -r 42 + +This will try to apply the patch to the current patch and generate a commit
Do we want to spend so much time explaining how to use SVN for core developers while we're supposed to switch to Mercurial Real Soon Now? (current core devs already know how to use it, and we don't get many new ones every month)
How about patches sent by users who track and fix bugs directly in codebase of their Python installation? Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users. We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development. -- anatoly t.
On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik
Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users.
That latter comment hasn't been true since Microsoft started releasing the Visual Studio Express editions.
We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development.
Given the length of Python's release cycles, diffs against released versions are far too likely to be out of date. We want diffs against the head of the relevant branch. People that can't check out and build their own version of Python are quite welcome to simply report issues without trying to fix them themselves. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan
On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik
wrote: Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users.
That latter comment hasn't been true since Microsoft started releasing the Visual Studio Express editions.
"not possible" here means that practically only a very small percent of Python users will go through the hurdles of getting code checkout, downloading and installing Visual Studio, compiling project, switching their code to use compiled version and finally submitting a patch. BTW, what is the size of Mercurial clone right now?
We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development.
Given the length of Python's release cycles, diffs against released versions are far too likely to be out of date. We want diffs against the head of the relevant branch.
I only see that you want the contribution entry barrier to stay at the height of core developer.
People that can't check out and build their own version of Python are quite welcome to simply report issues without trying to fix them themselves.
But if they really want for an issue to be fixed, they will need to think about preparing a patch. The first time they ask about plans to fix the issue, they will be asked to send a patch anyway. This person will look into devguide how to send a patch. There will be instructions to download Visual Studio, clone repository, compile, etc. I doubt this person will have time to do this, but next time the person will think twice before reporting.
On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik
How about patches sent by users who track and fix bugs directly in codebase of their Python installation?
While I don't personally endorse the above approach, if you're going to develop inside your installed site-packages folder it seems like a good idea to at least version control that code by running "hg init" or similar in the site-packages folder. Then you can create diffs against older versions using "hg diff". If one is going to do something crazy one might as well go the whole hog I guess. :) Schiavo Simon
Am 02.02.2011 13:50, schrieb anatoly techtonik:
We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development.
Given the length of Python's release cycles, diffs against released versions are far too likely to be out of date. We want diffs against the head of the relevant branch.
I only see that you want the contribution entry barrier to stay at the height of core developer.
Because only core developers are allowed to have a checkout of trunk? Georg
On Wed, Feb 2, 2011 at 06:50, anatoly techtonik
On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan
wrote: On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik
wrote: Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users.
That latter comment hasn't been true since Microsoft started releasing the Visual Studio Express editions.
"not possible" here means that practically only a very small percent of Python users will go through the hurdles of getting code checkout, downloading and installing Visual Studio, compiling project, switching their code to use compiled version and finally submitting a patch.
In reality this doesn't seem to be the case. In all of the Windows-related Python issues I've looked at in a year and a half, only a small handful of the patches or analysis have been based on installed versions or from users who don't have the capability or interest in setting up the environment. Of course we welcome those users, but my experience shows them to be the minority. Installing Visual Studio is probably one of the more rare steps in the process, as many Windows-using software developers tend to use it for other things.
People that can't check out and build their own version of Python are
quite welcome to simply report issues without trying to fix them themselves.
But if they really want for an issue to be fixed, they will need to think about preparing a patch.
This is not true at all. It's perfectly acceptable to report an issue and do nothing further. It certainly helps the process to contribute more, but we're happy to just get valid bug reports. Someone even made it easy enough to email report@bugs.python.org so you don't even have to create an account.
The first time they ask about plans to fix the issue, they will be asked to send a patch anyway.
We don't want bugs to linger, but there's only so many developers and so little time. If you want to know when something will be fixed, a lot of people will say something like "I won't be able to get to this next week, unless you have a patch of your own". I don't see anything wrong with that. In fact, it's pretty common in open source. This person
will look into devguide how to send a patch. There will be instructions to download Visual Studio, clone repository, compile, etc. I doubt this person will have time to do this, but next time the person will think twice before reporting.
I've found quite the opposite to be true. The dev guide I wrote for PSF Sprints, most of which was absorbed into the recently created http://docs.python.org/devguide/, got many people happily setup to contribute and I expect the new one to do the same. In fact, I've heard comments from a number of people that the setup was much easier than they thought, especially compared to other projects.
participants (5)
-
anatoly techtonik
-
Brian Curtin
-
Georg Brandl
-
Nick Coghlan
-
Simon Cross