Hacking on 5.10.1 was the plan…that happened for a couple of us.

Duke proposed a PDX.pm sprint to work on 5.10.1:
“I think if everyone learns how to

a) get a copy of the perl git repo
b) keep it in sync
c) run the perl test suite, including running a single test at a time
d) submit a small documentation patch

then we will have a great start.”

This is perfect for a first sprint: “small, solve-able tasks” that will get everyone up & running, plus have the potential to actually be productive.

Your first code sprint with a new group of people is like the first day on the job…except nobody realizes that we’re each FNGs*. It can take some time to figure out how to work together.

It’s really great if people get the stuff that’s going to take time from the code sprint out of the way beforehand. For example, cloning the perl5 git repo (step a):

:::=>git clone git://perl5.git.perl.org/perl.git

(Took me 13 minutes.)

Duke suggested some advance reading as well – how to use the repo (cd perl; perldoc pod/perlrepository.pod) (you will need to install perl-doc if you don’t have it; it was not installed on ubuntu.)

–

At the sprint: I don’t have the necessary experience with git yet, so most of my time was spent learning that, specifically in regards to task b) Keeping your repo in sync.

git branch
shows me that I am on the blead branch

git remote show
just an interface into .git/config

git pull
convenient combination of fetch (from remote) + merge (into local stuff)

git pull origin
…by default pulls your current branch.
git pull
…would have done the same thing (depending on your .git/config!)

The blead branch is NOT what perl 5.10.1 is going to be released from, so that’s not what we’re going to work with.

Side trip:
Duke has an excellent graphic that he & jhelwig created that illustrates git as applied to the perl development process**. (I think I convinced them to put it into an actual graphics program & make it available…) One of the tips I got from the diagram was that tags are immutable. They should not move. If they move, UR DOIN IT WRONG.

perldelta.pod – manually-maintained (!!!) filed that lists the changes in all versions of Perl.

OK back to work:
How to check out maint 5.10: (remember, blead is beyond 5.10 & has changes we don’t need to be concerned with.)

git checkout -b
…is a combination of checkout and branch

git branch -a
…shows me all the branches I have locally.

I want to create a *local* tracking branch for 5.10 maint.

git branch [whatever I want to call it] [branch I want (or anything that can uniquely id a commit!)]
eg:
git branch maint-5.10 origin/maint-5.10

Tip:
git config --global color.ui auto
- git branch -a – local branch is white, currently checked-out is green, remotes are red.

THEN I need to actually check out the local tracking branch (ie switch to it)
git checkout [name I gave it]
eg:
git checkout maint-5.10

git checkout -b maint-5.10 origin/maint-5.10 is a shortcut for the above two steps.

–
c) run the perl test suite, including running a single test at a time

For reference:
:::--> uname -a
Linux princess 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009 i686 GNU/Linux

First, you have to build (opts from Schwern, modified)
sh Configure -Ode \
-DDEBUGGING \
-Dprefix=/usr/local/perl/maint-5.10 \
-Dusedevel \
-Duseithreads \
-Dccflags='-I/usr/local/include -I/opt/local/include -I/sw/include' -Dldflags='-L/usr/local/lib -L/opt/local/lib -L/sw/lib' \
-Dlibpth='/usr/local/lib /opt/local/lib /sw/lib /usr/lib' \
-Uversiononly \
-Uinstallusrbinperl $@

- DEBUGGING builds the debugging symbols
- usedevel is required or configure will BITCHBITCHBITCH.
- useithreads enables one interpreter thread to do something I hope I don’t ever have to deal with. Or something.

Then:
TEST_JOBS=9; export TEST_JOBS #parallelizes your tests
make test
to compile perl and then run the tests. This takes a while. Grab a beer. In fact, grab a pitcher. Pay attention though, because a failing test here might be something interesting to patch.

make test TEST_FILES=[file] to run a single test.
e.g.:
make test TEST_FILES=t/pod/podselect.t
This turned out to be unreliable because it’s running through all the dependencies first. Bleah.

This is a better method:
cd t; ./perl TEST ./pod/podselect.t
Although Duke had problems with the debugger tests.

Remember TEST tries to cd to ./t, so you need to give your path relative to that.
(@Theory has more about this in his blog.)
(This is actually covered in perlhack, we just didn’t find it in time.)

–
Another tip:
get the name of your branch on your prompt. You need __git_ps1. Which is…somewhere halfway through the second pitcher.

Then add that var to your bash prompt whereever you’d like it:
$(__git_ps1 “(%s) “)
…the (%s ) is just my preferred formatting. The whole thing looks like this:
PS1=’\n\u@\h\w/\n$(__git_ps1 “(%s) “):::–> ‘

You can get some pretty colored output with this:
https://launchpad.net/~git-core/+archive/ppa

–
git shortlog:
shows you the commit messages, grouped by author. Useless if you’re looking for anything other than “a bunch of people did things.”

git shortlog -se:
number of commits, grouped by unique author + email.

git log --pretty=oneline maint-5.10..blead
…shows you the differences between two versions. In the perl source, there may be duplicates (different commit ID for same commit.)

–
Now let’s actually *do* something.
Stuff that’s holding up perl5.10.1 (I think)
Other stuff is in perltodo, but I’m not seeing anything that I’m actually up for given my skillset & current BAC.

I need to look for a doc to patch.

–
Annnnnd we decided to go to whiffies for pies.

More later! This is going to be a regular event.

–

* F’ing New Guy.
** Keep in mind that I am slightly more familiar with the Postgres release process & was expecting something similar.