Contributing Email Patches

From LibrePlanet
Jump to: navigation, search

Email patches were popular at one time, but most projects use a forge with a graphical pull request system. Hopefully, one day soon the FSF will use a graphical forge workflow.

Here is an example of the workflow that would work to send patches over email to contribute to our LibrePlanet Conference site to fix a validation error discovered with Vnu.

Scenario

You ran a local instance of Vnu against the LibrePlanet 2022 conference site and found a notice that reads:

   Info Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.
   From line 4. Column 5: to line 4. Column 28
       <meta charset="utf-8" />

You found the source for the LibrePlanet conference site and want to fix the validation message.

Command line git patch example

Clone the repository locally.

git clone https://vcs.fsf.org/git/libreplanet-static.git

Change to that directory.

cd libreplanet-static

Checkout the stable branch. (This is specific to this repository.)

git checkout stable

Recursively search for the file that contains the string you are looking for.

grep -R '<meta charset="utf-8" />' .

That string comes up 48 times in that repository.

The file that would make the most impact for the next LibrePlanet would be the most recent year or specifically the ./2022/includes/header.html file, but all 48 files could be fixed.

Edit the file you are working on with your favorite editor.

vim ./2022/includes/header.html

Find the line with meta charset. Remove the / from the end. Save and close the file.

Alternatively, you could use sed to change the file in-place without opening a text editor. This command could be adapted to change all 48 files.

sed -i 's|<meta charset="utf-8" />|<meta charset="utf-8">|g' ./2022/includes/header.html

Alternatively, you can take this a step further and edit all of the files at once. This command uses a bash for loop, grep, echo, and sed.

for i in $(grep -lR '<meta charset="utf-8" />' .); do echo "$i" && sed -i 's|<meta charset="utf-8" />|<meta charset="utf-8">|g' $i; done

Alternatively, you can take this a step further and remove all trailing slashes at once. This command uses a bash for loop, grep, echo, and sed.

for i in $(grep --exclude-dir=".git" --exclude='*.svg' --exclude='*.png' --exclude='*.map' --exclude='*.js' --exclude='Makefile' -lR ' />' .); do echo "$i" && sed -i 's| />|>|g' $i; done

Prepare the modified files for a new commit.

git add .

Create a new commit with a descriptive commit message. For this message, I put the type of patch in brackets followed by a paste of the first bit of the validation warning. It is generally a good practice to fix one type of thing with each patch.

git commit -m "[validation] Trailing slash on void elements has no effect"

Review the most recent commit. Press q to exit when you are done.

git diff HEAD~1

Create a patch file from the most recent commit in a different directory.

git format-patch -k --stdout HEAD~1 > ~/trailing-slash.patch

Send an email with the patch file attached to someone at the FSF. This can be done with the email provider, email client, or git send-email at your discretion. If the patch changes something that might be confusing, provide a detailed description of the patch such as what the patch is aiming to fix, what commands were used to make the changes, and how you arrived at the conclusion to write the patch.

In general, direct technical changes to sysadmin@fsf.org and content changes to campaigns@fsf.org.

On the other end, someone would download and review the patch. Reviews might go back and forth. If everything looks good, then the patch will be applied. The person on the other end with write access will run a variation of these commands:

git am -3 -k trailing-slash.patch

rm trailing-slash.patch

git push

Not all patches are accepted, but every patch is good practice for the next patch.