[Python-checkins] CVS: python/nondist/peps pep-0200.txt,1.4,1.5

[Fred L. Drake]

Update of /cvsroot/python/python/nondist/peps
In directory slayer.i.sourceforge.net:/tmp/cvs-serv27923

Modified Files:
	pep-0200.txt 
Log Message:

Do not start non-heading content on the first character of the line (after
the header).


Index: pep-0200.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0200.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -r1.4 -r1.5
*** pep-0200.txt	2000/07/25 14:11:19	1.4
--- pep-0200.txt	2000/07/26 04:12:42	1.5
***************
*** 18,30 ****
  Tentative Release Schedule
  
! Aug. 14: All 2.0 PEPs finished / feature freeze
! Aug. 28: 2.0 beta 1
! Sep. 29: 2.0 final
  
  Guidelines for submitting patches and making changes
  
! Use good sense when committing changes.  You should know what we mean
! by good sense or we wouldn't have given you commit privileges <0.5
! wink>.  Some specific examples of good sense include:
  
      - Do whatever the dictator tells you.
--- 18,30 ----
  Tentative Release Schedule
  
!     Aug. 14: All 2.0 PEPs finished / feature freeze
!     Aug. 28: 2.0 beta 1
!     Sep. 29: 2.0 final
  
  Guidelines for submitting patches and making changes
  
!     Use good sense when committing changes.  You should know what we
!     mean by good sense or we wouldn't have given you commit privileges
!     <0.5 wink>.  Some specific examples of good sense include:
  
      - Do whatever the dictator tells you.
***************
*** 44,76 ****
        to someone for review.
  
! Any significant new feature must be described in a PEP and approved
! before it is checked in.
  
! Any significant code addition, such as a new module or large patch,
! must include test cases for the regression test and documentation.  A
! patch should not be checked in until the tests and documentation are
! ready.
! 
! If you fix a bug, you should write a test case that would have caught
! the bug.
! 
! If you commit a patch from the SF Patch Manager or fix a bug from the
! Jitterbug database, be sure to reference the patch/bug number in the
! CVS log message.  Also be sure to change the status in the patch
! manager or bug database (if you have access to the bug database).
! 
! It is not acceptable for any checked in code to cause the regression
! test to fail.  If a checkin causes a failure, it must be fixed within
! 24 hours or it will be backed out.
! 
! All contributed C code must be ANSI C.  If possible check it with two
! different compilers, e.g. gcc and MSVC.
! 
! All contributed Python code must follow Guido's Python style guide.
! http://www.python.org/doc/essays/styleguide.html
! 
! It is understood that any code contributed will be released under an
! Open Source license.  Do not contribute code if it can't be released
! this way.
  
  Accepted and completed
--- 44,77 ----
        to someone for review.
  
!     Any significant new feature must be described in a PEP and
!     approved before it is checked in.
  
!     Any significant code addition, such as a new module or large
!     patch, must include test cases for the regression test and
!     documentation.  A patch should not be checked in until the tests
!     and documentation are ready.
! 
!     If you fix a bug, you should write a test case that would have
!     caught the bug.
! 
!     If you commit a patch from the SF Patch Manager or fix a bug from
!     the Jitterbug database, be sure to reference the patch/bug number
!     in the CVS log message.  Also be sure to change the status in the
!     patch manager or bug database (if you have access to the bug
!     database).
! 
!     It is not acceptable for any checked in code to cause the
!     regression test to fail.  If a checkin causes a failure, it must
!     be fixed within 24 hours or it will be backed out.
! 
!     All contributed C code must be ANSI C.  If possible check it with
!     two different compilers, e.g. gcc and MSVC.
! 
!     All contributed Python code must follow Guido's Python style
!     guide.  http://www.python.org/doc/essays/styleguide.html
! 
!     It is understood that any code contributed will be released under
!     an Open Source license.  Do not contribute code if it can't be
!     released this way.
  
  Accepted and completed
***************
*** 116,120 ****
        Small optimization achieved by using the code object's lnotab
        instead of the SET_LINENO instruction.  Uses code rewriting
!       technique (that Guido's growns on) to support debugger, which
        uses SET_LINENO.
  
--- 117,121 ----
        Small optimization achieved by using the code object's lnotab
        instead of the SET_LINENO instruction.  Uses code rewriting
!       technique (that Guido's frowns on) to support debugger, which
        uses SET_LINENO.