GSoC 2011 Parrot Debugger Proposal v2.0

[James E Keenan]

Jonathan "Duke" Leto wrote:
> Howdy,
>
> In the beginning, writing the examples first, before anything else exists, is
> instructional. Then you turn these into tests that *should* pass. Then you write
> the implementation that makes them pass. Then you add some docs about how that
> feature works. Then you rinse and repeat :)
>

I strongly concur with this approach.  Whenever I have a chance to 
develop a project from scratch, I try to practice what I call 
"documentation-driven development":  write a complete description of 
what functionality I want, including interfaces and examples, then write 
code and tests in close synchronization with one another.

> Also, I think you should send a separate email to parrot-dev asking
> for a consensus
> about whether your project should be developed in a branch of
> parrot.git or in a separate repo.
> If a separate repo, I think it would be beneficial to have it in the
> Parrot org on Github.
>

I think having the code in parrot.org on github will be good, because 
that will permit us to configure dalek to pick up commits and report 
them to #parrot.  I have a mild preference for having GSOC code in 
branches rather than a separate repo, because it makes it easier for me 
to do a quick checkout of the code and see what's up.  "branch vs. 
separate repo" might not make that much of a difference for the GSOCer, 
but branch might make life easier for mentors or backup mentors.

Thank you very much.
kid51