>>>>> "A" == aahz <aahz@pythoncraft.com> writes: A> On Tue, Apr 09, 2002, M.-A. Lemburg wrote: >> >> Regarding the subject line: don't know if it's just me, but I >> would like to see some of the conservative development style we >> had established a few years ago return in Python's development >> process. Some of the recent developments left me under the >> impression of the need to rush changes with no apparent reason >> (for rushing them). A> Or, to put it another way, perhaps before development work for A> each release starts (aside from bug fixes), we draw up a list of A> the feature goals for that release and project a target date for A> finishing those goals, but the goals get the focus rather than A> the date. Changing goals after development starts would require A> official BDFL prounouncement. That's pretty much what we do now, isn't it? We consider both a set of functional goals and a release schedule. We don't want to make these decisions in isolation. If there are N features in the release, and all but 1 can be finished in six months, we don't want to hold them all up for one feature that takes two years. So we say the next release will have N-1 features, and the other feature will go in a future release. A> If a great feature comes up after development starts, too bad -- A> the next development cycle will usually be less than nine months A> away. The only person sneaking in new features is Guido <0.2 wink>. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4