Subject: Re: Contribution to Linux Kernel.
To: Ken Moffat <zarniwhoop@ntlworld.com>, linux-kernel@vger.kernel.org
References: <59c7d4aa.d367370a.d4b44.16d6@mx.google.com>
 <20170924202505.GA29877@milliways.localdomain>
From: Javier Romero <linux.kernel.programming@gmail.com>
Message-ID: <6ad61767-7349-16ca-e5ec-1a7732d488d4@gmail.com>
Date: Mon, 25 Sep 2017 16:03:14 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20170924202505.GA29877@milliways.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2124
Lines: 63

Hi,

Last question, it will be the same to do Kernel testing on a virtual 
machine, or it will be better to do kernel testing over a no virtual 
machine?

Regards,


Javi


El 24/09/17 a las 17:25, Ken Moffat escribió:
> On Sun, Sep 24, 2017 at 12:52:08PM -0300, Javier Romero wrote:
>> Hi Ken,
>>
>> Thank you for your answer.
>>
>> Will it be better to work with linux-next Kernel for testing?
>>
>> Regards.
>>
> Yes, no, maybe.  I can't say what will work (process) for you, it
> depends in part on what you want to test, and how flakey that is at
> any particular time.
>
> The -next kernels are transient - what is there today might be
> removed tomorrow, what is in linus's -rc kernels (and in point
> releases of stable kernels) usually remains unless somebody finds a
> showstopper bug.
>
> If you are testing -next, expect to find more problems : in theory
> everything which gets to Linus's tree has been through an amount of
> testing before he applies it.
>
> Most people have limited time to test kernels.  Build farms usually
> run boot tests on all of these kernels, but do very little testing
> of whether or not any particular use is worse than before.
>
> For any of these, expect problems to arise when least convenient to
> you.  I try to test linus's -rc kernels on my own hardware,
> typically not until at least -rc2, and then once or twice after
> that.
>
> On occasion I test patchsets which look interesting, usually I end
> up wishing I had not bothered (they claim to help things, but do
> little or nothing for my machines).
>
> The other problem with testing, when you do find a real issue, is
> making sure it is repeatable so that you can bisect reliably.
>
> In short, test what interests you.  It's like writing or fixing
> code for the kernel as a hobby - work on what matters to you.
> Getting enough experience and visibility to become paid to code is a
> different thing entirely, I can't advise on that.
>
> So, for me it is just a hobby (with a side order of "hope this new
> release doesn't break anything for me").
>
> If you are not being paid for it, try to enjoy it.
>
> ĸen