[pypy-svn] rev 1617 - pypy/trunk/doc/funding

[hpk at codespeak.net]

Author: hpk
Date: Wed Oct  8 00:55:19 2003
New Revision: 1617

Modified:
   pypy/trunk/doc/funding/B4.5_resources.txt
Log:
removed spurious sprint information which is no in B5.* 

i wonder if this chapter about "resources" should be more
about how we will involve different parties and more
and more developers and so. 



Modified: pypy/trunk/doc/funding/B4.5_resources.txt
==============================================================================
--- pypy/trunk/doc/funding/B4.5_resources.txt	(original)
+++ pypy/trunk/doc/funding/B4.5_resources.txt	Wed Oct  8 00:55:19 2003
@@ -3,42 +3,7 @@
 Show how the project will mobilise the critical mass of resources
 (personnel, equipment, finance...) necessary for success.
 
-FIXME: <holger> i am only writing about sprints below (laura told me so) 
-but the above sentence seems to indicate that a lot of more stuff should go here. 
-Please feel free to enhance/modify!
-
-Coding Sprints are the key to PyPy's technical development 
-----------------------------------------------------------
-
-Key to PyPy's technical development and research are so called "sprints".  These publically 
-announced one-week meetings serve as an intense working forum to rapidly discuss 
-and implement key PyPy ideas with agile methodologies.  Developers usually pair 
-up and write unit-tests to test the to-be-implemented features before actually adding 
-them.  The unittest-first approach helps to understand the planned feature.  Additionally, 
-the discussion in a pair makes sure that obviously wrong pathes of development are
-avoided. If something seems too hard to test or to pin down explicitely this is 
-taken as an indication of an underlying design problem.  
-
-Note that more traditional approaches usually follow a model where developers work alone 
-and only meet to talk.  Instead with sprint-driven development talking and actually 
-implementing resulting ideas ensures a more focused approach with fast feedback cycles.  
-While the free software community is successful especially because of it's open 
-communication model sprints are an accelerator to this process.  While coding in pairs 
-developers educate each other which leads to a broader common understanding of the project.  
-During a sprint multiple pairs want to work in parallel which adds pressure on design 
-decisions so that independent development of components of the system is possible.  
-Thus sprints not only deepen the communication and understanding among researchers and 
-developers but they imply a working process which enhances the software design in multiple ways. 
-
-With a very-high-level-language like Python rapid development in coding-sprints becomes 
-especially effective.  A VHLL-language generally allows to focus on ideas rather than on low-level 
-language details.  In combintation with pervasive test-driven development this eases high-quality 
-rapid evolution towards the intendent goals.  Obviously, the PyPy developers are very experienced 
-with Python and bigger applications in general. Thus the full potential of coding-sprints is 
-unvealed during PyPy sprints. In less than five weeks worth of development (during four sprints) 
-the group produced a working prototype which is a big success not only in the eyes of its
-developers.  
-
-
-FIXME LAURA: <holger> should i add more about the involvement of the Python community here? 
-and something about the python-sprint-culture (Zope3, Plone, twisted) in general? 
+FIXME_LAURA: i (holger) moved the sprint information now completly
+to B5.* because i don't think it belongs here.  Can you restate what
+is needed here?  A description of the involvement of the Python community
+and the audience we are reaching and who will be contributing?