Skip to content

Latest commit

 

History

History
137 lines (88 loc) · 4.22 KB

patching_blead.pod

File metadata and controls

137 lines (88 loc) · 4.22 KB
Raw

Patching ExtUtils::CBuilder in bleadperl

Prerequisites

These instructions assume you have already cloned the perl git repository and have checked out the blead branch. The blead branch should be clean of extraneous files

$ cd ~/git
$ git clone git://perl5.git.perl.org/perl.git
$ git checkout blead
$ git clean -dxf

The rest of the instructions assume your perl git repo is ~/git/perl

Creating a perl branch with changes

Start in the ExtUtils-CBuilder directory. This would be the distdir left behind right after publishing a new release, or could be an unpacked tarball from CPAN.

$ cd ExtUtils-CBuilder-0.33_02

Run the add-packages.pl program from ~/git/perl/Porting to create a new git branch and copy in ExtUtils::CBuilder files.

$ perl ~/git/perl/Porting/add-package.pl -v -r ~/git/perl

Verifying and editing the branch

After add-packages.pl finishes, ~/git/perl will be on the new branch. Verify that and see what changes have been made:

$ git branch
$ git status

If there are other changes made but not staged, examine them individually and determine if they should be staged or if an error occurred.

If any files are being removed, be sure to edit Perl's MANIFEST file and stage it to be committed.

$ vim MANIFEST
$ git add MANIFEST

Next, modify the ExtUtils::CBuilder section of Porting/Maintainers.pl to indicate the distribution file on which the patch is based. Note the version that is being replaced -- you'll need this later when creating the commit message. Update any other metadata necessary, then add this file to the index.

$ vim Porting/Maintainers.pl
$ git add Porting/Maintainers.pl

Commiting the branch

Commit the branch and use the editor to create a commit message. The first line should be like this: "Update ExtUtils::CBuilder to 0.33_02". (Use the correct version, of course.) The rest of the file should contain an excerpt from the Changes file since the last version in blead (i.e. the old version number in Porting/Maintainers.pl)

$ git commit

### In editor ###
Update ExtUtils::CBuilder to 0.33_02

0.33_02 - Mon Jun 15 12:23:55 EDT 2009

Bug-fixes:
- Fixed tests for bleadperl

0.33_01 - Sat Jun 13 20:24:42 EDT 2009

[... rest of Changes ...]

Testing the branch

Build and test Perl to confirm the changes don't break anything. This takes a while, but saves embarassment posting a buggy patch to perl5-porters. For example:

$ ./Configure -des -Dusedevel
$ make && make test

Creating and sending the patch

Git can automatically create the patch email for perl5-porters:

$ git format-patch blead

This creates a single '0001...' email message file. If you have configured your perl git repository for sending email direct to perl5-porters, you can send it with this command:

$ git send-email 0001-Updating-ExtUtils-CBuilder-to-0.33_02.patch

Special tips

Configuring git to send email

In your ~/git/perl repository, set the destination email:

$ git config sendemail.to perl5-porters@perl.org

You may need to set some configuration for your particular email/ISP setup. For example, to set global git config to send email via a gmail account:

$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpssl 1
$ git config --global sendemail.smtpuser YOURUSERNAME@gmail.com

With this setup, you will be prompted for your gmail password when you run 'git send-email'.

Fixing a branch and regenerating a patch

DANGER -- ADVANCED GIT HERE

If something breaks in the test or after committing you realize you need to tweak the branch, you can go ahead and make changes and commit them to the branch as normal.

Then, before regenerating the patch, squash them into a single patch using interactive rebase:

$ git rebase -i origin

In the editor, you will have the option to choose how commits are rebased. Leave the first entry as 'pick' and make all subsequent entries 'squash'. After you leave the editor, a new editor window will open and you will have the opportunity to combine all commit messages. Generally, you'll want to keep the initial Changes list and just delete the other commit messages.

Afterwards, regenerate and send the patch as described above.