tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

[Imported from Trac: page Patches, version 29]

markberger 2013-08-07 20:43:37 +00:00
parent 835582a3f5
commit 2f8de9d812
1 changed files with 14 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
Patches.md

@ -1,28 +1,27 @@
(see also [How To Review Patches](PatchReviewProcess))
Please create a new ticket to track the issue unless your patch is a patch for an issue that is already ticketed.
Please create a new ticket to track the issue unless your patch addresses an issue that is already ticketed. If you're not sure whether there is a ticket for your issue, just make a new one. Someone will point you in the right direction if your ticket is a duplicate.
Then run the following darcs commands to generate a darcs patch file named `WHAT.darcs.patch`:
We use git as our versoin control system and the tahoe source code is hosted on [Github](https://github.com/tahoe-lafs/tahoe-lafs). Github requires that you have a Github account in order to submit patches, so you will have to create one if you don't already have one. If you are unfamiliar with Github or git we recommend the following resources:
* [Github - Set up git](https://help.github.com/articles/set-up-git)
* [Github - Fork a repo](https://help.github.com/articles/fork-a-repo)
* [git-scm.com/book - A great overall git resource](http://git-scm.com/book)
```
darcs record
darcs send -o WHAT.darcs.patch http://tahoe-lafs.org/source/tahoe-lafs/trunk
```
Once you have finished installing git and creating your Github account, fork the offical Tahoe-LAFS repo [here](https://github.com/tahoe-lafs/tahoe-lafs). You can also star or watch the official repo to make us feel fuzzy inside.
(The name of the file, which is given here as `WHAT.darcs.patch`, is not that important. Use a relevant word or two or maybe the ticket number.)
Download the source code from your new fork. This can be done by typing `git clone <https://github.com/><YOUR USERNAME>/tahoe-lafs.git` into terminal.
Write a descriptive patch name and description like these ones (the "patch name" and "patch description" are labelled on these pages as "Message"): changeset:8ba536319689ec8e, changeset:1de4d2c594ee64c8, changeset:d0706d27ea2624b5, changeset:63b28d707b12202f, changeset:c18b934c6a8442f8, changeset:7cadb49b88c03209, changeset:be6139dad72cdf49.
If, and only if, a single file was modified in the patch it is conventional to begin the "patch name" field with "<FILENAME>:"
Navigate to the `tahoe-lafs` folder and type `git branch` to make sure `master` is selected. Then create a new branch with `git checkout -b <your branch name>`. Your branch name should have the ticket number and a small description of what the ticket is addressing. For example, the branch name for [ticket #1382 - immutable peer selection refactoring and enhancements](https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382) was `1382-immutable-peer-selection`.
Attach the patch to the ticket.
Now, hack at Tahoe-LAFS!
Please use a filename like `*.darcs.patch` so that Trac will display it with proper syntax highlighting.
Once you think you have solved the issue run the test suite with `python setup.py trial`. This ensures that you didn't accidentally break something while working on your patch.
Or without darcs you can attach a normal old unified diff. If you do that, please use a filename like `*.diff` so that Trac will display it with syntax highlighting. (If using darcs, you can generate a unified diff with `darcs whatsnew --unified`.)
Now that all of the existing unit tests pass, [write your own tests](https://tahoe-lafs.org/trac/tahoe-lafs/wiki/HowToWriteTests) for the ticket if they don't already exist.
Finally, push your branch to Github and [open a pull request](https://help.github.com/articles/creating-a-pull-request). Please add the tag `review-needed` to the ticket and add a link to the pull request. If you had trouble writing unit tests for your patch, don't worry. Submit the pull request anyway and add the tag `tests-needed` to the ticket.
Then add the keyword `review-needed` (spelled just like that) to the Keywords field of the ticket.
# Design reviews
To request a design review, explain your design (with or without a patch) and then add the [design-review-needed]query:keywords~=design-review-needed&status=!closed&group=milestone tag. Completion of a design review will normally not directly result in a patch being committed. The main goal of a design review is to give the person working on the ticket confidence that there are no show-stopping issues with the approach they are taking, and to get feedback on smaller issues that are useful to take into account before doing further work on a patch.
To request a design review, explain your design (with or without a patch) and then add the [design-review-needed]query:keywords~=design-review-needed&status=!closed&group=milestone tag. Completion of a design review will normally not directly result in a patch being committed. The main goal of a design review is to give the person working on the ticket confidence that there are no show-stopping issues with the approach they are taking, and to get feedback on smaller issues that are useful to take into account before doing further work on a patch.