This article is reproduced from the Linux kernel's official website , the official website to load because the very card, for easy reading purposely forwarded to the blog.
Time-sensitive content, students need to read the latest version, you can jump through the following links:
https://www.kernel.org/doc/html/latest/translations/zh_CN/process/index.html
Translator:
中文版维护者： 钟宇 TripleX Chung <[email protected]>
中文版翻译者： 钟宇 TripleX Chung <[email protected]>
时奎亮 Alex Shi <[email protected]>
中文版校译者： 李阳 Li Yang <[email protected]>
王聪 Wang Cong <[email protected]>For those who want to submit the changes to the Linux kernel individuals or companies, if not familiar with the "rules", the process will be submitted daunting. This document is a collection of a series of recommendations, which can greatly improve your chances of being accepted changes.
The following document contains a lot of simple suggestions, specific see: Documentation / Process (Bloggers note: See reprint "kernel development process Guide" ), likewise, Documentation / Translations' / zh_CN / Process / the Submit-checklist.rst (Bloggers note: see reprint "Linux kernel patch submission of the list" ) gives a list before submitting the code to check the project. If you submit a driver, then while reading it: Documentation / Process / Submitting-drivers.rst (Bloggers note: See reprint "How to submit drivers to the Linux kernel" )
Many steps describe the default behavior Git version control system; if you use Git to prepare a patch, you will find that most of the mechanical work it for you, although you still need to prepare and record a reasonable set of patches. In general, use git kernel will make your life as a developer easier.
Get the current source tree
If you do not use a current kernel source code repository, use git get one. You will start from the main repository, it can be obtained in the following ways:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gitHowever, please note that you may not want to directly address the main line of tree development. Most subsystem maintenance personnel to run their own tree, and hope to see patches for these trees to prepare. See MAINTAINERS file subsystem T: items to find the tree, or simply ask whether the defenders of the tree which is not listed.
Tarballs can still download the kernel version (as in the next section), but this is a difficult way to kernel development.
“diff -up”
Use "diff -up" or "diff -uprN" to create patches.
All changes to the kernel, are presented in the form of a patch, patch generated by the diff (1). When creating patches, make sure it is the creation of "unified diff" format, which is generated by the diff (1) of the '-u' parameter. Further, using the '-p' parameter will be displayed as a C function for each change is located, so that the generated patch is much easier to read. Patch should be based on the root directory of the kernel source tree, rather than any subdirectories inside.
A separate file is created for the patch, in general, doing so is enough:
SRCTREE=linux
MYFILE=drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE # make your change
cd ..
diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patchCreate patches for multiple files, you can not unlock a modified kernel source tree, and then between your own tree do diff. E.g:
MYSRC=/devel/linux
tar xvfz linux-3.19.tar.gz
mv linux-3.19 linux-3.19-vanilla
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
linux-3.19-vanilla $MYSRC > /tmp/patch"Dontdiff" is a list of files generated by the kernel at compile time, the list of files will be skipped in the diff (1) patches generated inside.
Make sure your content patch does not contain any additional files were not on this patch submission. I remember after the patch is generated by diff (1), review a patch, to ensure accuracy.
If your changes are scattered, you should look at how to divide the patch into separate sections, will change into a series of logical steps. This makes it easy for other kernel developers review, if you want your patch is accepted, it is very important. See: Split your changes
If you use git, git rebase -i can help you this. If you do not git, quilt http://savannah.nongnu.org/projects/quilt another popular choice.
(Bloggers note: By git format-patchlooks like a faster method, see chapter standard patch format )
Describe your changes
Describe your problem. Whether your line of bug fixes or patches are 5000 rows of new features, there must be a potential problem motivate you to get the job done. Let reviewers believe that there is a problem worth solving, let them read the first paragraph makes sense.
Describe the effect visible to the user. Direct crashes and lock are quite convincing, but not all errors are so blatant. Even we discovered the problem during code reviews, but also to describe what you think it might impact on user-generated. Keep in mind that most of the Linux kernel from the installation and operation of two stable tree to tree or a particular vendor / product, just upstream from the selection of a particular patch, so please include any changes can help you locate content downstream: scene triggered, dMESG excerpt, crash description, performance regression, delayed spikes, locking and so on.
Quantify and optimize the trade-off. If you claim an improvement in performance, memory consumption, stack space or binary terms of size, include support for their numbers. But also the cost of obvious description. Optimization is usually not free, but the trade-off between CPU, memory and readability; or explore the nature of the work, a trade-off between different workloads. Please describe the expected shortcomings optimized, so that reviewers can weigh the costs and benefits.
Once the problem is established, it must describe in detail what you are actually doing. For the reviewer, the code changes in plain English description is very important to verify whether the code of conduct in line with your wishes.
If you write a patch described in a form, this form can easily be used as "commit log" into the source code management system git Linux's, the maintenance staff will thank you very much. See clear reply message header (In-Reply-To)
Each patch only to solve a problem. If your description starts to grow, suggesting that you might need to split your patch. See Split your changes
When you submit or re-submit the patch or patches series, include the full description and justification of the patch. Do not just say it's patch (series) of the edition. Do not expect subsystem maintainers cited earlier version of the patch or patches described referring URL to find and put it into the patch. That is, the patch (series) and their description should be independent. This is good for maintenance personnel and auditors. Some reviewers may not even receive an early version of the patch.
Describe your in command changes in tone, such as "make xyzzy do frotz" rather than "[patch] make xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you were in command code base change the same behavior.
If the patch fixes a bug entry record, press the bug number and URL reference entry. If the patch from the mailing list discussion, given the mailing list archive URL; https://lkml.kernel.org/ use redirection with Message-ID to ensure that the link will not become obsolete.
However, in the absence of external resources, try to make your explanation understandable. In addition to providing bug mailing list archive or the URL, we should also summarize the relevant points of discussion needs to submit a patch.
A specific reference if you want to submit, do not just quote SHA-1 ID submitted. Please also include a one-line summary submitted to the reviewers to understand what it is about. E.g:
Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary
platform_set_drvdata(), but left the variable "dev" unused,
delete it.You should also make sure to use at least the first 12 SHA-1 ID. Kernel repository contains many objects, so the potential for conflict with the short ID great. Remember, even if the conflict does not occur now with your six-character ID, this situation may change after five years.
If the patch fixes specific submission errors, for example, use git bisct, please use the "Fixes:" with the first 12 characters of the SHA-1 ID tag and a one-line summary. In order to simplify Do not mark into multiple rows, marking analysis script from "75 Wrap" rule restrictions. E.g:
Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")The following git config settings can be added to make git log, git show beautiful display format:
[core]
abbrev = 12
[pretty]
fixes = Fixes: %h (\"%s\")Split your changes
Each logical partition will change into a single patch.
For example, if you have changes in the same time bug fixes and performance optimization, then to split into two or more of these changes patch file. If your changes include modifications to the API, and modify the driver to adapt to these new API, then put these changes into two patches.
On the other hand, if you make multiple changes to a single patch file, then merge them into a single patch file. Such a single logical change is contained only in a patch file.
If you have a dependent on another patch to patch complete its changes, that is no problem. Simply say, "This patch rely on a patch" like in your patch described in.
When your changes into a series of patches, pay special attention to ensure that the building can be normal after each patch kernel series and run. Use git bisect to track problems developers may split your patch series at any time; if you introduce errors in the middle, they will not thank you.
If you can not patch concentrated into fewer files, each about sending out 15, and then wait for review and integration.
Check your change style
Check your patch whether there is a fundamental conflict style, detailed information is available in Documentation / Translations' / zh_CN / Process / Coding-style.rst (Bloggers note: See reprint "Linux kernel coding style" ) found in. Failure to do so will only waste time reviewers, and will cause your patch is rejected, might not even be read.
An important exception is when the code from one file to another - in this case, you should not modify the code to move in the same patch mobile code. This clearly describes the behavior of mobile code and your change. This greatly contributes to actual differences in the review, and allows the tool to better track the history of the code itself.
Before submitting, use the patch style checker checks patch (scripts / check patch.pl). However, please note that the style checker should be seen as a guide and not as a substitute for human judgment. If your code looks better, but there are violations, it is best not to use it.
Examiner reports at three levels:
- ERROR: things are likely to go wrong
- Things to scrutiny: WARNING
- CHECK: need to think about things
You should be able to determine all the irregularities that exist in your patch.
Select Patch Recipients
You should always copy on any patch corresponding subsystem maintainers to get the code of their maintenance; maintenance personnel file and view the source code revision history to see who these maintenance personnel Yes. Script scripts / get_Maintainer.pl very useful in this step. If you can not find subsystem maintainers are working, then Andrew Morton ([email protected]) will serve as the final maintenance personnel.
You generally should also select at least one mailing list to receive the patch set. [email protected] as a list of the final solution, but the volume on this list has caused many developers refused. Find a list of specific subsystems in MAINTAINERS file; your patch might get more attention there. However, please do not send spam to the list irrelevant.
Many associated with the kernel list hosted on vger.kernel.org; you can find a list of them on http://vger.kernel.org/vger-lists.html. However, there are associated with the kernel list hosted elsewhere.
Do not send more than 15 patches once to vger mailing list! ! ! !
Linus Torvalds is to determine whether the changes into the final arbiter of the Linux kernel. His e-mail address is [email protected] . He received a lot of e-mail, so generally, better not send e-mail to him.
If you have a patch to fix security vulnerabilities available, please send the patch to [email protected]. For serious bug, you can consider short-term pause to allow distributors to release patches to users; in this case, it is clear patches should not be sent to any public list.
Repair has released the kernel patches critical errors should point to a stable version of the maintenance personnel, is to put a line like this:
Cc: [email protected]Sign into the patch of quasi-area (note, not the e-mail recipient). In addition to this file, you should also read the Documentation / Process / stable-Kernel-rules.rst (Bloggers note: See reprint "All you want to know - about linux stable release" )
However, please note that some of the subsystem maintainers who want to draw their own conclusions, that is what patches should be placed in a stable tree. In particular, network maintenance personnel, do not want to see the individual developers to add such a line like the one above in the patch.
If the change affects the user and kernel interfaces, maintenance personnel to man pages (such as maintenance personnel file listed) man page send patches, or change notification is sent at least to some of the information into the man page. It should also be copied to the user space API changes [email protected].
For small patches, you might trivial patch CC to collect mailing list (Trivial Patch Monkey) [email protected], where special collection of trivial patch. The following patch will be treated as such "trivial" patch:
- Document spelling correction.
- Correction will affect the grep (1) spelling.
- Warnings amended (frequent printing unnecessary warning is not good.)
- Compile Error Correction (code logic is indeed a right, but a problem with the compiler.)
- Correction run (as long as the amendment is really wrong.)
- Removed using the function code to be discarded / macro (e.g. check_region.)
- Information and documentation correction.
- Replacement code nonportable with portable code (even in architecture specific code, since it was copied, as long as it is trivial)
- Author of any document / maintainer (for example, under the patch monkey in the retransmission mode) the changes to the file
(Annotation, on the "trivial patches" Some explanation: because this part of the original written relatively simple, so had to write about violations Annotation "trivial" the English word intended to be "trivial, unimportant." However, there are some slight changes, such as a number of significant amendments NULL pointer, belonging to amend run, will be categorized into trivial patch in. while correction NULL pointer is very important, but such amendments tend to be small and very easy to get test, it is also classified as trivial patch. trivial patch more precise classification should be "simple, localized & easy to verify", that is simple, easy and local inspection. [email protected] mailing list this patch is for the purpose of providing a center for the submitters to lower the threshold for submission.)
No MIME encoding, no links, no compression, no attachments, only plain text
Linus and other kernel developers need to read and comment on changes to your submission. For kernel developers, can "quote" your changes are important, use a general e-mail tool, they can add comments anywhere in your code.
For this reason, all patches are submitted by e-mail in the "embedded" in.
** If you use the Cut - paste your patch, carefully wrap feature your editor damage your patch **
Do not use the patch as a MIME-encoded attachment, regardless of whether or not compressed. Many popular e-mail software is not at any time be MIME-encoded attachments sent as plain text, which would make others can not comment in your code. In addition, MIME-encoded attachment Linus will spend a little more time to process, which reduces the likelihood of your changes to be accepted.
Exception: If your postman broke patch, then someone may ask you to use mime to re-send patches
See Documentation / Translations' / zh_CN / Process / Email-clients.rst (Bloggers note: See reprint "Linux mail client configuration information" ) to get on configuring your email client so that it is unaffected send patches prompt.
size of the e-mail
Big changes to the mailing list is inappropriate for some defenders also inappropriate. If your patch, without compression, more than 300kB, then you'd better put a patch on the server can access the internet, and then use the URL to your patch instead. However, please note that if you patch more than 300kb, then it will almost certainly need to be destroyed.
Reply to review comments
Your patch will almost certainly get the reviewers comment on the patch improved method. You must respond to these comments; let patch overlooked a good way is to ignore the opinions of reviewers. Does not result in changes to the code comments or questions will almost certainly bring about changes in comments or change log, so that the next review to better understand what is happening.
Be sure to tell the reviewer to change what you're doing, and thank them for their time. Code review is a tiring and time-consuming process, reviewers sometimes become violent. Even in this case, but also politely respond and solve problems they pointed out.
Do not be discouraged or impatient
After submitting the changes, please be patient. Reviewers are busy people who may not have access to your patches immediately.
Once upon a time, the patch had disappeared without comment in the blank, but the development process more smoothly than it is now. You should receive a review within a week or so; if not received comments, please make sure you have a patch sent to the correct position. Before resubmitting or contact reviewers to wait at least a week - possibly longer during peak hours, such as merge window and the like.
Messages containing PATCH
Linus linux kernel and due to high email traffic, often combined with [PATCH] prefix in front of the subject line. This makes Linus and other kernel developers to more easily separate patches and other e-mail forum.
Signing your work - the developer of the original certification
In order to strengthen the track who did what is going on, especially plus a "sign-off" on the patch process for those sent out through several layers of defenders patch, we recommend.
"Sign-off" is the last line of text in the notes simple patch of certification you write it or others have the power to pass it as a patch of open source. The rules are simple: If you can authenticate the following information:
Developer certificate of origin 1.1
Contribution to this project, I certified the following information:
- These contributions are entirely or partially created by me, I have the right to file pointed out that open source licenses submitted to it; or
- These contributions are based on previous work, as far as I know, these previous working properly protected by the open-source license, and, under license, I have the right to modify the contribution of submitting either completely or in part created by me, these contributions are using the same open source license (unless I was allowed to use other licenses), as indicated in the file; or
- These contributions by the certification (1), (2) or (3) the person directly to me, and I did not change it.
- I understand and agree with this project and contributions are public contribution records (including personal records submitted with me, including sign-off) and can be permanently maintained and this project or open source license re-issued simultaneously.
Then add the following line:
Signed-off-by: Random J Developer <[email protected]>Use your real name (sorry, can not use pseudonyms or anonymous.)
Someone finally labeled. Now these things are ignored, but you can do so by tagging process within the company, or just to point out some specific details on the sign-off.
If you are a sub-branch or maintenance personnel, and sometimes need to slightly modify the patch received, in order to merge them, because trees and submitters code are not identical. If you strictly follow the rules (c), you should be required to submit to re-release, but a complete waste of time and effort. Rule (b) allows you to adjust the code, but the code changes submitted by a person and let him recognize your mistake is very impolite. To resolve this problem, we recommend adding a line between the signature line and your last line, indicating the nature of the change. Although this is not mandatory, but it seems plus your mail and / or name previously described (all enclosed in square brackets), which is enough to notice that you are responsible for the changes last minute. E.g:
Signed-off-by: Random J Developer <[email protected]>
[[email protected]: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <[email protected]>If you maintain a stable branch, at the same time want to thank authors, track changes, merge repair and protect against a complaint filed by, then this approach is particularly useful. Please note, we can not change the author's ID (From head) in any case, because it is an identity in the change log appears.
Special instructions Round (back-porters): Insert a patch in (after the subject line) at the top of the commit message indicating origin seems to be a common and useful practice in order to facilitate tracking. For example, here is what we see in the stable version 3.x:
Date: Tue Oct 7 07:26:38 2014 -0400
libata: Un-break ATA blacklist
commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.Also, here is an older version of the kernel of a round patch:
Date: Tue May 13 22:12:27 2008 +0200
wireless, airo: waitbusy() won't delay
[backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]When to use Acked-by:, CC :, and Co-Developed by:
Singed-off-by: mark indicates the signer involved in the development of the patch, or his / her transfer path in patches.
If a person is not directly involved in the preparation or processing of the patch, but wished to express and record their approval of the patch, then they can request to add a Acked-by in the change log of the patch:
Acked-by: typically used by the affected code defenders, the defenders when neither contribute nor forwarding patch.
Acked-by: people do not sign formal. This is a record, confirmed that at least people reviewed the patch, and acceptance. Therefore, sometimes merging patches manually Acker of "Yep, looks good to me" convert Acked-By :( Note, however, is usually best to ask for a clear Ack).
Acked-by: acknowledgment does not necessarily mean the entire patch. For example, if a plurality of subsystems influence patch, and there is a: a subsystem from a maintainer, this usually indicates that only affect some confirmation code maintainer. There should be careful to judge. If in doubt, refer to the original discussion mailing list archive.
If someone has the opportunity to comment on the patch, but did not provide such a comment, you can choose to add Cc in the patch: This is the only tag that can be added without being explicitly named person operation, but it should indicate that the person is in the Cc patch. Discussions included potential stakeholders.
Co-developed-by: patch declaration by a number of developers co-founded; when several people working on a patch, which is used to impart properties co-author (except From: addition of conferred). Because Co-developed-by: representation of identity, so each person to develop: must immediately follow the relevant co-author of the signature. Standard procedures require sign-off: Mark signoff order should reflect the time history of the patch as much as possible, regardless of whether the author is through the From: or by the Co-developed-by: common development. It is noteworthy that the last signatory: must always be a developer to submit a patch.
Note that when the author of the email header "From:" line when people listed, "From:" tags are optional.
Patch authors to submit examples:
<changelog>
Co-developed-by: First Co-Author <[email protected]>
Signed-off-by: First Co-Author <[email protected]>
Co-developed-by: Second Co-Author <[email protected]>
Signed-off-by: Second Co-Author <[email protected]>
Signed-off-by: From Author <[email protected]>Patch co-developer submitted examples:
From: From Author <[email protected]>
<changelog>
Co-developed-by: Random Co-Author <[email protected]>
Signed-off-by: Random Co-Author <[email protected]>
Signed-off-by: From Author <[email protected]>
Co-developed-by: Submitting Co-Author <[email protected]>
Signed-off-by: Submitting Co-Author <[email protected]>Use Speaker: Test person: Reviewed by: recommended people: repair people:
Reported-by: to those who find errors and report an error of people to thank, once again it hopes to motivate them to help us in the future. Note that if the bug report is a private way, then before using Reported-by marks, please request permission.
Tested-by: mark indicates the patch has been designated person (in certain circumstances) successfully tested. The label notify maintenance personnel have performed some tests, provides a method for locating testers for future patches, and to ensure the credibility of the testers.
Reviewed-by: In contrast, according to the judge's statement that the patch has been reviewed and considered acceptable:
Judge's supervision statement
By providing my Reviewed-by, I declare:
- I have this patch conducted a technical review to assess whether it is suitable to be included in the mainline kernel.
- Any problems associated with the patch, concerns or issues are fed back to the submitter. I am satisfied with the response to my comments on the submitter.
- Although this submission may improve some things, but I believe that, at this time, (1) the kernel valuable changes, (2) contains no known issues involved in the debate.
- Although I have reviewed the patch and that it is sound, but I will not (unless explicitly stated otherwise) make no warranty or guarantee that it will achieve its stated under any given circumstances purpose or function properly.
Reviewed-by is a view statement that the patch is appropriate to modify the kernel, without any serious technical problems left over. Any interested reviewer (to complete the work of people) that can provide a patch a Review-by label. This label is used to provide thanks to the reviewers, and notifies the extent of the review has been completed defenders in the patch. Reviewed-by: When provided by a known understanding of the subject area and perform a thorough examination of the reviewers, generally increases the likelihood of a patch into the kernel.
Suggested-by: patch represents the idea was put forward by the specified persons, and to ensure that this idea thanks to the designated person. Please note that, without permission, shall add to this label, released especially if the idea is not in a public forum. This means that if we are diligent to thank our creative people, they get encouraged by promising in the future, help us again.
Fixes: indicates the patch fixes a problem in the previous submission. It can easily determine the source of the error, which helps to check the bug fixes. The mark also help stabilize the core team determines should receive stable kernel version fixes. This is the preferred method of patching error indication. See the description of the changes you describe your changes for more details.
Standard patch format
This section describes how to format the patch itself. Please note that if you patch stored in a Git repository, you can use git format-patch patch correctly formatted. However, these tools can not create the necessary text, so be sure to read the instructions below.
Standard patches, header line is:
Subject: [PATCH 001/123] 子系统:一句话概述There is a message body portion of a standard patch:
- A "from" line indicates patches of. Followed by a blank line (to send patches were not required only if the author only).
- Text interpretation, and lines 75 packaging, which will be copied to the permanent change log to describe this patch.
- A blank line
- The above described "Signed-off-by" line, will also appear in the change log.
- --- contains only tag line.
- Any other comments that do not fit the change log.
- The actual patch (diff output).
- Format header row, such that the header row sorted alphabetically is very easy - many e-mail clients can support - since the sequence number is zero-filled, so by alphabetical and numerical order is the same.
e-mail the title of "subsystem" logo which will be patched kernel subsystem.
"Overview phrase" e-mail header briefly described an e-mail patch. "In short overview" should not be a file name. For a patch series ( "patch series" refers to a series of multiple related patches), we do not have the same "word Overview" use of each patch.
Remember that e-mail is "word Overview" will become the globally unique identifier for the patch. It will spread to git changes to record. Then "Overview word" will be used in the discussion of the developer's, used to refer to the patch. Users will want to find articles that discuss this patch google search for "word Overview" by. When people view the use of tools such as gitk thousands patch or git log --oneline like in two or three months, we will soon see it.
For these reasons, the outline must not exceed 70-75 characters, and must describe the patch changes and why you need the patch. Both descriptive simplicity but also very challenging, but well-written overview should do it.
Prefix may be outlined in brackets: "Subject: [PATCH
Some headline examples:
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCHv2 001/207] x86: fix eflags tracking"From" line in the message body is the top row, has the following format:
From: Patch Author <[email protected]>"From" line indicates a permanent change in the log, who was identified as the author. If there is no "From" line, then the message in advance of the "From:" line will be used to determine the change of the log.
Topic Description will be submitted to the permanent changes to the source code log, so for those of you who already do not remember the details of the discussion related to the patch and capable, it makes sense. Including patches positioning errors (kernel log messages, OOPS messages, etc.) symptoms, especially useful for people who commit log search to find suitable patches. If a patch fixes a compilation fails, you may not need to include all fail to compile; just enough to let people search the patch can be found it the line. And an overview of the same, both have to be concise descriptive.
"-" patch tag line for processing tools to find where is the end of the change log information is indispensable.
For "-" extra notes after the marker is used to write a good use diffstat, used to display and modify what files and delete each file increases the number of rows. diffstat especially useful for large patches. Those notes and the rest of the time, or only developer-related, inappropriate changes to log into the permanent should also be put here. Use diffstat option "-p 1 -w 70" so that the file name will start from the directory of the kernel source tree, will not take up too wide space (it is easy to fit the width of the 80's, maybe there will be some indentation.)
In the latter reference can be seen in more detail the appropriate patch format.
Clear reply message header (In-Reply-To)
Add Comment patch of manual titled Head (In-Reply_To :) is helpful (for example, using git send-email) patch will be associated with the previous discussion, for example, links to e-mail bug fixes and bug reports . However, for multi-patch series, it is best to avoid using the link to the old version of the series in reply. In this way, multiple versions of the patch will not be the reference sequence e-mail client can not be managed. If the link is useful, you can use https://lkml.kernel.org/ redirector (for example, in the cover e-mail text) link to an earlier version of the patch series.
Git pull transmission request
If you have a series of patches, then the maintenance personnel operating through git pull them directly pulled into the storage subsystem library may be the most convenient. However, please note that, to obtain a patch for a patch from the mailing list than requiring a higher degree of trust from your developers. Therefore, many people are unwilling to accept the maintenance subsystem requests, especially requests from new and unknown developers. If you have questions, you can use the pull request a series of options as a normal patch release in the cover e-mail, so that maintenance personnel can choose to use one of them.
The subject line pull request should have [Git Pull]. Request itself should contain the name and branch repository interest in a row; it should look like:
Please pull from
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
to get these changes:a pull request message should also contain a whole, the request will include what is described, a patch itself Git shortlog diffstat overall effect and a series of display patches. The easiest way, of course, will gather together all of this information is to use git git request-pull command for you to complete these tasks.
Some maintenance personnel (including Linus) would like to see a signed request from the submission; this increases their confidence in your request. In particular, in the absence of the signature label situation, Linus will not pull request from the public like Github hosting site.
The first step in creating such a signature is to generate a key GNRPG by one or more core kernel developers to be signed. This step can be difficult for new developers, but there is no way around it. The meeting is to find a good way developers can sign your key.
Once you have prepared a patch that you want someone to pull the series in Git, you create a signature tag with git tag -s. This will create a new tag, the last commit identity in the series, and include a signature with your private key to create. You can also be added to the tag changelog style message; this is the ideal location for a description of the overall effect of the pull request.
If you maintain a repository will be extracted from the tree is not that you are using, do not forget to have a signature mark significant push to the public tree.
When generating pull requests, please use a signed tag as a target. This command can be achieved:
git request-pull master git://my.public.tree/linux.git my-signed-tag