Created
July 7, 2009 23:58
-
-
Save pmichaud/142466 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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