[Grok-dev] Grok sprint for PyCon 2008: grokcore

[Brandon Craig Rhodes]

Thanks for the advice, everyone!  I've decided to indeed host a Grok
sprint here at PyCon 2008 that indeed attempts to break out a
"grokcore.*" set of packages from Grok that makes its component
registration features available individually.

Everyone, come to our orientation on Sunday afternoon even if you
can't stay!  We'd love to see you and get your ideas on our approach
even if you can't stay to type anything in with us.

We can go ahead and start a prelimimary thread on my approach.  Would
the following work, as a useful first step?

 (1) "svn cp" the "grok" package to something called "grokcore.component"

 (2) Remove all tests that don't directly concern component
     registration.  This should be a *great* activity for new
     sprinters, since it will let them read lots of well-constructed
     unit tests without requring them to write any code.  They're just
     helping us scan the directories of tests to see which belong in a
     first, minimal implementation of "grokcore.component".

 (3) Even that small set of tests will fail, since all the import
     statements in the code say "grok" and now need to say something
     that starts with "grokcore".  We'll therefore each take a .py
     file or two, jump in and repair the imports, and get the test
     suite running.  Again, a simple and useful task for beginners.

 (4) We'll now have a "working" "grokcore.component" that's
     essentially all of "grok" but renamed and with a smaller test
     suite.  As the final major step, I can send the volunteers
     through each .py file, each experimenting independently to find
     out what can be removed and disabled without breaking the basic
     ability to run the adapter test suite.  At the end of a day of
     work, I believe, we could have a very lean "grokcore.component"
     that just had the component-registration stuff left inside.

 (5) If we got this far, the last step would be to start a new branch
     of "grok" in which we remove the component-registration code that
     now duplicates what's in "grokcore.component", and teach mainline
     Grok to pull the same functionality from there.

My guess is that one or two major obstacles would come up during the
above steps that would pause us, but I'm still hopeful that it could
fit the days of the sprint and the availability of people.  From PvW's
comment earlier, I'm tempted to pull the Grok test stuff out of Grok
and into a "grokcore.test" module, since it would be pretty pointless
to have "grokcore.component" turn around and depend on Grok. :-)
(Maybe that's what PvW meant and I just didn't grok all that he
said...)

I hope to see several of you there!  I'll tout the Sprint at the end
of my talk, since it relates directly to my talk's conclusion - my
talk sets up the sprint topic as the logical next step for Grok's
evolutoin.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon