Evolinx/packagekit
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HACKING: Refresh to match current practices

Browse Source 
We've long since accepted contributions via GitHub pull requests,
so we should indicate as much. Additionally, provide lightweight
guidance about how to structure patches matching what we do today.

Finally, add a symlink to point CONTRIBUTING to HACKING.
This commit is contained in:
Neal Gompa 2023-05-14 10:29:41 -04:00 committed by Neal Gompa
parent 82f862b46c
commit 6c05146b73
2 changed files with 36 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
CONTRIBUTING Symbolic link
View File

@ -0,0 +1 @@
HACKING

38
HACKING
View File

@ -62,10 +62,16 @@ Remember:
Submitting Patches
------------------
Use 'git format-patch' to generate patches against a checked out copy
of the source.
We prefer patches submitted as pull requests to our GitHub project at
https://github.com/PackageKit/PackageKit
For Example:
However, if you are unable to use GitHub, you can also submit patches
via email.
To do so, Use 'git format-patch' to generate patches against a checked
out copy of the source.
For example:
$> cd PackageKit
HACK HACK HACK
@ -79,3 +85,29 @@ For Example:
Send these patches in an introductory email as attachments to
packagekit@lists.freedesktop.org
Commit/Patch Style
------------------
Commits (and thus patches) should be structured such that each one
is a logically distinct change that stands well and can be tested
on its own.
Commit/Patch messages should be wrapped at 72 characters, and the
subject line (minus the subsystem prefix) should be less than 50
characters.
What we mean by subsystem prefix is the portion of the codebase
that is being modified.
For example, if you are changing something in the main library,
use "lib:" as the prefix of the patch subject. If you are
changing something in one of the backends, use the backend name
as the prefix in the patch subject.
There are a number of examples of this already in the revision
history, so look at any number of them for good examples.
Finally, please do not use commit messages as a means for
advertising. The revision history is not a place for rent-free
permanent advertising. It can be especially problematic as
sponsoring entities change, rename, or such. That means that
tags like "Sponsored-by" or similar are not allowed.