[RFC] Moving my GSoC project to an external repository

Tyler Curtis tyler.l.curtis at gmail.com
Thu Jul 8 16:43:09 UTC 2010


I brought this up at this week's #ps, but I wanted to make sure there
were no objections.

Bacek wants my GSoC branch either merged into trunk or moved to an
external project. He was probably concerned about having to wait for
my branch to merge trunk whenever any change occured in trunk that
PIRATE needs. I know Moritz has been bitten by this when he's been
working on testing optimizations for Rakudo using my branch, as well.

At #ps, particle raised concerns about merging a GSoC branch into a
supported release halfway through GSoC. Allison and Whiteknight both
seemed to prefer moving it to its own repository, as do I. Whiteknight
suggested it be include in ext/ for 2.6. I don't have an opinion on
that. If that is done, however, it should definitely be marked
experimental. The API is still not totally stable, and its
capabilities are still changing as I learn better what is useful in
such a project.

I'm going to begin working on extracting my project to an external
repository(probably on github), using distutils.pbc for a build
system, today. If all goes well and no one objects, I plan to do the
rest of my development of it in the git repo instead of in the
gsoc_past_optimization branch of Parrot's subversion repository. Once
this is done, it will be able to be installed without any Parrot. I'll
also speak to japhb about getting its metadata into Plumage to make it
even more convenient to install.

-- 
Tyler Curtis


More information about the parrot-dev mailing list