Skip to content

Instantly share code, notes, and snippets.

@pmichaud
Created July 7, 2009 23:58
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pmichaud/142466 to your computer and use it in GitHub Desktop.
Save pmichaud/142466 to your computer and use it in GitHub Desktop.
Over the next couple of weeks I'm working on fleshing out
"job openings" and descriptions for people who want to help
advance Rakudo Perl 6. I'll write more about this in a later
post.
Following the Parrot model, one of the jobs we've already
identified is "Release Managers". These are people who have
responsibility for executing Rakudo releases according to the
release schedule. And like Parrot, we want this responsibility
to be widely spread among a team of managers, and not always fall
to the same person for every release. So, over the next month
or so I'll be recruiting people to be release managers, starting
with the August 2009 release. (The July 2009 release is likely
to have a few significant changes -- most notably a "make install"
target -- so I think it's better for me to do that one last
release myself.)
However, yesterday it occurred to me that thanks to github, it's
entirely possible <i>today</i> for people to independently and
immediately demonstrate that they're able to cut and publish
a Rakudo release. However, at present the instructions are
aimed only at people making releases from Unix environments;
I haven't tested or attempted to do so from other operating
systems. (I'll accept suggestions for doing so, though! :-)
For those who want to try it, here are the basic steps for
creating a Rakudo "practice release":
* Fork the rakudo github repository.
* Follow the steps in the docs/release-guide.pod file, substituting
your own github repo clone for the rakudo one.
* Let us know "Hey, I just made a Rakudo release!" and point to
your github repo. Or tell us where you ran into problems, so we
can improve the process.
* Profit.
Some notes about creating "practice releases":
* It's okay to skip steps 1-3 of the release guide for practice releases
* You can also safely skip any steps that involve communicating with others,
such as posting messages to the mailing lists or updating the wiki
* If you don't want to wait the 30+ minutes for a spectest run to
complete, "make test" is sufficient for a practice release.
* Yes, it's even possible for you to test uploading the tarball
to github -- just make sure to put it in your own repository
and not in rakudo's master. :-)
So, anyone want to give it a try? If you do, please let us know
how it works out, and places where you think things can improve.
I know that we'll be updating the release guide in response to
feedback from others, as well as adding things like testing of
"make install" and the like.
Thanks!
Pm
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment