[pypy-svn] rev 1617 - pypy/trunk/doc/funding
hpk at codespeak.net
hpk at codespeak.net
Wed Oct 8 00:55:20 CEST 2003
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?
More information about the Pypy-commit
mailing list