On Thu, Mar 31, 2011 at 8:22 AM, James E Keenan <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
