Hello! I submitted a number of patches to the SF tracker. Few of them were accepted, but most of them still are unreviewd by core team. What can I do to help? (A polite way to say "how can I push them?" :) I have updated them to Python 2.4b1. Actually, only one of them required minor changes (different line numbers). But I must admit that the patches are not a simple bug fix, so it is probably too late to apply them for 2.4. They can wait for 2.5... but I am afraid they will be just forgotten. The patches are: http://python.org/sf/754022 This is the biggest and the oldest. It hangs in the tracker since Python 2.2. In short, it makes the webbrowser.py runs through _tryorder list of browsers and trie to run every browser until one started successfully. Currently webbrowser.py tries to run a browser and if it fails - stops trying. Assigned to Fred Drake. http://python.org/sf/784089 A program to scan python files and list those require -*- coding -*- directive. Reviewed by Marc-Andre Lemburg and Andrew Kuchling. http://python.org/sf/821862 Makes ftplib.py a bit more RFC959-compliant. The RFC requires the FTP protocol to be run not over TCP but over telnet. For most people there is no difference but there is a subtle different for those who use non-ASCII encodings: chr(255) - a special character in telnet - requires a special handling. My patch adds a toggle that allows to turn telnet on (actually, it only doubles chr(255) in command stream, but it is one of two things that are required for FTP-over-telnet). By default it is off to preserve backward compatibility. http://python.org/sf/1038388 The smallest and the simplest of all. 3 lines patch that adds __main__ to whichdb.py, so one can run it on the command line: $ whichdb.py *.db Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
I have suggested a procedure in the past, which never has been executed so far. I promise that I will stick to it if somebody actually executes it. Here it goes: - For every patch you want to get reviewed, review 10 (ten) other patches. A review should explain what kind of analysis was performed (code inspection, testing on platform X, etc), and it should include a recommendation for acceptance, rejection, or modification. If a patch already has a suggestion of modification, which was unanswered for some time, either post the modification yourself, or suggest rejection of the patch. - Post your reviews to the relevant patches. - Post a summary of the patches reviewed, including the patch number and review recommendation, to python-dev, along with the patch you want reviewed in turn. Notice that a review at this point may conclude with "acceptable for 2.5", which means that we need to go back to the patch after 2.4 has been forked. Regards, Martin
"Martin" == Martin v Löwis <martin@v.loewis.de> writes:
Martin> I have suggested a procedure in the past, which never has Martin> been executed so far. I promise that I will stick to it if Martin> somebody actually executes it. Here it goes: Martin> - For every patch you want to get reviewed, review 10 Martin> (ten) other patches. I think 10 is way too high; I would call it prohibitive for anyone who isn't already primarily a Python hacker. I agree it should be more than 1 for 1 for several reasons, but I'd be willing to bet you get excellent results from 3:1 or even 2:1. Even if you think that risks being a burden on your time, since you've had no takers yet (and it's been a while since the last time I saw your proposal), I'd say that lowering the "price" to 5:1 is a reasonable idea, and not very risky. You can always raise the price again if you get 50 useful reviews by next Tuesday.<wink> -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On Oct 19, 2004, at 23:56, Stephen J. Turnbull wrote:
Speaking of "price", perhaps PSF donations should be factored into getting a patch reviewed? I'm probably only saying this because I've donated, have some patches in the queue that aren't yet reviewed, and don't really have the spare time/energy to review a stockpile of Other People's Patches ;) I think my open-source-python-time is better spent working on the Mac distribution problems (py2app, bdist_pkg, etc.) than reviewing other people's patches... -bob
[Bob]
Speaking of "price", perhaps PSF donations should be factored into getting a patch reviewed?
Since we're talking about volunteered time, any reviewer can use any basis they want for selecting what to address. Martin's price of review is a way of trying to leverage his time. Because he has broad expertise, often he is the only to spend time with otherwise neglected bugs or patches. If others followed his example, we would have less of a backlog.
I'm probably only saying this because I've donated, have some patches in the queue that aren't yet reviewed
Please list them out in an email and I'll look them over. than
reviewing other people's patches...
Ah, there's the rub. Raymond
Bob Ippolito wrote:
That is an entirely valid remark, and using PSF funds for that would be an appropriate spending of the funds. Unfortunately, I don't think it will work: we can't hire anybody off the street to do patch reviews and commits for us, since we need to trust reviewers to do a high-quality job. The people who already review and commit patches regularly probably can't be pursued with money to work more on Python (I know that I wouldn't be pursued, atleast not with the amount of money that the PSF could offer). As for spending your volunteer time differently: most certainly, yes. Any volunteer can spend volunteer time anyway they please. This goes both ways, of course: for submitters and reviewers. If you want to push your changes, an alternative procedure might be to push only selected changes, by contacting somebody you know is primary maintainer of that part of Python - and trust that your own reputation on python-dev will not make that person ignore you. Regards, Martin
I'm also willing to look at any outstanding bugs or patches if you think it's particularly urgent or important (to you). Obviously, I'm more likely to be able to act on a patch than a bug with no patch, my time is limited - but if there's a patch you think needs some TLC, email me with the details. This is of course only for me - other committers have their own preferences on how they'd prefer to act. Anthony
Stephen J. Turnbull wrote:
I think 10 is way too high; I would call it prohibitive for anyone who isn't already primarily a Python hacker.
Some kind of prohibition is necessary for the process of "pushing" patches. If too many people actually perform the procedure, I may not be able to keep my promise of giving their patches more attention. Notice that this is my own, private procedure - the condition under which *I* will make my volunteer time available. Other core developers may have different procedures, such as giving such requests moderate priority, trying to review the patches right away, or completely ignoring such requests entirely (I believe the majority of people with commit access falls in that category, as only a small fraction of committers commits SF patches regularly). People who don't want to use that procedure don't need to at all. There is apparently a constant backlog of 200..300 patches. Patches that look more important to regular reviewers will get attention, patches that somehow seem doubtful will get skipped over - over and over again. If you want to push one of these patches, and you don't want to use the procedure of guaranteed review that I promise, you can still use the begging procedure that most people come up with.
That might be an option indeed. So, Oleg, as a special offer, I will do this at a 5:1 ratio :-) Regards, Martin
"Martin" == Martin v Löwis <martin@v.loewis.de> writes:
Martin> If you want to push one of these patches, and you don't Martin> want to use the procedure of guaranteed review that I Martin> promise, you can still use the begging procedure that most Martin> people come up with. Sure. I don't suggest reducing price in order to get you to review more patches. What I like about your procedure is that it encourages people to get involved in helping each other in developing Python. While python-dev is really excellent for mentoring design and implementation, this looks like a good way to get people involved in reviewing. I think that activity is normally under-staffed in most projects. I'd-rather-be-coding-too-ly y'rs, -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
[Oleg Broytmann]
This should probably wait until Py2.5 The functionality, command line launching and successive browser tries, appear useful. Feel free to bug Fred to at least comment on the desirability of the patch. If he gives it a thumbs up, almost anyone else can review and apply this one.
I will clean this one up a bit and add it Tools/scripts.
Is there a real need for this? As you mention in the patch, FTP is usually not run over telnet. This module has been around for years and there has been zero user demand for the feature. I suspect this is a waste of bits.
This is harmless. I will apply it for you. No charge, Raymond
phd@phd.pp.ru
On Wed, Oct 20, 2004 at 02:20:12AM -0400, Raymond Hettinger wrote:
Of course.
Thank you!
It often runs over telnet - I use ProFTPd which implements telnet without an option to turn it off. The problem is that I cannot use ftplib.py to grab files from my own server :( Most Unix servers implement telnet, but 7-bit ASCII-only filenames hide the fact. Making ftplib.py more RFC-compliant with backward compatibility is a good thing, in my opinion. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 20 Oct 2004 02:20:12 -0400, Raymond Hettinger <python@rcn.com> wrote:
It reminds Postel's Law: "Be conservative in what you do, be liberal in what you accept from others." [Section 2.10 - RFC 793] So... if the RFC states that it should run over telnet, then standard implementations should do it. But, according to Martin's proposed rules -- which I entirely agree with -- my vote still doesn't count, as I haven't reviewed any patch yet; so please take it only as a general opinion on the subject. low demand nonetheless. Priority may be low, but its still a relevant patch, IMHO -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
Carlos Ribeiro wrote:
Martin's rules are a bargain where reviewing a certain number of existing patches will get him to have a look at a particular patch you'd like him to review (I'd guess it doesn't even have to be one you wrote - just one you'd like someone with commit access to consider). Your opinion on patches definitely counts even if you haven't made it to Martin's magic number - otherwise his bargain wouldn't make much sense! Cheers, Nick.
participants (8)
-
"Martin v. Löwis"
-
Anthony Baxter
-
Bob Ippolito
-
Carlos Ribeiro
-
Nick Coghlan
-
Oleg Broytmann
-
Raymond Hettinger
-
Stephen J. Turnbull