Nemcio/opkg-utils
1
0
Fork 0
mirror of https://git.yoctoproject.org/git/opkg-utils synced 2026-05-07 01:16:32 +02:00
Code Issues Packages Projects Releases Activity

CONTRIBUTING: update markdown styling

Browse Source 
Update the CONTRIBUTING document markdown styling to something more
modern and fixup a spelling mistake in the text.

No substantial content changes in this commit.

Signed-off-by: Alex Stewart <alex.stewart@ni.com>
This commit is contained in:
Alex Stewart
2023-08-18 17:04:34 -04:00
parent 3b6b9ff223
commit 0d6b7f44db
1 changed files with 62 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

142
CONTRIBUTING
View File

@@ -1,118 +1,100 @@
% Contributing to opkg-utils
# Contributing to opkg-utils
## Starting off
To contribute to opkg-utils, you'll need a basic understanding of how to use
git. You'll also need to make sure you can use `git send-email` - maybe try
sending a few patches to your own email address first to check you've got it set
up correctly.
To contribute to opkg-utils, you'll need a basic understanding of how to use git. You'll also need to make sure you can use `git send-email` - maybe try sending a few patches to your own email address first to check you've got it set up correctly.
If you don't have the latest opkg-utils sources, you'll need to clone the
official repository:
If you don't have the latest opkg-utils sources, you'll need to clone the official repository:
```bash
git clone git://git.yoctoproject.org/opkg-utils.git
```
git clone git://git.yoctoproject.org/opkg-utils.git
## Developing patches
Now make and commit your changes (that bit is left as an exercize for the
reader). Developing on a separate branch is a very good idea:
Now make and commit your changes (that bit is left as an exercise for the reader). Developing on a separate branch is a very good idea:
git checkout -b my-branch
git add ... # As appropriate
git commit -s # As appropriate
```bash
git checkout -b my-branch
git add ... # As appropriate
git commit -s # As appropriate
```
Adding a "Signed-off-by" line (using the -s option to `git commit`) is very
important and signifies acceptance of the Developer's Certificate of Origin (see
appendix). We also accept "Cc", "Acked-by" and "Tested-by" lines as appropriate,
as per the [submission guidelines for the Linux kernel][1]. We're not currently
interested in "Reviewed-by", "Reported-by" or "Suggested-by" lines.
Adding a "Signed-off-by" line (using the -s option to `git commit`) is very important and signifies acceptance of the Developer's Certificate of Origin (see appendix). We also accept "Cc", "Acked-by" and "Tested-by" lines as appropriate, as per the [submission guidelines for the Linux kernel][1]. We're not currently interested in "Reviewed-by", "Reported-by" or "Suggested-by" lines.
The subject (first line of the commit message) for each patch should begin with
the submodule, file or function that is modified, followed by a short (<50
characters if possible) description of the change. That helps
a lot to find anything related to a submodule or file by searching with a
simple 'git log | grep [foo]'.
The subject (first line of the commit message) for each patch should begin with the submodule, file or function that is modified, followed by a short (<50 characters if possible) description of the change. That helps a lot to find anything related to a submodule or file by searching with a simple 'git log | grep [foo]'.
The remainder of the commit message should explain in detail what was changed
and why.
The remainder of the commit message should explain in detail what was changed and why.
Each patch should make a single logical change. If multiple files are changed to
fix one bug or add one feature, that should be a single patch. If one file is
changed to fix multiple bugs, that should be multiple patches.
Each patch should make a single logical change. If multiple files are changed to fix one bug or add one feature, that should be a single patch. If one file is changed to fix multiple bugs, that should be multiple patches.
[1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
## Submitting patches for review
Opkg-utils is primarily used by the OpenEmbedded build system but may also be
used by other embedded Linux projects. For now, please submit all patches to
both the Yocto Project mailing list (yocto@lists.yoctoproject.org) and the opkg mailing
list (opkg-devel@googlegroups.com), adding a subject prefix of "opkg-utils PATCH"
(this prefix is necessary as the Yocto Project mailing list receives patches for
many projects). Also make sure that you use the -M option on the command line or
the "diff.renames=copy" option in your config.
Opkg-utils is primarily used by the OpenEmbedded build system but may also be used by other embedded Linux projects. For now, please submit all patches to both the Yocto Project mailing list (yocto@lists.yoctoproject.org) and the opkg mailing list (opkg-devel@googlegroups.com), adding a subject prefix of "opkg-utils PATCH" (this prefix is necessary as the Yocto Project mailing list receives patches for many projects). Also make sure that you use the -M option on the command line or the "diff.renames=copy" option in your config.
That sounds like a lot to remember but if you run the following commands in your
opkg-utils directory it will all be done automatically when you use
`git format-patch` or `git send-email`:
That sounds like a lot to remember but if you run the following commands in your opkg-utils directory it will all be done automatically when you use `git format-patch` or `git send-email`:
git config format.to "opkg-devel@googlegroups.com"
git config --add format.to "yocto@lists.yoctoproject.org"
git config format.subjectprefix "opkg-utils PATCH"
git config diff.renames copy
```bash
git config format.to "opkg-devel@googlegroups.com"
git config --add format.to "yocto@lists.yoctoproject.org"
git config format.subjectprefix "opkg-utils PATCH"
git config diff.renames copy
```
To prepare your patches, assuming you took the advice before about developing on
a separate branch:
To prepare your patches, assuming you took the advice before about developing on a separate branch:
git format-patch master
```bash
git format-patch master
```
You can add `--cover-letter` to that command if you want to include a
descriptive email along with your patches.
You can add `--cover-letter` to that command if you want to include a descriptive email along with your patches.
Once you've checked the generated patch files, run:
git send-email
```bash
git send-email
```
That should result in your patches being sent to the relevant mailing lists in
the correct format. The patches should then be reviewed and you should receive
feedback by email. If you haven't heard anything within 2 weeks, feel free to
send us a reminder.
That should result in your patches being sent to the relevant mailing lists in the correct format. The patches should then be reviewed and you should receive feedback by email. If you haven't heard anything within 2 weeks, feel free to send us a reminder.
If you need any further help or advice, just ask on the opkg-devel mailing list (opkg-devel@googlegroups.com).
If you need any further help or advice, just ask on the opkg-devel mailing list
(opkg-devel@googlegroups.com).
## Commit Access
If you have commit access to the opkg-utils git repository, it is assumed that
you know what you're doing. You can bypass the mailing list and push your
changes directly to the public repository, just make sure that you test things
properly and sign off your patches!
If you have commit access to the opkg-utils git repository, it is assumed that you know what you're doing. You can bypass the mailing list and push your changes directly to the public repository, just make sure that you test things properly and sign off your patches!
Appendix: Developer's Certificate of Origin
===========================================
Developer's Certificate of Origin 1.1
## Appendix: Developer's Certificate of Origin
```
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
```