
Andrew let me repost this mail of his to this list. It's worth a discussion here (if not in a larger forum). My responses are at the bottom. ------- Forwarded Message Date: Wed, 19 Jan 2000 20:17:55 -0500 From: "A.M. Kuchling" <amk1@erols.com> To: guido@python.org Subject: Python 1.6 timing I thought a bit more about the release schedule for 1.6, and like the idea of delaying it less and less. Another bad effect of delaying it is that not having Unicode in the core handicaps developing XML tools; we can continue working with wstrop, or integrate MAL's code into the XML-SIG's CVS tree, but it might mean abandoning the XML processing field to Perl & Tcl because the tools can't be made fully standard compliant in time. Options I can think of: 1) Delegating some control to a pumpkin holder [...]. 2) Releasing the Unicode+sre modules as separate add-ons to 1.5. (But would that impose annoying backward-compatibility constraints when they get integrated into 1.6?) 3) Add Unicode, sre, Distutils, plus other minor things and call it 1.5.5, meaning it's not as big a revision as a 1.6 release, but it's bigger than just another patchlevel of bugfixes. I don't remember what other features were planned for 1.6; was there anything major, if static typing is left for 2.0? - -- A.M. Kuchling http://starship.python.net/crew/amk/ Life's too short for chess. -- H.J. Byron ------- End of Forwarded Message There are several other things I can think of now that were planned for 1.6: revamped import, rich comparisons, revised coercions, parallel for loop (for i in L; j in M: ...), extended slicing for all sequences. I've also been thinking about making classes be types (not as huge a change as you think, if you don't allow subclassing built-in types), and adding a built-in array type suitable for use by NumPy. I've also received a conservative GC patch that seems to be fairly easy to apply and has some of Tim Peters' blessing. For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more conservative agenda, as suggested by Andrew: Unicode and distutils are probably the most important things to integrate. (The import utilities are not ready for prime time in my opinion; there are too many issues.) Anybody care to be the pumpkin? That would cut the discussion short; otherwise the problem remains that I can't spend too much time on the next release unless I get funded for it; what little money I've received for CP4E I had better spend on getting some CP4E-related results ASAP, because the next installment of this funding is very much at stake... --Guido van Rossum (home page: http://www.python.org/~guido/) Life's better without braces. -- Bruce Eckel

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been Guido> thinking about making classes be types (not as huge a Guido> change as you think, if you don't allow subclassing Guido> built-in types), and adding a built-in array type suitable Guido> for use by NumPy. I've also received a conservative GC Guido> patch that seems to be fairly easy to apply and has some of Guido> Tim Peters' blessing. All very cool things that could easily wait until 1.7. After all, what's in a number? If, as Andrew puts forth, getting a stable Python release with Unicode is very important for Python's future positioning, then I say let's go with his more modest list, mainly Unicode, sre, and Distutils. We've already got string meths, tons of library improvements, and sundry other things. That's a good enough laundry list for the next release.

Barry A. Warsaw [bwarsaw@cnri.reston.va.us] wrote:
Heck, Python is infinately more conservative in its numbering than a lot of projects. All that was mentioned would normally be enough to call it 2.0 easily. :-) Modesty can be counter productive in PR business...also there is the issue of having two copies of 1.5.x installed at the same time, which with Unicode could be a manjor consideraton for some of us. For me, numbering has always been (and I try and keep it this way with Zope): X.Y.Z X = structural changes, backward incompaibility Y = new features Z = bug fixes only Chris -- | Christopher Petrilli | petrilli@amber.org

[Christopher Petrilli]
Indeed, where I work a number of managers met the suggestion to use Python 1.5.x with "what?! we don't want to use software that's barely out of alpha release -- besides, Perl is already on release 5". I hear that Guido got normal American glasses -- time to do normal American hyperinflated version numbering too. heck-ms-windows-will-soon-be-at-version-2000<wink>-ly y'rs - tim

Barry A. Warsaw writes:
I'm not clear on the status of these various things; how many of these changes are deep ones that need lots of design, or affect massive amounts of the code base? For example, revamped import is a tricky design problem (as we've seen on this list). Is the spec for rich comparisons clearly defined at this point? Something like the parallel for loop seems like a parser modification combined with a code-generator modification, with no subtle implications for the rest of the implementation, and so that seems a simple matter of programming -- a week or so of effort. (Maybe I've missed something?)
Similarly, does the conservative GC patch splatter changes all over the place, or is it very localized? Is adding the NumPy array type straightforward? Remember, there would presumably be a couple of 1.6 alphas and betas to shake out bugs.
From a political standpoint, I'd call the next release 1.6 and not bother with another installment in 1.5.x series. And I agree with
Fair enough; forget about the 1.5.5 suggestion, and call it as 1.6.
tree. My free-time plate is pretty full with JPython and Mailman, but I'm willing to help where possible.
Ditto. -- A.M. Kuchling http://starship.python.net/crew/amk/ One trouble with being efficient is that it makes everybody hate you so. -- Bob Edwards, the Calgary Eyeopener, March 18, 1916

[Andrew M. Kuchling]
Part of its problem is that it's *too* localized (which was, paradoxically, I suspect part of its initial quick-eyeball appeal to Guido -- it "looks like" an amazingly self-contained patch). For example, all the code to chase pointers in various types of objects is hiding in a single function, which does a string of "if type is list then this else if type is tuple then that ..." tests. This stuff clearly needs to be distributed across the object implementations and dispatched to via a new slot in type objects; there's no code for that now. I expect it would take a minimum of two weeks (full-time work) to make this code ready for prime time (but mostly to slash the space and time use -- and with no certainty of "good enough" in the end). BTW, "conservative" is a misleading adjective for this approach -- it never guesses ("guessing on the safe side" whether or not some bit pattern is a pointer is what "conservative" customarily means in the GC world).
Is adding the NumPy array type straightforward?
DavidA nixed that one in no uncertain terms! maybe-hp-will-give-up-unicode-and-we-can-release-tomorrow-ly y'rs - tim

"BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes: "Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been thinking Guido> about making classes be types (not as huge a change as you Guido> think, if you don't allow subclassing built-in types), and Guido> adding a built-in array type suitable for use by NumPy. I've Guido> also received a conservative GC patch that seems to be fairly Guido> easy to apply and has some of Tim Peters' blessing. BAW> All very cool things that could easily wait until 1.7. After BAW> all, what's in a number? If, as Andrew puts forth, getting a BAW> stable Python release with Unicode is very important for BAW> Python's future positioning, then I say let's go with his more BAW> modest list, mainly Unicode, sre, and Distutils. We've already BAW> got string meths, tons of library improvements, and sundry BAW> other things. That's a good enough laundry list for the next BAW> release. We've had this conversation before, so it'll comes as no surprise that I agree with you. Question: If we go with the feature set you've described, when will those features be ready? What kind of schedule could we set for releasing the first alpha? Jeremy

[I just got GvR's post on the topic, but I'll send this anyway] BAW:
All very cool things that could easily wait until 1.7. After all, what's in a number?
Guido has promised some of those features as being in 1.6 at conferences in the past, but I agree that string methods for example are a more major change than I'd expect to see in a 0.0.3-delta version change. Maybe with a deadline (as Greg suggests) we can integrate some of the pending patches (I agree with Greg that I at least would have found the time for a revised patch for rich comparisons if I'd had a deadline -- call me human =). Coercion and extended slicing also seem like relatively minor changes, compared with changing everything to be a class or adding GC! Regardless, just like Greg, I'd like to know what a pumpkin-holder would mean in the Python world. I propose that it be called the Oracle instead. As in, whoever is Oracle would get some training with Tim Peters and learn how to channel G__do. As a Python user, I'd be most comfortable with such a change if the Oracle just took over the technical stuff (reviewing patches, CVS checkins, running tests, corralling help for doc & code, maintaining release notes, building installers, etc.), but that the important decisions (e.g. whether to add a feature to the core language) would be checked with G__do first. We could call the position "Administrative Assistant", but somehow that doesn't have the prestige. A progressive schedule where Guido watches over the Oracle periodically would probably help build trust in the new mechanism. The Oracle would be expected to ask Guido for his opinion with everything at the beginning, and as a trust builds between Guido and the Oracle and the community and the mechanism, progressively less. --david ascher

On Thu, 20 Jan 2000, Ken Manheimer wrote:
The "pumpkin" term comes from Perl-land... I'm not super clear on the pumpkin-holders's entire job, but I think it is basically the guy who sees that the version for which he "holds the pumpkin" is completed and shipped. Not necessarily by himself :-), but as the overseer (or "release manager" if you will). The current Perl pumpkin-holder is a guy at ActiveState. I think it changes for each version. Cheers, -g -- Greg Stein, http://www.lyra.org/

We'd have to rework the CVS arrangement in order to give non-CNRI employees write access to the tree. I think I know how I'd go about this, and it wouldn't be too hard, just a bit time-consuming. If that's the way we're going to go, I can start making plans. -Barry

[Barry]
I think before you make such changes you'd have to talk to Bob (good luck). I don't mind applying patches and doing the checkins -- it's the decision-making that's time-consuming. --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> I think before you make such changes you'd have to talk to Guido> Bob (good luck). Heh. Guido> I don't mind applying patches and doing the checkins -- Guido> it's the decision-making that's time-consuming. Then maybe the current CVS arrangement is fine (cool with me). -Barry

On Thu, 20 Jan 2000, Barry A. Warsaw wrote:
Though it may be moot if guido's going to continue mediating the checkins, maybe this would be interesting (if only for barry, to compare procedures). We basically use a captive cvs-":ext:"-over-ssh method, where the captive .ssh/authorized_keys command is quite succinct: command="set $SSH_ORIGINAL_COMMAND; shift; exec cvs $@" 1024 35 ... The shellisms (set/shift/exec cvs $@) lock the user of the qualifying key into executing a cvs command, and only a cvs command. Also, for us the checkins are to a public mirror of our CVS repository, so penetration of the security there doesn't jepordize the master repository base. We don't currently have any outsiders checking into our master repository, and it doesn't seem to me that CVS provides sufficiently managable discretion for doing that. Oh, and a disappointment - the account under which cvs conducts the checkins is the account on the CVS server host, not that of the host where the checkins are being done. This means that you can't use a single account to serve multiple remote users (preventing masquerading quite reliably by using a separate authorized_key public-key entry for each remote user). Therefore we have to have distinct (nailed-down) accounts for each checkin-privileged person - more management burden. Ken

On Thu, 20 Jan 2000, Barry A. Warsaw wrote:
Or move the CVS tree off-site. Cheers, -g -- Greg Stein, http://www.lyra.org/

On Fri, 21 Jan 2000, Barry A. Warsaw wrote:
I was under the impression that CVS access restrictions are based on CNRI security policy. If the CVS repository moves elsewhere, then many people can access it without impact on CNRI's network and security policies. However, if the external access issue is based on legal reasons (for example, only CNRI people should alter Python code), then yes: moving the repository will buy nothing. Cheers, -g -- Greg Stein, http://www.lyra.org/

"GS" == Greg Stein <gstein@lyra.org> writes:
GS> I was under the impression that CVS access restrictions are GS> based on CNRI security policy. If the CVS repository moves GS> elsewhere, then many people can access it without impact on GS> CNRI's network and security policies. Well, access to our /internal/ network is of course restricted. CNRI employees have write access to the tree by virtue of access to the filesystem (i.e. by NFS). My current arrangement for external ssh mediated access to a writable cvs server on an internal machine is a hack and not something that I want to perpetuate if more users were added. GS> However, if the external access issue is based on legal GS> reasons (for example, only CNRI people should alter Python GS> code), then yes: moving the repository will buy nothing. I'll let Guido comment on policy concerning write access to the Python CVS tree. From a technical standpoint, if this is something Guido wanted to extend to non-CNRI employees, the way to do it would be to host the primary repository on a CNRI machine outside our firewall, e.g cvs.python.org. At that point, we'd be accessing the tree the same as anybody else. -Barry

On Fri, 21 Jan 2000 bwarsaw@python.org wrote:
Gotcha. Sounds great! I'm not sure yet that Guido is looking for external people to do checkins (as opposed to delivering refined patches to him)... So we probably don't need an assessment from the legal department :-), but if Guido already knows, then I'd be curious. thx! -g -- Greg Stein, http://www.lyra.org/

[David Ascher]
I'm afraid that wouldn't work. The whole secret to channeling Guido in the *past* was to have been an ABC user: all you had to do is notice the things about ABC that you loved and the ones that would drive any sane *experienced* programmer mad with frustration. Voila! Guido's mind is your mind <wink>. But the more Python sails into uncharted waters, the less reliable my Guido-channeling pseudo-skills get. He is, in Essence, Unfathomable. Also indispensable.
Definitely. But where do you find someone like that? It's (or at least *should* be) several full-time jobs. Languages like Icon & Scheme do it via university association (scads of grad student slave labor); REBOL did it by floating a trendy Internet business plan that actually attracted enough venture capital to hire about 30 people; Python, unfortunately <wink>, seems to attract people who already have demanding jobs. So I see it as an issue of finding warm bodies more than anything else. In the absence of funding "real jobs", I really don't see much hope. Bits & pieces can be farmed out (e.g., I doubt Guido has had to do any work on the regular expression code since Andrew arrived), but that's it -- I expect the past predicts the future quite accurately here. Certainly much more *could* be "farmed out", but no single volunteer of the kind Python has attracted so far is going to do a lot on their own month after month after month. Even with the best of intentions, their "real life" will interfere severely more often than not (voice of experience, there -- and I'd guess it's the same for *all* of us). if-something-doesn't-change-nothing-will-change<wink>-ly y'rs - tim

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> REBOL did it by floating a trendy Internet business plan that TP> actually attracted enough venture capital to hire about 30 TP> people; Python, unfortunately <wink>, seems to attract people TP> who already have demanding jobs. I think all we have to do is change the name for 1.6 to LinuxPython 2.0, then split off and go IPO. The more money we lose, the higher our stock will go and we can use our market cap to hire all those warm bodies. -Barry

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> [David Ascher]
TP> I'm afraid that wouldn't work. The whole secret to channeling TP> Guido in the *past* was to have been an ABC user: all you had to TP> do is notice the things about ABC that you loved and the ones TP> that would drive any sane *experienced* programmer mad with TP> frustration. Voila! Guido's mind is your mind <wink>. I have discovered another approach. CNRI put in a cleam room on the second floor last year. I recently discovered a little door behind some metrology device in a corner of the clean room. The door opens onto a tunnel that leads directly into Guido's mind. Unfortunately, it won't be of much use for a pumpkin-holder or channeler, because after about 15 minutes you are deposited on the shoulder of the Dulles Toll Road. who-wants-to-be-John-Malkovich-when-they-could-be-Guido-ly y'rs, Jeremy

On Sun, 23 Jan 2000, Jeremy Hylton wrote:
I almost fell out of my chair laughing when i read this. What do you think would happen if Guido went into the tunnel? Perhaps http://www.lfw.org/jminc/Guido/http://www.python.org/ (What you get is a generalization of some earlier silliness... the description of the original is at http://www.lfw.org/jminc/.) -- ?!ng

Guido van Rossum wrote:
(snip)
(snip) What is the basis of the Python numbering scheme? I thought that there was a notion that: - The first part changed with huge, possibly backward incompatible, changes, - The second part was for new functionality - The third part was for bug fixes. I thought I saw this scheme referenced somewhere and possibly even attributed to Guido. (?) I think that this is a better scheme that what I've seen with the 1.5 releases. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

On Thu, 20 Jan 2000, Guido van Rossum wrote:
I agree with Andrew's basic premise.
Options I can think of:
1) Delegating some control to a pumpkin holder [...].
Seems fine.
Icky. :-)
Call it 1.6, per the rest of the thread.
Unicode: definitely. distutils seems pretty early, but I bet that some key concepts could be added to 1.6, to make the transition and continued development easier. Note that if an announcement were made to the effect of "feature freeze on February 15; only bug fixes afterwards," that you would get a lot of people scrambling to submit their pet features. This would be a good way to light some fires, to see what kinds of things get completed (i.e. we may think some things aren't ready or are too far out, put that deadline in and those positions could change...)
I'm waiting for that review :-) If you raise issues, then I can knock them down. I don't see all that many at the moment. But I'm biased :-)
I would volunteer for the pumpkin... around April-ish. My plate is rather full with completing mod_dav and then integrating that into Apache 2.0. Once the Apache integration begins, then I'd have some more free time. But this begs the question of: what does the pumpkin-holder mean in the *Python* world? If it is collating fixes, producing snapshots, etc, then I'm comfy with it. If it also contains responsibility for specific kinds of work, then Fred would probably veto me :-), as I've got an outstanding doc that I owe him (for about six months now... sigh; maybe I'll bribe MAL to write it; he knows the interface :-)). But stll: what's it mean? How does the pumpkin reduce the Guido-load, yet still enable the Guido-control? [ I just had a talk about this with the guys at Inprise, re: InterBase, mentioning that the Dictator model works well for Python, but doesn't necessarily work well for new projects or commercially-started projects due to control/prejudice issues. Python people like it because of the resulting simplicity and cleanliness; I doubt we want a pumpkin approach that would allow that to go away! ] Cheers, -g -- Greg Stein, http://www.lyra.org/

Call it 1.6, per the rest of the thread.
OK. I expect I'll get some complaints from some people who asked when 1.6 would be out (I've generally told them end of 2000); but it sounds like a 1.7 would be necessary to fulfill the other promises, so it shouldn't really matter -- it's all a case of relabeling for PR purposes.
The point of adding distutils is that it will allow distribution of packages without including distutils with each distribution. Since distutils was about 200K itself last time I looked, this is important. I don't believe it would be good to have to say "My FooBar package is really easy to install. All you need to do is download and install distutils, (which by the way is a 200K package that you have to manually install), and then run "python setup.py" in the FooBar root directory..." This would be enough for the average person to run away screaming. I think I saw a distribution by AMK that had a setup.py that tried to use distutils but had a crude fallback if distutils didn't exist; however that defeats much of the purpose since the package author has to figure out how to do the fallback. Large distributions (e.g. NumPy) can afford to squeeze distutils in a corner of their distribution, but for the average package it wouldn't be of much use. In other words, I'm for putting distutils in the next release, essentially feature-freezing it. Greg Ward, what do you think of that?
I bet you we couldn't complete the import hooks by that date; I consider imputil.py as a nice prototype, but the integration with the C code is still missing. Also the 50% slowdown is a problem I worry about for inclusion a production version. (Plus breakage of everybody else's code who uses or hacks __import__; e.g. have you tested it with rexec?)
It was kept up by the need to get the types documents out.
Good questions. I have to say that I feel reluctant to release any kind of control -- yet at the same time I desperately need help getting trivial stuff checked in. One of the most important time-consuming tasks is quality control: collecting fixes is all well and good, but I routinely reject fixes that superficially look fine, because they are subtly broken, or interfere with other plans, or just because the code looks poorly written. I also spend a lot of testing before I check things in; running the standard test suite is a good safeguard against general breakage, but you really have to play with the code affected by the change before you can know that it works as advertised. My work attitude here means that what gets checked in is generally rock solid, and that helps Python's reputation; but it is very costly...
Agreed, of course. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, 20 Jan 2000, Guido van Rossum wrote:
Oh, don't get me wrong. I'd like to see it in there for at least all the reasons you cite. But it seems (to me) that it is still pretty alpha. But hey: I'm shooting from the peanut gallery; we need GregW's comments.
hehe... if the static typing is to be deferred, then I'll take that bet! [discussion omitted; too tangental to this thread right now...]
Reading your comments below, we may be able to help. First, presume that at least one (best would be several) people man the "front lines" for any/all patches and bug reports. The front line can deal with the bug reports, mostly by responding with "go away; enter it into Jitterbug." Patches fall under several catagories, detailed below:
Conversely, your "lieutenants" (LTs) would filter all ugly-looking patches.
because they are subtly broken,
If the LTs didn't catch these, then you could catch them from the checkin diff email. However, the LTs would reduce the number of broken ones that you would review.
or interfere with other plans,
The LTs may know of this, but if not: you'd catch it at checkin time. The patches would then be backed out, altered, or whatever.
or just because the code looks poorly written.
The LTs would definitely catch this. If the style was *still* not up to snuff, I'd have to believe it would only be in minor ways that you could then touch up at your leisure.
I also spend a lot of testing before I check things in;
Done by the LTs.
running the standard test suite is a good safeguard against general breakage,
Ditto.
Ditto.
Based on my responses, I would venture to state that a group of LTs would manage to keep the Python core rock solid, except for: 1) subtle breakages that require your broader knowledge of Python 2) changes that "go against the plan" (and the LTs were ignorant of it) 3) minor format issues You would still review checkins, but the number of reviews would drop since the (obvious) crap has been eliminated. #1 is based on your *broad* knowledge of Python; I presume the LTs would be your match on various subsets of Python. By keeping the LTs well-informed, #2 could be nearly eliminated. #3 isn't that big of a deal, as I think your desired style is relatively well-known and the LTs would simply endeavor to match existing style. You could avoid a lot of testing; you would probably be inclined to do testing of items that you find dubious, but still this would be a reduction. ===== That may be an answer to the checkin problem. How about actual snapshots, alphas, betas, releases, and accompanying notes/news/readme files? I presume your LTs could run the alpha and beta aspects, but you would still issue final releases. Does your mail volume need to be reduced? (I think this has been asked before) Specifically, would patches@python.org (and similar targets) need to be established? (I would think so, as a matter of course, with the expectation that some patches would still end up with you and need to be bounced to patches@) Cheers, -g -- Greg Stein, http://www.lyra.org/

(I accidentally mailed this only to Greg; here's a repost of the relevant parts to the list:) [me]
[Greg Stein]
Reading your comments below, we may be able to help.
[...Proposal of lieutenants condensed...]
There's a lot of work in these (you may have noticed that the release notes got sloppier as 1.5.2 neared its completion). I would be happy to have the responsibility to decide to release without the burden of having to do all the work.
It's not the mail volume that bothers me -- I can ignore 100s of messages a day very quickly. It's the time it takes to respond to all of them. As an experiment, I've collected about 40 messages with suggested patches in them that I found in my inbox; the oldest are nearly two years old. You can access these from this address: http://www.python.org/~guido/patch/ I would love any help I could get in responding with these, and taking action in the form of patches. I propose that if you decide that a particular patch is worth checking in, you ask the author for the bugrelease or wetsign disclaimer and let me know that I can check it in; if changes to the patch are needed, I propose that you negotiate these with the author first. (I often ask them to test my version of a patch when I have style suggestions but don't have access the target platform or problem it solves.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Is this just for the sake of the experiment or this patch selection is the one you really haven't had the time to deal with? I see a couple of patches proposing GC implementations (a very delicate issue) of which only half a single patch would be acceptable for now (the one renaming malloc to PyMem_Malloc). There's one message (No 8) suggesting modifications to README and to the python.org Web page. How can we help with that? I have problems understanding two patches submitted by Gerrit Holl. They mention "Hallo Guido". :-)
Understood. Sharing your collection of suggested patches definitely increases your chances to get some help and answer the authors in time! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

These are ones that I really haven't had the time to deal with (witness the dates on some).
Maybe you can help me formulate a reply? I guess the patch collection isn't just about patches -- it's about the general level of effort that some patches require. I just don't feel comfortable with saying "no" without a good reason, and "no time" isn't a good enough reason. So I welcome any form of comments on these patch proposals.
There's one message (No 8) suggesting modifications to README and to the python.org Web page. How can we help with that?
The README is checked into the CVS. For the web page I will gladly accept patches to the HTML.
I have problems understanding two patches submitted by Gerrit Holl. They mention "Hallo Guido". :-)
Oops, sorry. The first one is proposing a validate() function for pathnames. In the second one, the patch code speaks for itself -- it makes an exception class conform to the rule that exceptions must inherit from Exception.
Thanks. Apart from Tim Peters who immediately tackled a typo in the FAQ, no-one else has offered any help with these. I'm glad that you've at least taken the time to look at them. I'm still being inundated with patches... But as long as this experiment hasn't shown more success I will keep them in my inbox. Or is there a better idea? Should I forward all patches I get to python-dev? To a separate list? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Understood.
Or is there a better idea? Should I forward all patches I get to python-dev?
Certainly not. This isn't the purpose of the list, except maybe if a patch is too fundamental to be just a patch. :-)
To a separate list?
This would be fine. A public list discussing all submitted patches would be helpful. There are some patches that require routine testing that few people here would find the time to perform. Others require "critical mass" of opinions to be adopted, rejected or deferred. Maybe we could set the gross operation mode of such a list as follows: You publish systematically all patches (except those that get checked in directly) The discussion focuses patches submitted during the past month. Some of them are accepted, some are rejected, many are "deferred" (for various reasons). Deferred patches are those that have an undecided future and get archived. In this case, a mail notification is sent to the author explaining the situation. If the author thinks the patch is worthy and "decidable", s/he has to resubmit the patch for reviving the discussion on the list and for trying to gain more proponents/favorable opinions. (because the list is discussing 1 month old patches only). If the author pushes real hard, either a decision would be taken, either s/he will end up convinced that the patch is "undecidable" for the time being :-). Besides, all serious patchers would become members of this list, which isn't so bad (given that presently, you're the only contact person for patch related material/submissions and you're mainly discussing a subset of the submissions, one-by-one, with the authors in person). This operation mode would ensure that the "light" patches, mostly the various bug fixes, will end up with a decision. The "hard" ones, those that introduce new functionality or behavior, will be seriously discussed and will eventually end up deferred (and archived) for future consideration. Thus, the archive would constitute yet another "memory" of the development process, accessible to all interested parties. This forum, like python-dev, would have a consultative mission, preserving your decision rights, so it's something you'd probably want to try (provided that you fix the rules of the game at its creation). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> The README is checked into the CVS. For the web page I Guido> will gladly accept patches to the HTML. I'm willing to put the entire python.org web site under CVS. This would at least make it easier for others to send us patches to the .ht files against the latest revisions. Is there any interest in this? It wouldn't take me long. Guido> Or is there a better idea? Should I forward all patches I Guido> get to python-dev? To a separate list? Probably a separate list. xemacs.org runs a xemacs-patches mailing list with a replybot on it that scans for patches. It sends back a different response based on whether it finds a patch or not. Then there's a group of lieutenants that keep an eye on the patches and work out their applicability. We could set something like that up fairly easily. -Barry

This sounds like a useful idea. It should also check for the disclaimer text and send an appropriate apply if a patch is found without a disclaimer. Of course, the replybot would need to be smart enough to find things like patches hiding in BASE64-encoded attachments... On the other hand, perhaps it would be better to deal with patches the same way as with bug reports -- the Jitterbug database isn't perfect, but it makes it possible to check regularly whether something has been dealt with or not, much better than a simple mailing list. (There are already lieutenants scanning the bugs traffic, so that part doesn't change.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> This sounds like a useful idea. It should also check for Guido> the disclaimer text and send an appropriate apply if a Guido> patch is found without a disclaimer. Guido> Of course, the replybot would need to be smart enough to Guido> find things like patches hiding in BASE64-encoded Guido> attachments... Guido> On the other hand, perhaps it would be better to deal with Guido> patches the same way as with bug reports -- the Jitterbug Guido> database isn't perfect, but it makes it possible to check Guido> regularly whether something has been dealt with or not, Guido> much better than a simple mailing list. (There are already Guido> lieutenants scanning the bugs traffic, so that part doesn't Guido> change.) Maybe then just use Jitterbug to collate patches. That's what a lot of my JPython users do. -Barry

On Wed, 2 Feb 2000 bwarsaw@CNRI.Reston.VA.US wrote:
Personally, I'm more comfortable knowing that I can email a patch (rather than dropping it into a bug db), and that will get handled by a human. The patch handlers could certainly use Jitterbug as arbitration, but I would think the list itself would make that reasonably clear. Note that "patches@python.org" could become THE place to submit patches. Sure, Guido would get some patches still, but some of the load will drop from his direct Inbox (yet he'd still get the patch as a subscriber). When the patch handlers had a "final" patch, it would get sent straight to Guido (with some "final" marker on it). etc etc. I'm sure there is a lot discussion that can take place on the exact mechanics. Until people will *volunteer*, I think the discussion of mechanics can be postponed. No need for a peanut gallery here :-) Cheers, -g -- Greg Stein, http://www.lyra.org/

On Wed, 2 Feb 2000, Greg Stein wrote:
Maybe then just use Jitterbug to collate patches. That's what a lot of my JPython users do.
<prefers e-mail to web-based>
Note that "patches@python.org" could become THE place to submit patches. <snip>
OK, I want to know one thing: is everyone comfortable with my suggestion of a seperate list, with a reply-to: python-dev? Barry said he'd be willing to hack it in, and everyone who talked seemed like this idea is similar to what they have in mind. The sooner a consensus is reached, the less patches Guido will have to deal with. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

On Thu, 3 Feb 2000, Moshe Zadka wrote:
I don't advocate the reply-to (see my other email).
It won't reduce his load unless we have actual volunteers that will truly do some handling of the patches. I'm assuming the current volunteer list is: - Guido (he volunteers whether he wants to or not :-) - Moshe (??) - Greg in April Others? Cheers, -g -- Greg Stein, http://www.lyra.org/

On Wed, 2 Feb 2000, Greg Stein wrote:
Part time -- I'll take responsibility for the patches that interest me. There will likely be a few, and I *love* installing patches off the net, just to test my security measures <0.3 wink>
Others?
I assume you'll get a similar response from many people: hopefully, for each patch it will either get booed automatically (hey! I just added braces instead of indentation to the parser) or will interest someone. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

The thing here that makes me slightly uncomfortable is how to keep track of patches that nobody picks up. a Jitterbug database would nicely do this, but I agree that it's inconvenient and overkill for other reasons. Perhaps we could use the "Linus Torvalds' inbox algorithm"? (When it overflows he deletes everything; "if it was important they'll send it again.") --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2 Feb 2000, Guido van Rossum wrote:
1. This discussion is in the (as you put it) niceties are. You are unlikely to get that many patches that it is an *immediate* problem. 2. mailman (what fun to me! I'm dumping work on Barry) could be hacked (or hooked) into doing that: it can keep a list of all patches which never got a reply in whatever list is being "replied to:" (that would neccessitate developers to CC the list, at least on the first post, but that's probably a good idea to do anyway) and send a mail message after a week to a patch-submitter who hasn't gotten a reply with a notice to the effect that nobody seems interested in it so he should make a bit more noise. 3. Like in the CP4E BOF we're getting all geeky again (which is fine, since we're all geeks). Just get something out of the door! Even a mailing list with no policy at all to who sends to it is infinitely better then Guido's mailbox, as much as we all respect that mailbox. We'll argue the fine points of exactly how to score automatically irrelevant patches (and I've got just the algorithm <0.9 wink>) later. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

"MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:
MZ> 2. mailman (what fun to me! I'm dumping work on Barry) could MZ> be hacked (or hooked) into doing that: Not a good strategy right now :) Here's my proposal, from short term/easy to long term: 1. Create patches@python.org which will be the official advertised address to send patches. This will be a Mailman mailing list to which anybody can post, but to which subscriptions are closed. Amount of work: trivial. 2. Create patches-discuss@python.org which will be the address to discuss patches@python.org postings. We make Reply-To: for patches@ be patches-discuss@ Amount of work: relatively small (for me to hack Mailman) 3. If someone will write a Python function to scan a string, returning true or false as to whether it contains a patch, I will integrate this into Mailman so that if a patch is found, it will be forwarded to the Jitterbug database address. Ideally this filter would check to be sure that the disclaimer text is included, but that's not necessary. Guido (or someone) is still going to have to decide whether the small text or a wet signature is necessary. Amount of work: Fairly non-trivial for someone other than Barry Not too bad for Barry to hack this into Mailman 4. When !?ng frees Roundup we look at adopting it. From everything that I heard about it, it's OHS (official hot shit). I want, I want! :) Amount of work: none now, except for !?ng :) Later, some for one of us CNRI'ers 5. Move the whole kit-and-kaboodle to SourceForge (or server51.freshmeat.net which looks to provide many of the same services). We cannot be the only project facing these same issues, so let's leverage off of what others have done. Amount of work: unknown, but I'm looking into it for Mailman -Barry

Why do we need two lists? For my own email processing I don't see how it will make a difference. A reply-bot could check whether there's a "Re:" in the subject or not to decide whether to send an acknowledgement. --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> Why do we need two lists? For my own email processing I GvR> don't see how it will make a difference. A reply-bot could GvR> check whether there's a "Re:" in the subject or not to decide GvR> whether to send an acknowledgement. Okay, fine with me.

Barry:
Given that VA Linux is buying Andover.net (parent of freshmeat.net), I doubt the two will remain as competing solutions. =) http://www.businesswire.com/cgi-bin/f_headline.cgi?day0/200340020&ticker=lnu x|andn --david

Let me just note the whole thing sounds great! I'm for it. On Thu, 3 Feb 2000, Barry A. Warsaw wrote:
... We cannot be the only project facing these same issues, so let's leverage off of what others have done.
As a point to think about, linux-kernel have a very non-high-tech solution that works, but for some reason causes everyone shivers: high volume mailing list, with patches and discussion of patches, and Linus's mailbox, in which patches from known hackers are more streamlined. That's the ultimate in flexibility ;-) I don't know how many people here ever subscribed to linux-kernel, but as someone who compiled a new kernel every week for a few months, I just want to say that it works <0.6 wink> -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

On Wed, 2 Feb 2000, Guido van Rossum wrote:
We have a mailing list to archive the patches, so the "delete all" approach becomes a bit harder :-). Note that the approach requires feedback to be successful. The patch author must watch CVS to know if the patch went it. Otherwise, the patch handlers would be required to notify the author one way or another. With the notify route, then we'd have to state something like "you should resend if you haven't heard back within X weeks." But the notify/resend approach also creates an expectation that a patch *will* be handled within a *specific* timeframe. Dunno what I'd think the policy should look like right now. More thought needed on my part, so I'll just defer until a list is set up and discuss there... Cheers, -g -- Greg Stein, http://www.lyra.org/

From: "Guido van Rossum" <guido@CNRI.Reston.VA.US> To: <python-dev@python.org> Sent: Wednesday, February 02, 2000 4:50 PM Subject: Re: [Python-Dev] patch handling (was: Python 1.6 timing)
Sourceforge has a nice patch manager which allows a GUI'ish view of patches in context, discarding/deferring/etc. The code is available and open source. --david

On Wed, 2 Feb 2000, David Ascher wrote:
However, I think I'd still like to be able to 1. send patches by e-mail (I don't always want to fire up a browser) 2. receive patches by e-mail (think of it as select() instead of a busy wait ;-) If the patch manager allows that/can do that with a simple addition, I'm for it. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

Another idea is to steal Ping's very cool idea of a 'nosy list'. If you missed his short talk at IPC8, he has a system which is a frontend to their bug database (but I think it would work well with patches). As far as I understood, folks submit bugs via an email message. Each email message has an _implicit_ mailing list, which is made up of all the people who either 'register' interest in the bug/patch, or who reply to the submission. That way there is an automatic broadcasting of the discussion to those parties interested in the topic at hand, and only those. Maybe Ping can explain in more detail how it works. It seemed like a brilliant idea to me. --david

Another idea is to steal Ping's very cool idea of a 'nosy list'.
I missed it. Sounds an interesting long-term solution. I've heard about a similar concept elsewhere: you never unsubscribe to a list, each subject has its own list, and subjects just die. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2 Feb 2000, Guido van Rossum wrote:
Yup, that's the general approach. The short paper is at http://www.lfw.org/ping/roundup.html; here is an excerpt describing the mechanism: a. New issues are always submitted by sending an e-mail message. This message is saved in a mail spool attached to the newly-created issue record, and copied to the relatively large user community of the application so everyone knows the issue has been raised. b. All e-mail messages sent by Roundup have their "Reply-To" field set to send mail back to Roundup, and have the issue's ID number in the Subject field. So, any replies to the initial announcement and subsequent threads are all received by Roundup and appended to the spool. c. Each issue has a "nosy list" of people interested in the issue. Any mail tagged with the issue's ID number is copied to this list of people, and any users found in the From:, To:, or Cc: fields of e-mail about the issue are automatically added to the nosy list. Whenever a user edits an item in the Web interface, they are also added to the list. The result is that no one ever has to worry about subscribing to anything. Indicating interest in an issue is sufficient, and if you want to bring someone new into the conversation, all you need to do is Cc: a message to them. It turns out that no one ever has to worry about unsubscribing, either: the nosy lists are so specific in scope that the conversation tends to die down by itself when the issue is resolved or people no longer find it sufficiently important. The transparent capture of the mail spool attached to each issue also yields a nice searchable knowledge repository over time. In practice, this has worked fairly well for developers at ILM, and no one has complained about missing mail they wanted or getting mail they didn't want -- which, given the apathetic nature of programmers, i suppose one could interpret as a positive empirical result. -- ?!ng "There's no point in being grown up if you can't be childish sometimes." -- Dr. Who

[Greg Stein asks ...]
Sure -- but can't make a concrete time commitment. The time I've been able to make so far amounted to changing three letters in a FAQ <wink/sigh>. I hope the Jitterbug idea is adopted: clunky as it is, it's public, searchable, has categories (so supports *some* rudimentary notion of workflow), and doesn't tie up my 28.8 modem <wink>.

Greg Stein writes:
I can certainly help out a bit, at least for small patches and anything related to the documentation (including additions of docstrings to module sources and the like). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Yes, let's do it. I actually think the reply-to is unnecessary to start (it's just a nicety). --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2 Feb 2000, Barry A. Warsaw wrote:
Ummmm...would this be the wrong time to ask how the redesign contest is going on?
A definite aye vote, though perhaps that's an overkill. As long as we're comparing other Free Software projects, let me just note that on linux-kernel, patches are part of the regular discussion. Whoever feels like it, runs a modified kernel, and reports the result. Patches are then chosen (in part) by the responses of people who have tried them out -- a very good QA mechanism. Just to brainstorm about the process. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

Ummmm...would this be the wrong time to ask how the redesign contest is going on?
I haven't seen any submissions. Maybe Barry has?
Good point. At the moment I am the sole arbiter for patches, and I'm tired of it. --Guido van Rossum (home page: http://www.python.org/~guido/)

"MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:
MZ> Ummmm...would this be the wrong time to ask how the redesign MZ> contest is going on? It isn't, AFAICT. I had two people come up to me at the conference and ask a few questions, with a promise to have something "soon". I had one other person email me a few weeks before the conference. But we've seen nothing, so I'm not very hopeful. MZ> A definite aye vote, though perhaps that's an overkill. As MZ> long as we're comparing other Free Software projects, let me MZ> just note that on linux-kernel, patches are part of the MZ> regular discussion. Whoever feels like it, runs a modified MZ> kernel, and reports the result. Patches are then chosen (in MZ> part) by the responses of people who have tried them out -- a MZ> very good QA mechanism. Just to brainstorm about the process. Mine's just one vote, but I really do not want to see patches floated on python-dev. -Barry

On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote:
Mine's just one vote, but I really do not want to see patches floated on python-dev.
How 'bout a seperate list with a Reply-To: python-dev? -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

"MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:
MZ> On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote: >> Mine's just one vote, but I really do not want to see patches >> floated on python-dev. MZ> How 'bout a seperate list with a Reply-To: python-dev? That would work for me. I need to hack Mailman a little to add this feature, but it could be done. -Barry

On Wed, 2 Feb 2000 bwarsaw@cnri.reston.va.us wrote:
Note that I requested this feature for Mailman a while back. I'd like to use it for the "checkin" mailing lists that I run. Send to checkins, respond to the discussion list. Currently, my CVS automailer just inserts a Reply-To:, but it would be nice to have it directly on the mailing list itself. (view it more as a Followup-To: for mailers, rather than Reply-To munging) In this particular case, I think the "patches mailing list" would be a self-contained list discussing a *patch*. Sure, it could certainly migrate to python-dev when appropriate, but I think the majority of the discussion should stay on the patches list. Otherwise, we'd just be spamming the -dev list as if the patches list didn't exist. Cheers, -g -- Greg Stein, http://www.lyra.org/

On Wed, 2 Feb 2000, Greg Stein wrote:
I retract my suggestion. Have python-patch, python-patch-discuss (python-patch would be replied-to: python-patch-discuss) and keep python-dev as a clean list. This way, people could just subscribe to python-patch, and when they get a patch they're interested in, they could subscribe to the discuss mailing list. That way, people could also subscribe to python-patch-discuss without subscribing to python-patch, to avoid the large attachments that would be sent by python-patch. Of course, mailman's new feature would automatically extract those attachments and post them up, so they can be downloaded by non-subscribers. enough-with-the-blabber-let's-just-get-something-going-ly y'rs, Z. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

On Thu, 3 Feb 2000, Moshe Zadka wrote:
Guido/Barry can decide on the final structure, but I'd recommend something a bit different: 1) drop the python- prefix. These are @python.org 2) just have "patches@python.org" I'm assuming the mailing list would be Guido-approved and the people on it would be required to "deal with the patch size". I think an open list might generate some noise rather than just "work". But again: the structure is ultimately up to Guido. Oops. I see a post from Guido saying "let's do it." In that case, it is probably best to move this discussion to the new list. I believe we need a statement of subscription policy from Guido. Or at least something to the effect of "python-dev members are free to subscribe, but you are expected to directly/positively contribute." I am presuming in all cases, that it would be administratively closed to non-python-dev members. Cheers, -g -- Greg Stein, http://www.lyra.org/

Moshe Zadka writes:
I'd be fine with this as well. If Ping can release his issue-tracker any time soon, that would also be a really nice tool. That was quite impressive. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

"MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:
MZ> Ummmm...would this be the wrong time to ask how the redesign contest MZ> is going on? BAW> It isn't, AFAICT. .... Perhaps the occasional reminder posted to c.l.py would stimulate a bit more activity. I don't recall seeing anything. I stumbled upon the menu item on the PSA web site awhile ago. Otherwise I probably wouldn't have known what Moshe was referring to. Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 "Languages that change by catering to the tastes of non-users tend not to do so well." - Doug Landauer

Guido van Rossum writes:
Oops, sorry. The first one is proposing a validate() function for pathnames. In the second one, the patch code speaks for itself -- it
I did have a thought on this, but hadn't gotten back to it. Essentially, I'm not sure how to implement this correctly; things like MAXPATHLEN aren't always easy to root out the "right" way to get the *real* definition from C. pathconf(_PC_PATH_MAX) could be used to get that, and pathconf(_PC_NAME_MAX) can get the maximum length of an individual name within the path, but I don't know if the concepts are even meaningful on all systems. I wouldn't be surprised if validity on some systems is highly specific to the actual filesystem that's being referred to, and that requires the name be valid on the local system. I've noticed that the functions in the os.path implementations fall into two categories: "abstract" functions like join(), split(), and the like, which are bound to the "path algebra" syntax rules, and the "local-access" functions like isfile() and abspath(), which require the paths relate to the local system. This isn't a problem, but something we should probably keep in mind.
makes an exception class conform to the rule that exceptions must inherit from Exception.
I don't think this is valuable for 1.6, but might be interesting for 1.7; the documentation can include a notice that this relationship will be required in the future. That would allow people to define exceptions with the required inheritance before the last minute. On the other hand, I'm not sure it really matters that exceptions inherit from a specific base class. *That* seems unnecessary. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

I personally think there is very little merit in a validate() function -- it's not going to be a very useful predictor of whether an open may succeed or not.
This is valuable mostly as an example; plus in that specific case I think he noticed that the module defines an exception class from scratch with functionality that is already present in the standard Exception class. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2 Feb 2000, Guido van Rossum wrote:
I looked through some of them, but (as I mentioned) would defer any real action until the April timeframe. At that point, I'd be more than happy to dig in and start handling them. Properly responding to them (in a group context) would probably need a bit of coordination infrustructure...
Or is there a better idea? Should I forward all patches I get to python-dev? To a separate list?
<IMO> A new list. python-dev is very constructive in that it typically has one, maybe two or three, threads going at once. Throwing patches into the mix, and possibly unreasonable/unqualified patches, would seem to be quite a disruptive influence. The (smaller) list could be much more focused, and could hold just the truly active reviewers. People who are "just interested" could wait for the CVS checkin notices or become active :-) </IMO> Cheers, -g -- Greg Stein, http://www.lyra.org/

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been Guido> thinking about making classes be types (not as huge a Guido> change as you think, if you don't allow subclassing Guido> built-in types), and adding a built-in array type suitable Guido> for use by NumPy. I've also received a conservative GC Guido> patch that seems to be fairly easy to apply and has some of Guido> Tim Peters' blessing. All very cool things that could easily wait until 1.7. After all, what's in a number? If, as Andrew puts forth, getting a stable Python release with Unicode is very important for Python's future positioning, then I say let's go with his more modest list, mainly Unicode, sre, and Distutils. We've already got string meths, tons of library improvements, and sundry other things. That's a good enough laundry list for the next release.

Barry A. Warsaw [bwarsaw@cnri.reston.va.us] wrote:
Heck, Python is infinately more conservative in its numbering than a lot of projects. All that was mentioned would normally be enough to call it 2.0 easily. :-) Modesty can be counter productive in PR business...also there is the issue of having two copies of 1.5.x installed at the same time, which with Unicode could be a manjor consideraton for some of us. For me, numbering has always been (and I try and keep it this way with Zope): X.Y.Z X = structural changes, backward incompaibility Y = new features Z = bug fixes only Chris -- | Christopher Petrilli | petrilli@amber.org

[Christopher Petrilli]
Indeed, where I work a number of managers met the suggestion to use Python 1.5.x with "what?! we don't want to use software that's barely out of alpha release -- besides, Perl is already on release 5". I hear that Guido got normal American glasses -- time to do normal American hyperinflated version numbering too. heck-ms-windows-will-soon-be-at-version-2000<wink>-ly y'rs - tim

Barry A. Warsaw writes:
I'm not clear on the status of these various things; how many of these changes are deep ones that need lots of design, or affect massive amounts of the code base? For example, revamped import is a tricky design problem (as we've seen on this list). Is the spec for rich comparisons clearly defined at this point? Something like the parallel for loop seems like a parser modification combined with a code-generator modification, with no subtle implications for the rest of the implementation, and so that seems a simple matter of programming -- a week or so of effort. (Maybe I've missed something?)
Similarly, does the conservative GC patch splatter changes all over the place, or is it very localized? Is adding the NumPy array type straightforward? Remember, there would presumably be a couple of 1.6 alphas and betas to shake out bugs.
From a political standpoint, I'd call the next release 1.6 and not bother with another installment in 1.5.x series. And I agree with
Fair enough; forget about the 1.5.5 suggestion, and call it as 1.6.
tree. My free-time plate is pretty full with JPython and Mailman, but I'm willing to help where possible.
Ditto. -- A.M. Kuchling http://starship.python.net/crew/amk/ One trouble with being efficient is that it makes everybody hate you so. -- Bob Edwards, the Calgary Eyeopener, March 18, 1916

[Andrew M. Kuchling]
Part of its problem is that it's *too* localized (which was, paradoxically, I suspect part of its initial quick-eyeball appeal to Guido -- it "looks like" an amazingly self-contained patch). For example, all the code to chase pointers in various types of objects is hiding in a single function, which does a string of "if type is list then this else if type is tuple then that ..." tests. This stuff clearly needs to be distributed across the object implementations and dispatched to via a new slot in type objects; there's no code for that now. I expect it would take a minimum of two weeks (full-time work) to make this code ready for prime time (but mostly to slash the space and time use -- and with no certainty of "good enough" in the end). BTW, "conservative" is a misleading adjective for this approach -- it never guesses ("guessing on the safe side" whether or not some bit pattern is a pointer is what "conservative" customarily means in the GC world).
Is adding the NumPy array type straightforward?
DavidA nixed that one in no uncertain terms! maybe-hp-will-give-up-unicode-and-we-can-release-tomorrow-ly y'rs - tim

"BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes: "Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been thinking Guido> about making classes be types (not as huge a change as you Guido> think, if you don't allow subclassing built-in types), and Guido> adding a built-in array type suitable for use by NumPy. I've Guido> also received a conservative GC patch that seems to be fairly Guido> easy to apply and has some of Tim Peters' blessing. BAW> All very cool things that could easily wait until 1.7. After BAW> all, what's in a number? If, as Andrew puts forth, getting a BAW> stable Python release with Unicode is very important for BAW> Python's future positioning, then I say let's go with his more BAW> modest list, mainly Unicode, sre, and Distutils. We've already BAW> got string meths, tons of library improvements, and sundry BAW> other things. That's a good enough laundry list for the next BAW> release. We've had this conversation before, so it'll comes as no surprise that I agree with you. Question: If we go with the feature set you've described, when will those features be ready? What kind of schedule could we set for releasing the first alpha? Jeremy

[I just got GvR's post on the topic, but I'll send this anyway] BAW:
All very cool things that could easily wait until 1.7. After all, what's in a number?
Guido has promised some of those features as being in 1.6 at conferences in the past, but I agree that string methods for example are a more major change than I'd expect to see in a 0.0.3-delta version change. Maybe with a deadline (as Greg suggests) we can integrate some of the pending patches (I agree with Greg that I at least would have found the time for a revised patch for rich comparisons if I'd had a deadline -- call me human =). Coercion and extended slicing also seem like relatively minor changes, compared with changing everything to be a class or adding GC! Regardless, just like Greg, I'd like to know what a pumpkin-holder would mean in the Python world. I propose that it be called the Oracle instead. As in, whoever is Oracle would get some training with Tim Peters and learn how to channel G__do. As a Python user, I'd be most comfortable with such a change if the Oracle just took over the technical stuff (reviewing patches, CVS checkins, running tests, corralling help for doc & code, maintaining release notes, building installers, etc.), but that the important decisions (e.g. whether to add a feature to the core language) would be checked with G__do first. We could call the position "Administrative Assistant", but somehow that doesn't have the prestige. A progressive schedule where Guido watches over the Oracle periodically would probably help build trust in the new mechanism. The Oracle would be expected to ask Guido for his opinion with everything at the beginning, and as a trust builds between Guido and the Oracle and the community and the mechanism, progressively less. --david ascher

On Thu, 20 Jan 2000, Ken Manheimer wrote:
The "pumpkin" term comes from Perl-land... I'm not super clear on the pumpkin-holders's entire job, but I think it is basically the guy who sees that the version for which he "holds the pumpkin" is completed and shipped. Not necessarily by himself :-), but as the overseer (or "release manager" if you will). The current Perl pumpkin-holder is a guy at ActiveState. I think it changes for each version. Cheers, -g -- Greg Stein, http://www.lyra.org/

We'd have to rework the CVS arrangement in order to give non-CNRI employees write access to the tree. I think I know how I'd go about this, and it wouldn't be too hard, just a bit time-consuming. If that's the way we're going to go, I can start making plans. -Barry

[Barry]
I think before you make such changes you'd have to talk to Bob (good luck). I don't mind applying patches and doing the checkins -- it's the decision-making that's time-consuming. --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> I think before you make such changes you'd have to talk to Guido> Bob (good luck). Heh. Guido> I don't mind applying patches and doing the checkins -- Guido> it's the decision-making that's time-consuming. Then maybe the current CVS arrangement is fine (cool with me). -Barry

On Thu, 20 Jan 2000, Barry A. Warsaw wrote:
Though it may be moot if guido's going to continue mediating the checkins, maybe this would be interesting (if only for barry, to compare procedures). We basically use a captive cvs-":ext:"-over-ssh method, where the captive .ssh/authorized_keys command is quite succinct: command="set $SSH_ORIGINAL_COMMAND; shift; exec cvs $@" 1024 35 ... The shellisms (set/shift/exec cvs $@) lock the user of the qualifying key into executing a cvs command, and only a cvs command. Also, for us the checkins are to a public mirror of our CVS repository, so penetration of the security there doesn't jepordize the master repository base. We don't currently have any outsiders checking into our master repository, and it doesn't seem to me that CVS provides sufficiently managable discretion for doing that. Oh, and a disappointment - the account under which cvs conducts the checkins is the account on the CVS server host, not that of the host where the checkins are being done. This means that you can't use a single account to serve multiple remote users (preventing masquerading quite reliably by using a separate authorized_key public-key entry for each remote user). Therefore we have to have distinct (nailed-down) accounts for each checkin-privileged person - more management burden. Ken

On Thu, 20 Jan 2000, Barry A. Warsaw wrote:
Or move the CVS tree off-site. Cheers, -g -- Greg Stein, http://www.lyra.org/

On Fri, 21 Jan 2000, Barry A. Warsaw wrote:
I was under the impression that CVS access restrictions are based on CNRI security policy. If the CVS repository moves elsewhere, then many people can access it without impact on CNRI's network and security policies. However, if the external access issue is based on legal reasons (for example, only CNRI people should alter Python code), then yes: moving the repository will buy nothing. Cheers, -g -- Greg Stein, http://www.lyra.org/

"GS" == Greg Stein <gstein@lyra.org> writes:
GS> I was under the impression that CVS access restrictions are GS> based on CNRI security policy. If the CVS repository moves GS> elsewhere, then many people can access it without impact on GS> CNRI's network and security policies. Well, access to our /internal/ network is of course restricted. CNRI employees have write access to the tree by virtue of access to the filesystem (i.e. by NFS). My current arrangement for external ssh mediated access to a writable cvs server on an internal machine is a hack and not something that I want to perpetuate if more users were added. GS> However, if the external access issue is based on legal GS> reasons (for example, only CNRI people should alter Python GS> code), then yes: moving the repository will buy nothing. I'll let Guido comment on policy concerning write access to the Python CVS tree. From a technical standpoint, if this is something Guido wanted to extend to non-CNRI employees, the way to do it would be to host the primary repository on a CNRI machine outside our firewall, e.g cvs.python.org. At that point, we'd be accessing the tree the same as anybody else. -Barry

On Fri, 21 Jan 2000 bwarsaw@python.org wrote:
Gotcha. Sounds great! I'm not sure yet that Guido is looking for external people to do checkins (as opposed to delivering refined patches to him)... So we probably don't need an assessment from the legal department :-), but if Guido already knows, then I'd be curious. thx! -g -- Greg Stein, http://www.lyra.org/

[David Ascher]
I'm afraid that wouldn't work. The whole secret to channeling Guido in the *past* was to have been an ABC user: all you had to do is notice the things about ABC that you loved and the ones that would drive any sane *experienced* programmer mad with frustration. Voila! Guido's mind is your mind <wink>. But the more Python sails into uncharted waters, the less reliable my Guido-channeling pseudo-skills get. He is, in Essence, Unfathomable. Also indispensable.
Definitely. But where do you find someone like that? It's (or at least *should* be) several full-time jobs. Languages like Icon & Scheme do it via university association (scads of grad student slave labor); REBOL did it by floating a trendy Internet business plan that actually attracted enough venture capital to hire about 30 people; Python, unfortunately <wink>, seems to attract people who already have demanding jobs. So I see it as an issue of finding warm bodies more than anything else. In the absence of funding "real jobs", I really don't see much hope. Bits & pieces can be farmed out (e.g., I doubt Guido has had to do any work on the regular expression code since Andrew arrived), but that's it -- I expect the past predicts the future quite accurately here. Certainly much more *could* be "farmed out", but no single volunteer of the kind Python has attracted so far is going to do a lot on their own month after month after month. Even with the best of intentions, their "real life" will interfere severely more often than not (voice of experience, there -- and I'd guess it's the same for *all* of us). if-something-doesn't-change-nothing-will-change<wink>-ly y'rs - tim

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> REBOL did it by floating a trendy Internet business plan that TP> actually attracted enough venture capital to hire about 30 TP> people; Python, unfortunately <wink>, seems to attract people TP> who already have demanding jobs. I think all we have to do is change the name for 1.6 to LinuxPython 2.0, then split off and go IPO. The more money we lose, the higher our stock will go and we can use our market cap to hire all those warm bodies. -Barry

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> [David Ascher]
TP> I'm afraid that wouldn't work. The whole secret to channeling TP> Guido in the *past* was to have been an ABC user: all you had to TP> do is notice the things about ABC that you loved and the ones TP> that would drive any sane *experienced* programmer mad with TP> frustration. Voila! Guido's mind is your mind <wink>. I have discovered another approach. CNRI put in a cleam room on the second floor last year. I recently discovered a little door behind some metrology device in a corner of the clean room. The door opens onto a tunnel that leads directly into Guido's mind. Unfortunately, it won't be of much use for a pumpkin-holder or channeler, because after about 15 minutes you are deposited on the shoulder of the Dulles Toll Road. who-wants-to-be-John-Malkovich-when-they-could-be-Guido-ly y'rs, Jeremy

On Sun, 23 Jan 2000, Jeremy Hylton wrote:
I almost fell out of my chair laughing when i read this. What do you think would happen if Guido went into the tunnel? Perhaps http://www.lfw.org/jminc/Guido/http://www.python.org/ (What you get is a generalization of some earlier silliness... the description of the original is at http://www.lfw.org/jminc/.) -- ?!ng

Guido van Rossum wrote:
(snip)
(snip) What is the basis of the Python numbering scheme? I thought that there was a notion that: - The first part changed with huge, possibly backward incompatible, changes, - The second part was for new functionality - The third part was for bug fixes. I thought I saw this scheme referenced somewhere and possibly even attributed to Guido. (?) I think that this is a better scheme that what I've seen with the 1.5 releases. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

On Thu, 20 Jan 2000, Guido van Rossum wrote:
I agree with Andrew's basic premise.
Options I can think of:
1) Delegating some control to a pumpkin holder [...].
Seems fine.
Icky. :-)
Call it 1.6, per the rest of the thread.
Unicode: definitely. distutils seems pretty early, but I bet that some key concepts could be added to 1.6, to make the transition and continued development easier. Note that if an announcement were made to the effect of "feature freeze on February 15; only bug fixes afterwards," that you would get a lot of people scrambling to submit their pet features. This would be a good way to light some fires, to see what kinds of things get completed (i.e. we may think some things aren't ready or are too far out, put that deadline in and those positions could change...)
I'm waiting for that review :-) If you raise issues, then I can knock them down. I don't see all that many at the moment. But I'm biased :-)
I would volunteer for the pumpkin... around April-ish. My plate is rather full with completing mod_dav and then integrating that into Apache 2.0. Once the Apache integration begins, then I'd have some more free time. But this begs the question of: what does the pumpkin-holder mean in the *Python* world? If it is collating fixes, producing snapshots, etc, then I'm comfy with it. If it also contains responsibility for specific kinds of work, then Fred would probably veto me :-), as I've got an outstanding doc that I owe him (for about six months now... sigh; maybe I'll bribe MAL to write it; he knows the interface :-)). But stll: what's it mean? How does the pumpkin reduce the Guido-load, yet still enable the Guido-control? [ I just had a talk about this with the guys at Inprise, re: InterBase, mentioning that the Dictator model works well for Python, but doesn't necessarily work well for new projects or commercially-started projects due to control/prejudice issues. Python people like it because of the resulting simplicity and cleanliness; I doubt we want a pumpkin approach that would allow that to go away! ] Cheers, -g -- Greg Stein, http://www.lyra.org/

Call it 1.6, per the rest of the thread.
OK. I expect I'll get some complaints from some people who asked when 1.6 would be out (I've generally told them end of 2000); but it sounds like a 1.7 would be necessary to fulfill the other promises, so it shouldn't really matter -- it's all a case of relabeling for PR purposes.
The point of adding distutils is that it will allow distribution of packages without including distutils with each distribution. Since distutils was about 200K itself last time I looked, this is important. I don't believe it would be good to have to say "My FooBar package is really easy to install. All you need to do is download and install distutils, (which by the way is a 200K package that you have to manually install), and then run "python setup.py" in the FooBar root directory..." This would be enough for the average person to run away screaming. I think I saw a distribution by AMK that had a setup.py that tried to use distutils but had a crude fallback if distutils didn't exist; however that defeats much of the purpose since the package author has to figure out how to do the fallback. Large distributions (e.g. NumPy) can afford to squeeze distutils in a corner of their distribution, but for the average package it wouldn't be of much use. In other words, I'm for putting distutils in the next release, essentially feature-freezing it. Greg Ward, what do you think of that?
I bet you we couldn't complete the import hooks by that date; I consider imputil.py as a nice prototype, but the integration with the C code is still missing. Also the 50% slowdown is a problem I worry about for inclusion a production version. (Plus breakage of everybody else's code who uses or hacks __import__; e.g. have you tested it with rexec?)
It was kept up by the need to get the types documents out.
Good questions. I have to say that I feel reluctant to release any kind of control -- yet at the same time I desperately need help getting trivial stuff checked in. One of the most important time-consuming tasks is quality control: collecting fixes is all well and good, but I routinely reject fixes that superficially look fine, because they are subtly broken, or interfere with other plans, or just because the code looks poorly written. I also spend a lot of testing before I check things in; running the standard test suite is a good safeguard against general breakage, but you really have to play with the code affected by the change before you can know that it works as advertised. My work attitude here means that what gets checked in is generally rock solid, and that helps Python's reputation; but it is very costly...
Agreed, of course. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, 20 Jan 2000, Guido van Rossum wrote:
Oh, don't get me wrong. I'd like to see it in there for at least all the reasons you cite. But it seems (to me) that it is still pretty alpha. But hey: I'm shooting from the peanut gallery; we need GregW's comments.
hehe... if the static typing is to be deferred, then I'll take that bet! [discussion omitted; too tangental to this thread right now...]
Reading your comments below, we may be able to help. First, presume that at least one (best would be several) people man the "front lines" for any/all patches and bug reports. The front line can deal with the bug reports, mostly by responding with "go away; enter it into Jitterbug." Patches fall under several catagories, detailed below:
Conversely, your "lieutenants" (LTs) would filter all ugly-looking patches.
because they are subtly broken,
If the LTs didn't catch these, then you could catch them from the checkin diff email. However, the LTs would reduce the number of broken ones that you would review.
or interfere with other plans,
The LTs may know of this, but if not: you'd catch it at checkin time. The patches would then be backed out, altered, or whatever.
or just because the code looks poorly written.
The LTs would definitely catch this. If the style was *still* not up to snuff, I'd have to believe it would only be in minor ways that you could then touch up at your leisure.
I also spend a lot of testing before I check things in;
Done by the LTs.
running the standard test suite is a good safeguard against general breakage,
Ditto.
Ditto.
Based on my responses, I would venture to state that a group of LTs would manage to keep the Python core rock solid, except for: 1) subtle breakages that require your broader knowledge of Python 2) changes that "go against the plan" (and the LTs were ignorant of it) 3) minor format issues You would still review checkins, but the number of reviews would drop since the (obvious) crap has been eliminated. #1 is based on your *broad* knowledge of Python; I presume the LTs would be your match on various subsets of Python. By keeping the LTs well-informed, #2 could be nearly eliminated. #3 isn't that big of a deal, as I think your desired style is relatively well-known and the LTs would simply endeavor to match existing style. You could avoid a lot of testing; you would probably be inclined to do testing of items that you find dubious, but still this would be a reduction. ===== That may be an answer to the checkin problem. How about actual snapshots, alphas, betas, releases, and accompanying notes/news/readme files? I presume your LTs could run the alpha and beta aspects, but you would still issue final releases. Does your mail volume need to be reduced? (I think this has been asked before) Specifically, would patches@python.org (and similar targets) need to be established? (I would think so, as a matter of course, with the expectation that some patches would still end up with you and need to be bounced to patches@) Cheers, -g -- Greg Stein, http://www.lyra.org/

(I accidentally mailed this only to Greg; here's a repost of the relevant parts to the list:) [me]
[Greg Stein]
Reading your comments below, we may be able to help.
[...Proposal of lieutenants condensed...]
There's a lot of work in these (you may have noticed that the release notes got sloppier as 1.5.2 neared its completion). I would be happy to have the responsibility to decide to release without the burden of having to do all the work.
It's not the mail volume that bothers me -- I can ignore 100s of messages a day very quickly. It's the time it takes to respond to all of them. As an experiment, I've collected about 40 messages with suggested patches in them that I found in my inbox; the oldest are nearly two years old. You can access these from this address: http://www.python.org/~guido/patch/ I would love any help I could get in responding with these, and taking action in the form of patches. I propose that if you decide that a particular patch is worth checking in, you ask the author for the bugrelease or wetsign disclaimer and let me know that I can check it in; if changes to the patch are needed, I propose that you negotiate these with the author first. (I often ask them to test my version of a patch when I have style suggestions but don't have access the target platform or problem it solves.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Is this just for the sake of the experiment or this patch selection is the one you really haven't had the time to deal with? I see a couple of patches proposing GC implementations (a very delicate issue) of which only half a single patch would be acceptable for now (the one renaming malloc to PyMem_Malloc). There's one message (No 8) suggesting modifications to README and to the python.org Web page. How can we help with that? I have problems understanding two patches submitted by Gerrit Holl. They mention "Hallo Guido". :-)
Understood. Sharing your collection of suggested patches definitely increases your chances to get some help and answer the authors in time! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

These are ones that I really haven't had the time to deal with (witness the dates on some).
Maybe you can help me formulate a reply? I guess the patch collection isn't just about patches -- it's about the general level of effort that some patches require. I just don't feel comfortable with saying "no" without a good reason, and "no time" isn't a good enough reason. So I welcome any form of comments on these patch proposals.
There's one message (No 8) suggesting modifications to README and to the python.org Web page. How can we help with that?
The README is checked into the CVS. For the web page I will gladly accept patches to the HTML.
I have problems understanding two patches submitted by Gerrit Holl. They mention "Hallo Guido". :-)
Oops, sorry. The first one is proposing a validate() function for pathnames. In the second one, the patch code speaks for itself -- it makes an exception class conform to the rule that exceptions must inherit from Exception.
Thanks. Apart from Tim Peters who immediately tackled a typo in the FAQ, no-one else has offered any help with these. I'm glad that you've at least taken the time to look at them. I'm still being inundated with patches... But as long as this experiment hasn't shown more success I will keep them in my inbox. Or is there a better idea? Should I forward all patches I get to python-dev? To a separate list? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Understood.
Or is there a better idea? Should I forward all patches I get to python-dev?
Certainly not. This isn't the purpose of the list, except maybe if a patch is too fundamental to be just a patch. :-)
To a separate list?
This would be fine. A public list discussing all submitted patches would be helpful. There are some patches that require routine testing that few people here would find the time to perform. Others require "critical mass" of opinions to be adopted, rejected or deferred. Maybe we could set the gross operation mode of such a list as follows: You publish systematically all patches (except those that get checked in directly) The discussion focuses patches submitted during the past month. Some of them are accepted, some are rejected, many are "deferred" (for various reasons). Deferred patches are those that have an undecided future and get archived. In this case, a mail notification is sent to the author explaining the situation. If the author thinks the patch is worthy and "decidable", s/he has to resubmit the patch for reviving the discussion on the list and for trying to gain more proponents/favorable opinions. (because the list is discussing 1 month old patches only). If the author pushes real hard, either a decision would be taken, either s/he will end up convinced that the patch is "undecidable" for the time being :-). Besides, all serious patchers would become members of this list, which isn't so bad (given that presently, you're the only contact person for patch related material/submissions and you're mainly discussing a subset of the submissions, one-by-one, with the authors in person). This operation mode would ensure that the "light" patches, mostly the various bug fixes, will end up with a decision. The "hard" ones, those that introduce new functionality or behavior, will be seriously discussed and will eventually end up deferred (and archived) for future consideration. Thus, the archive would constitute yet another "memory" of the development process, accessible to all interested parties. This forum, like python-dev, would have a consultative mission, preserving your decision rights, so it's something you'd probably want to try (provided that you fix the rules of the game at its creation). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> The README is checked into the CVS. For the web page I Guido> will gladly accept patches to the HTML. I'm willing to put the entire python.org web site under CVS. This would at least make it easier for others to send us patches to the .ht files against the latest revisions. Is there any interest in this? It wouldn't take me long. Guido> Or is there a better idea? Should I forward all patches I Guido> get to python-dev? To a separate list? Probably a separate list. xemacs.org runs a xemacs-patches mailing list with a replybot on it that scans for patches. It sends back a different response based on whether it finds a patch or not. Then there's a group of lieutenants that keep an eye on the patches and work out their applicability. We could set something like that up fairly easily. -Barry

This sounds like a useful idea. It should also check for the disclaimer text and send an appropriate apply if a patch is found without a disclaimer. Of course, the replybot would need to be smart enough to find things like patches hiding in BASE64-encoded attachments... On the other hand, perhaps it would be better to deal with patches the same way as with bug reports -- the Jitterbug database isn't perfect, but it makes it possible to check regularly whether something has been dealt with or not, much better than a simple mailing list. (There are already lieutenants scanning the bugs traffic, so that part doesn't change.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> This sounds like a useful idea. It should also check for Guido> the disclaimer text and send an appropriate apply if a Guido> patch is found without a disclaimer. Guido> Of course, the replybot would need to be smart enough to Guido> find things like patches hiding in BASE64-encoded Guido> attachments... Guido> On the other hand, perhaps it would be better to deal with Guido> patches the same way as with bug reports -- the Jitterbug Guido> database isn't perfect, but it makes it possible to check Guido> regularly whether something has been dealt with or not, Guido> much better than a simple mailing list. (There are already Guido> lieutenants scanning the bugs traffic, so that part doesn't Guido> change.) Maybe then just use Jitterbug to collate patches. That's what a lot of my JPython users do. -Barry

On Wed, 2 Feb 2000 bwarsaw@CNRI.Reston.VA.US wrote:
Personally, I'm more comfortable knowing that I can email a patch (rather than dropping it into a bug db), and that will get handled by a human. The patch handlers could certainly use Jitterbug as arbitration, but I would think the list itself would make that reasonably clear. Note that "patches@python.org" could become THE place to submit patches. Sure, Guido would get some patches still, but some of the load will drop from his direct Inbox (yet he'd still get the patch as a subscriber). When the patch handlers had a "final" patch, it would get sent straight to Guido (with some "final" marker on it). etc etc. I'm sure there is a lot discussion that can take place on the exact mechanics. Until people will *volunteer*, I think the discussion of mechanics can be postponed. No need for a peanut gallery here :-) Cheers, -g -- Greg Stein, http://www.lyra.org/

On Wed, 2 Feb 2000, Greg Stein wrote:
Maybe then just use Jitterbug to collate patches. That's what a lot of my JPython users do.
<prefers e-mail to web-based>
Note that "patches@python.org" could become THE place to submit patches. <snip>
OK, I want to know one thing: is everyone comfortable with my suggestion of a seperate list, with a reply-to: python-dev? Barry said he'd be willing to hack it in, and everyone who talked seemed like this idea is similar to what they have in mind. The sooner a consensus is reached, the less patches Guido will have to deal with. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

On Thu, 3 Feb 2000, Moshe Zadka wrote:
I don't advocate the reply-to (see my other email).
It won't reduce his load unless we have actual volunteers that will truly do some handling of the patches. I'm assuming the current volunteer list is: - Guido (he volunteers whether he wants to or not :-) - Moshe (??) - Greg in April Others? Cheers, -g -- Greg Stein, http://www.lyra.org/

On Wed, 2 Feb 2000, Greg Stein wrote:
Part time -- I'll take responsibility for the patches that interest me. There will likely be a few, and I *love* installing patches off the net, just to test my security measures <0.3 wink>
Others?
I assume you'll get a similar response from many people: hopefully, for each patch it will either get booed automatically (hey! I just added braces instead of indentation to the parser) or will interest someone. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

The thing here that makes me slightly uncomfortable is how to keep track of patches that nobody picks up. a Jitterbug database would nicely do this, but I agree that it's inconvenient and overkill for other reasons. Perhaps we could use the "Linus Torvalds' inbox algorithm"? (When it overflows he deletes everything; "if it was important they'll send it again.") --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2 Feb 2000, Guido van Rossum wrote:
1. This discussion is in the (as you put it) niceties are. You are unlikely to get that many patches that it is an *immediate* problem. 2. mailman (what fun to me! I'm dumping work on Barry) could be hacked (or hooked) into doing that: it can keep a list of all patches which never got a reply in whatever list is being "replied to:" (that would neccessitate developers to CC the list, at least on the first post, but that's probably a good idea to do anyway) and send a mail message after a week to a patch-submitter who hasn't gotten a reply with a notice to the effect that nobody seems interested in it so he should make a bit more noise. 3. Like in the CP4E BOF we're getting all geeky again (which is fine, since we're all geeks). Just get something out of the door! Even a mailing list with no policy at all to who sends to it is infinitely better then Guido's mailbox, as much as we all respect that mailbox. We'll argue the fine points of exactly how to score automatically irrelevant patches (and I've got just the algorithm <0.9 wink>) later. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

"MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:
MZ> 2. mailman (what fun to me! I'm dumping work on Barry) could MZ> be hacked (or hooked) into doing that: Not a good strategy right now :) Here's my proposal, from short term/easy to long term: 1. Create patches@python.org which will be the official advertised address to send patches. This will be a Mailman mailing list to which anybody can post, but to which subscriptions are closed. Amount of work: trivial. 2. Create patches-discuss@python.org which will be the address to discuss patches@python.org postings. We make Reply-To: for patches@ be patches-discuss@ Amount of work: relatively small (for me to hack Mailman) 3. If someone will write a Python function to scan a string, returning true or false as to whether it contains a patch, I will integrate this into Mailman so that if a patch is found, it will be forwarded to the Jitterbug database address. Ideally this filter would check to be sure that the disclaimer text is included, but that's not necessary. Guido (or someone) is still going to have to decide whether the small text or a wet signature is necessary. Amount of work: Fairly non-trivial for someone other than Barry Not too bad for Barry to hack this into Mailman 4. When !?ng frees Roundup we look at adopting it. From everything that I heard about it, it's OHS (official hot shit). I want, I want! :) Amount of work: none now, except for !?ng :) Later, some for one of us CNRI'ers 5. Move the whole kit-and-kaboodle to SourceForge (or server51.freshmeat.net which looks to provide many of the same services). We cannot be the only project facing these same issues, so let's leverage off of what others have done. Amount of work: unknown, but I'm looking into it for Mailman -Barry

Why do we need two lists? For my own email processing I don't see how it will make a difference. A reply-bot could check whether there's a "Re:" in the subject or not to decide whether to send an acknowledgement. --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> Why do we need two lists? For my own email processing I GvR> don't see how it will make a difference. A reply-bot could GvR> check whether there's a "Re:" in the subject or not to decide GvR> whether to send an acknowledgement. Okay, fine with me.

Barry:
Given that VA Linux is buying Andover.net (parent of freshmeat.net), I doubt the two will remain as competing solutions. =) http://www.businesswire.com/cgi-bin/f_headline.cgi?day0/200340020&ticker=lnu x|andn --david

Let me just note the whole thing sounds great! I'm for it. On Thu, 3 Feb 2000, Barry A. Warsaw wrote:
... We cannot be the only project facing these same issues, so let's leverage off of what others have done.
As a point to think about, linux-kernel have a very non-high-tech solution that works, but for some reason causes everyone shivers: high volume mailing list, with patches and discussion of patches, and Linus's mailbox, in which patches from known hackers are more streamlined. That's the ultimate in flexibility ;-) I don't know how many people here ever subscribed to linux-kernel, but as someone who compiled a new kernel every week for a few months, I just want to say that it works <0.6 wink> -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.

On Wed, 2 Feb 2000, Guido van Rossum wrote:
We have a mailing list to archive the patches, so the "delete all" approach becomes a bit harder :-). Note that the approach requires feedback to be successful. The patch author must watch CVS to know if the patch went it. Otherwise, the patch handlers would be required to notify the author one way or another. With the notify route, then we'd have to state something like "you should resend if you haven't heard back within X weeks." But the notify/resend approach also creates an expectation that a patch *will* be handled within a *specific* timeframe. Dunno what I'd think the policy should look like right now. More thought needed on my part, so I'll just defer until a list is set up and discuss there... Cheers, -g -- Greg Stein, http://www.lyra.org/

From: "Guido van Rossum" <guido@CNRI.Reston.VA.US> To: <python-dev@python.org> Sent: Wednesday, February 02, 2000 4:50 PM Subject: Re: [Python-Dev] patch handling (was: Python 1.6 timing)
Sourceforge has a nice patch manager which allows a GUI'ish view of patches in context, discarding/deferring/etc. The code is available and open source. --david
participants (20)
-
Andrew M. Kuchling
-
Barry A. Warsaw
-
bwarsaw@cnri.reston.va.us
-
bwarsaw@CNRI.Reston.VA.US
-
bwarsaw@python.org
-
Christopher Petrilli
-
David Ascher
-
David Ascher
-
Fred L. Drake, Jr.
-
Greg Stein
-
Guido van Rossum
-
Guido van Rossum
-
Jeremy Hylton
-
Jim Fulton
-
Ka-Ping Yee
-
Ken Manheimer
-
Moshe Zadka
-
Skip Montanaro
-
Tim Peters
-
Vladimir Marangozov