GSoC 2011 Parrot Debugger Proposal v2.0

[Andrew Whitworth]

On Thu, Mar 31, 2011 at 8:22 AM, James E Keenan <jkeen at verizon.net> wrote:
> 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.

As a good third option, we have the ability to develop the code in a
fork, and at the end of the summer (or at various intermediate
checkpoints as needed) we can merge the changes in to parrot/master.
Doing the work in a dedicated branch in the master repository is fine
and good too, and has the benefit that other Parrot contributors can
easily make changes/fixes to the branch as needed (a fork would have a
different set of permissions). I am absolutely against any code being
developed directly in master, and I think everybody else is too.

We can raise a question whether or not the debugger belongs in the
Parrot repository at all, or whether it should be kept separate and
external. An argument for keeping it in an external repository, under
the parrot organization, is to help enforce encapsulation barriers at
the code level. If it was kept as a separate project we would be
forced to have a Parrot which worked properly without a debugger
available. This, in turn, forces Parrot to provide a suitable API
which could be used to implement other, alternative debuggers and
other tools.

Keeping the debugger in the Parrot repo does add a convenience factor,
which is not to be overlooked for a tool as common or as generally
useful as a debugger. We do run into our share of difficulties, it's
harder for Parrot to expose a clean and reusable API for the
development of other debuggers when there is a clear "winner" already
available in the repo. This is precisely one of the big problems we
are having with IMCC right now. Also, if the debugger has any external
dependencies (Parrot-Instrument is mentioned frequently) we would need
to also move those dependencies into the parrot repo as well.

My personal preference is that a new repository be created for this
debugger work, and that it not be bundled in the Parrot repo. In that
case, we don't need to worry about whether the project is developed in
master, in a branch, or even in a fork because it is a separate and
private repo. If this project gets accepted (and it hasn't even been
officially submitted to the google-melanage website for consideration
yet) we will need to find a place for it to live.

--Andrew Whitworth