[Py-howto-checkins] CVS: pyhowto python-2.0.tex,1.34,1.35

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/py-howto/pyhowto
In directory slayer.i.sourceforge.net:/tmp/cvs-serv4049

Modified Files:
	python-2.0.tex 
Log Message:
Rewrites to section on new development process, after Usenet discussion 
    of the text

Index: python-2.0.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v
retrieving revision 1.34
retrieving revision 1.35
diff -C2 -r1.34 -r1.35
*** python-2.0.tex	2000/09/27 02:49:24	1.34
--- python-2.0.tex	2000/10/04 12:40:44	1.35
***************
*** 59,94 ****

  The most important change in Python 2.0 may not be to the code at all,
! but to how Python is developed.  

- In May of 2000, the Python CVS tree was moved to SourceForge.
- Previously, there were roughly 7 or so people who had write access to
- the CVS tree, and all patches had to be inspected and checked in by
- one of the people on this short list.  Obviously, this wasn't very
- scalable.  By moving the CVS tree to SourceForge, it became possible
- to grant write access to more people; as of September 2000 there were
- 27 people able to check in changes, a fourfold increase.  This makes
- possible large-scale changes that wouldn't be attempted if they'd have
- to be filtered through the small group of core developers.  For
- example, one day Peter Schneider-Kamp took it into his head to drop
- K\&R C compatibility and convert the C source for Python to ANSI
- C. After getting approval on the python-dev mailing list, he launched
- into a flurry of checkins that lasted about a week, other developers
- joined in to help, and the job was done.  If there were only 5 people
- with write access, probably that task would have been viewed as
- ``nice, but not worth the time and effort needed'' and it would
- never have gotten done.
- 
- SourceForge also provides tools for tracking bug and patch
- submissions, and in combination with the public CVS tree, they've
- resulted in a remarkable increase in the speed of development.
- Patches now get submitted, commented on, revised by people other than
- the original submitter, and bounced back and forth between people
- until the patch is deemed worth checking in.  This didn't come without
- a cost: developers now have more e-mail to deal with, more mailing
- lists to follow, and special tools had to be written for the new
- environment.  For example, SourceForge sends default patch and bug
- notification e-mail messages that are completely unhelpful, so Ka-Ping
- Yee wrote an HTML screen-scraper that sends more useful messages.
- 
  The ease of adding code caused a few initial growing pains, such as
  code was checked in before it was ready or without getting clear
--- 59,99 ----

  The most important change in Python 2.0 may not be to the code at all,
! but to how Python is developed: in May 2000 the Python developers
! began using the tools made available by SourceForge for storing 
! source code, tracking bug reports, and managing the queue of patch
! submissions.  To report bugs or submit patches for Python 2.0, use the
! bug tracking and patch manager tools available from Python's project
! page, located at \url{http://sourceforge.net/projects/python/}.
! 
! The most important of the services now hosted at SourceForge is the
! Python CVS tree, the version-controlled repository containing the
! source code for Python.  Previously, there were roughly 7 or so people
! who had write access to the CVS tree, and all patches had to be
! inspected and checked in by one of the people on this short list.
! Obviously, this wasn't very scalable.  By moving the CVS tree to
! SourceForge, it became possible to grant write access to more people;
! as of September 2000 there were 27 people able to check in changes, a
! fourfold increase.  This makes possible large-scale changes that
! wouldn't be attempted if they'd have to be filtered through the small
! group of core developers.  For example, one day Peter Schneider-Kamp
! took it into his head to drop K\&R C compatibility and convert the C
! source for Python to ANSI C. After getting approval on the python-dev
! mailing list, he launched into a flurry of checkins that lasted about
! a week, other developers joined in to help, and the job was done.  If
! there were only 5 people with write access, probably that task would
! have been viewed as ``nice, but not worth the time and effort needed''
! and it would never have gotten done.
! 
! The shift to using SourceForge's services has resulted in a remarkable
! increase in the speed of development.  Patches now get submitted,
! commented on, revised by people other than the original submitter, and
! bounced back and forth between people until the patch is deemed worth
! checking in.  This didn't come without a cost: developers now have
! more e-mail to deal with, more mailing lists to follow, and special
! tools had to be written for the new environment.  For example,
! SourceForge sends default patch and bug notification e-mail messages
! that are completely unhelpful, so Ka-Ping Yee wrote an HTML
! screen-scraper that sends more useful messages.

  The ease of adding code caused a few initial growing pains, such as
  code was checked in before it was ready or without getting clear
***************
*** 137,144 ****
  PEP 225, ``Elementwise/Objectwise Operators''.

- To report bugs or submit patches for Python 2.0, use the bug tracking
- and patch manager tools available from the SourceForge project page,
- at \url{http://sourceforge.net/projects/python/}.
- 
  % ======================================================================
  \section{Unicode}
--- 142,145 ----
***************
*** 1158,1163 ****
  The authors would like to thank the following people for offering
  suggestions on drafts of this article: Mark Hammond, Gregg Hauser,
! Fredrik Lundh, Detlef Lannert, Skip Montanaro, Vladimir Marangozov,
! Guido van Rossum, and Neil Schemenauer.

  \end{document}
--- 1159,1164 ----
  The authors would like to thank the following people for offering
  suggestions on drafts of this article: Mark Hammond, Gregg Hauser,
! Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir
! Marangozov, Guido van Rossum, Neil Schemenauer, and Russ Schmidt.

  \end{document}