What is the fastest way to build and boot a kernel

[Alexander Kapshuk]

On Thu, Apr 20, 2017 at 7:20 PM, Code Soldier1 <codesoldier1 at gmail.com> wrote:
> On Thu, Apr 20, 2017 at 1:21 AM, Sébastien Masson
> <sebastien at masson.engineer> wrote:
>>
>> On 2017-04-19 20:26, Code Soldier1 wrote:
>>>
>>> On Wed, Apr 19, 2017 at 3:32 AM, Tobin C. Harding <me at tobin.cc> wrote:
>>>>
>>>> On Tue, Apr 18, 2017 at 08:59:36AM -0700, Code Soldier1 wrote:
>>>> [snip]
>>>>
>>>> Why the moniker?
>>>
>>>
>>> Why not ? unlike most people today I value my privacy.
>>
>>
>> Hi!
>>
>> In my opinion, the point is not really about privacy.  Although, I
>> understand you concern.
>>
>> As a kernel developer, the source code you will write will be subject to
>> copyright matters and, if you want to contribute, you will have to give your
>> agreement to this.
>> This is only possible using your real name.
>>
>> I am inviting you to read: Documentation/process/submitting-patches.rst in
>> this regard.
>>
>> Of course, as long as you do not submit source code, it does not really
>> matter.  It may be more a question of "consistency".
>>
>> BR,
>> Sebastien.
>
> I completely agree with you. If I decide to submit code and there is a
> requirement, I will have to make a choice. BTW how would anyone verify
> if I am really Joe Smith and I have not just created an email account
> ?
>
> I just looked at the kernel that I am working with and it does not
> have the file you pointed out to me. I read the first file and it does
> not say anything about username neither did anyone objected when I
> posted on netdev.
>
> ubuntu-server:~/linux/linux-stable-v4.9.9/Documentation$ find . -name
> \*patches\* -print
> ./hwmon/submitting-patches
> ./applying-patches.txt
> ./devicetree/bindings/submitting-patches.txt
>
>
>
>
> --
> CS1
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/plain/Documentation/SubmittingPatches?id=refs/tags/v4.9.23

11) Sign your work
------------------

To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch.  The rules are pretty simple: if you
can certify the below:

Developer's Certificate of Origin 1.1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

        (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.

        (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.

then you just add a line saying::

Signed-off-by: Random J Developer <random at developer.example.org>

using your real name (sorry, no pseudonyms or anonymous contributions.)