[PATCH] README: cosmetic fixes

[PATCH] README: cosmetic fixes

[Diego Viola]

Signed-off-by: Diego Viola <diego.viola@gmail.com>
---
 README | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README b/README
index f4756ee..afc4f0d 100644
--- a/README
+++ b/README
@@ -59,7 +59,7 @@ DOCUMENTATION:
 INSTALLING the kernel source:
 
  - If you install the full sources, put the kernel tarball in a
-   directory where you have permissions (eg. your home directory) and
+   directory where you have permissions (e.g. your home directory) and
    unpack it:
 
      xz -cd linux-4.X.tar.xz | tar xvf -
@@ -125,7 +125,7 @@ BUILD directory for the kernel:
 
    When compiling the kernel, all output files will per default be
    stored together with the kernel source code.
-   Using the option "make O=output/dir" allow you to specify an alternate
+   Using the option "make O=output/dir" allows you to specify an alternate
    place for the output files (including .config).
    Example:
 
@@ -159,9 +159,9 @@ CONFIGURING the kernel:
 
      "make nconfig"     Enhanced text based color menus.
 
-     "make xconfig"     X windows (Qt) based configuration tool.
+     "make xconfig"     Qt based configuration tool.
 
-     "make gconfig"     X windows (GTK+) based configuration tool.
+     "make gconfig"     GTK+ based configuration tool.
 
      "make oldconfig"   Default all questions based on the contents of
                         your existing ./.config file and asking about
@@ -268,8 +268,8 @@ COMPILING the kernel:
    Normally, the kernel build system runs in a fairly quiet mode (but not
    totally silent).  However, sometimes you or other kernel developers need
    to see compile, link, or other commands exactly as they are executed.
-   For this, use "verbose" build mode.  This is done by inserting
-   "V=1" in the "make" command.  E.g.:
+   For this, use "verbose" build mode.  This is done by passing
+   "V=1" to the "make" command, e.g.
 
      make V=1 all
 
@@ -300,7 +300,7 @@ COMPILING the kernel:
    kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
    /boot/bzImage.  To use the new kernel, save a copy of the old image
    and copy the new image over the old one.  Then, you MUST RERUN LILO
-   to update the loading map!! If you don't, you won't be able to boot
+   to update the loading map! If you don't, you won't be able to boot
    the new kernel image.
 
    Reinstalling LILO is usually a matter of running /sbin/lilo. 
-- 
2.6.3

Re: [PATCH] README: cosmetic fixes

[Jonathan Corbet]

I've applied this to the docs tree.  I'd sure rather see an effort to
update this file instead of tweaking it, though.  For example:

> @@ -300,7 +300,7 @@ COMPILING the kernel:
>     kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
>     /boot/bzImage.  To use the new kernel, save a copy of the old image
>     and copy the new image over the old one.  Then, you MUST RERUN LILO
> -   to update the loading map!! If you don't, you won't be able to boot
> +   to update the loading map! If you don't, you won't be able to boot
>     the new kernel image.
>  
>     Reinstalling LILO is usually a matter of running /sbin/lilo. 

I somehow suspect that very few of us actually MUST RERUN LILO in 2015...

Thanks,

jon

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

Hi Jonathan,

Thanks for applying my patch. I actually have to admit that before
sending my patch I actually thought about the same thing regarding
LILO being in the README.

I asked on IRC and a few places about this because I don't feel like
removing anything before asking the community first. LILO still seems
to be alive as a project but not many people use it anymore, as you
have mentioned.

I agree the README feels outdated in many ways, I would be happy to do
some clean up, but I also want some input from the community on what
should stay and what should go. Should I send a new email to discuss
this?

Also, see this:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/install.sh

This script calls /sbin/lilo if it's available during the make
install, so I don't think we can just remove LILO from the README if
it's still being used for the make install?

If we end up removing LILO from the README, should we remove it from
the Makefile as well?

This Makefile hasn't been updated in a few years I think.

Thanks,

Diego

On Thu, Dec 10, 2015 at 4:34 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> I've applied this to the docs tree.  I'd sure rather see an effort to
> update this file instead of tweaking it, though.  For example:
>
>> @@ -300,7 +300,7 @@ COMPILING the kernel:
>>     kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
>>     /boot/bzImage.  To use the new kernel, save a copy of the old image
>>     and copy the new image over the old one.  Then, you MUST RERUN LILO
>> -   to update the loading map!! If you don't, you won't be able to boot
>> +   to update the loading map! If you don't, you won't be able to boot
>>     the new kernel image.
>>
>>     Reinstalling LILO is usually a matter of running /sbin/lilo.
>
> I somehow suspect that very few of us actually MUST RERUN LILO in 2015...
>
> Thanks,
>
> jon

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Thu, Dec 10, 2015 at 4:34 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> I've applied this to the docs tree.  I'd sure rather see an effort to
> update this file instead of tweaking it, though.  For example:
>
>> @@ -300,7 +300,7 @@ COMPILING the kernel:
>>     kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
>>     /boot/bzImage.  To use the new kernel, save a copy of the old image
>>     and copy the new image over the old one.  Then, you MUST RERUN LILO
>> -   to update the loading map!! If you don't, you won't be able to boot
>> +   to update the loading map! If you don't, you won't be able to boot
>>     the new kernel image.
>>
>>     Reinstalling LILO is usually a matter of running /sbin/lilo.
>
> I somehow suspect that very few of us actually MUST RERUN LILO in 2015...
>
> Thanks,
>
> jon

Is there a reason this patch didn't make it for 4.5?

Diego

Re: [PATCH] README: cosmetic fixes

[Jiri Kosina]

On Sun, 17 Jan 2016, Diego Viola wrote:

> Is there a reason this patch didn't make it for 4.5?

Diego, this is a second time I am CCed on some super-super-trivial patch 
from you, and you keep to be very persistent regarding the urge of pushing 
everything upstream ASAP.

Please understand that there are much more important things that need to 
end up in a particular kernel release, and purely cosmetic fixes (such as 
this one) simply have to wait for the particular maintainer to clean up 
low priority items (such as this one) from his queue.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Mon, Jan 18, 2016 at 7:44 AM, Jiri Kosina <jikos@kernel.org> wrote:
> On Sun, 17 Jan 2016, Diego Viola wrote:
>
>> Is there a reason this patch didn't make it for 4.5?
>
> Diego, this is a second time I am CCed on some super-super-trivial patch
> from you, and you keep to be very persistent regarding the urge of pushing
> everything upstream ASAP.
>
> Please understand that there are much more important things that need to
> end up in a particular kernel release, and purely cosmetic fixes (such as
> this one) simply have to wait for the particular maintainer to clean up
> low priority items (such as this one) from his queue.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>

OK sorry about that, I thought they forgot to add my patch in the pull request.

Diego

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Mon, Jan 18, 2016 at 7:44 AM, Jiri Kosina <jikos@kernel.org> wrote:
> On Sun, 17 Jan 2016, Diego Viola wrote:
>
>> Is there a reason this patch didn't make it for 4.5?
>
> Diego, this is a second time I am CCed on some super-super-trivial patch
> from you, and you keep to be very persistent regarding the urge of pushing
> everything upstream ASAP.
>
> Please understand that there are much more important things that need to
> end up in a particular kernel release, and purely cosmetic fixes (such as
> this one) simply have to wait for the particular maintainer to clean up
> low priority items (such as this one) from his queue.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>

The thing I'm unsure about is that the pull request contained trivial
changes from others as well, and my patch was trivial, yes.

So why not include my changes with the other trivial changes as well?

Diego

Re: [PATCH] README: cosmetic fixes

[Jonathan Corbet]

On Mon, 18 Jan 2016 17:53:02 -0200
Diego Viola <diego.viola@gmail.com> wrote:

> The thing I'm unsure about is that the pull request contained trivial
> changes from others as well, and my patch was trivial, yes.
> 
> So why not include my changes with the other trivial changes as well?

I set aside when I raised my initial complaint, and it stayed set aside.

I'll consider it again, but I'm not very enthusiastic about applying
stylistic fixes.  We really don't need trivial patch wars over how many
exclamation points belong on a given sentence.

Diego, I'd like to ask you to sit back a bit and think about what you are
really trying to accomplish.  Maintainers are busy people, and you place a
demand on their time whenever you post a patch.  That time is available in
*very* limited quantities for patches that don't really make the kernel
better.  Please think a bit about why you're doing this, and how you might
direct your energy toward creating changes that maintainers actively want
to apply.  That will leave everybody better off than nagging people about
cosmetic changes.

Thanks,

jon

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Mon, Jan 18, 2016 at 8:40 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 18 Jan 2016 17:53:02 -0200
> Diego Viola <diego.viola@gmail.com> wrote:
>
>> The thing I'm unsure about is that the pull request contained trivial
>> changes from others as well, and my patch was trivial, yes.
>>
>> So why not include my changes with the other trivial changes as well?
>
> I set aside when I raised my initial complaint, and it stayed set aside.

After your complaint, I provided and suggested examples about
improving the section in the README that you complained about, I also
asked for your feedback, but you remained silent.

I was hoping to get your feedback and we would improve that section together.

>
> I'll consider it again, but I'm not very enthusiastic about applying
> stylistic fixes.  We really don't need trivial patch wars over how many
> exclamation points belong on a given sentence.

I understand, but the exclamation point is just one fix, there are
other fixes in my patch.

>
> Diego, I'd like to ask you to sit back a bit and think about what you are
> really trying to accomplish.  Maintainers are busy people, and you place a
> demand on their time whenever you post a patch.  That time is available in
> *very* limited quantities for patches that don't really make the kernel
> better.  Please think a bit about why you're doing this, and how you might
> direct your energy toward creating changes that maintainers actively want
> to apply.  That will leave everybody better off than nagging people about
> cosmetic changes.

I'm just trying to improve the documentation, I want to improve the
state of the documentation and the README, why is this so hard to do?

I understand you don't have the time to review small patches like
mine, so wouldn't it make sense to delegate this work or activity to
someone else that has the time?

>
> Thanks,
>
> jon

Thanks,

Diego

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Mon, Jan 18, 2016 at 11:32 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Mon, Jan 18, 2016 at 8:40 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>> On Mon, 18 Jan 2016 17:53:02 -0200
>> Diego Viola <diego.viola@gmail.com> wrote:
>>
>>> The thing I'm unsure about is that the pull request contained trivial
>>> changes from others as well, and my patch was trivial, yes.
>>>
>>> So why not include my changes with the other trivial changes as well?
>>
>> I set aside when I raised my initial complaint, and it stayed set aside.
>
> After your complaint, I provided and suggested examples about
> improving the section in the README that you complained about, I also
> asked for your feedback, but you remained silent.
>
> I was hoping to get your feedback and we would improve that section together.
>
>>
>> I'll consider it again, but I'm not very enthusiastic about applying
>> stylistic fixes.  We really don't need trivial patch wars over how many
>> exclamation points belong on a given sentence.
>
> I understand, but the exclamation point is just one fix, there are
> other fixes in my patch.
>
>>
>> Diego, I'd like to ask you to sit back a bit and think about what you are
>> really trying to accomplish.  Maintainers are busy people, and you place a
>> demand on their time whenever you post a patch.  That time is available in
>> *very* limited quantities for patches that don't really make the kernel
>> better.  Please think a bit about why you're doing this, and how you might
>> direct your energy toward creating changes that maintainers actively want
>> to apply.  That will leave everybody better off than nagging people about
>> cosmetic changes.
>
> I'm just trying to improve the documentation, I want to improve the
> state of the documentation and the README, why is this so hard to do?
>
> I understand you don't have the time to review small patches like
> mine, so wouldn't it make sense to delegate this work or activity to
> someone else that has the time?
>
>>
>> Thanks,
>>
>> jon
>
> Thanks,
>
> Diego

Would you consider my patch if I send another patch that addresses the
complaint you brought it up?

No rush, apologies for that.

Diego

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Tue, Jan 19, 2016 at 12:40 AM, Diego Viola <diego.viola@gmail.com> wrote:
> On Mon, Jan 18, 2016 at 11:32 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Mon, Jan 18, 2016 at 8:40 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>>> On Mon, 18 Jan 2016 17:53:02 -0200
>>> Diego Viola <diego.viola@gmail.com> wrote:
>>>
>>>> The thing I'm unsure about is that the pull request contained trivial
>>>> changes from others as well, and my patch was trivial, yes.
>>>>
>>>> So why not include my changes with the other trivial changes as well?
>>>
>>> I set aside when I raised my initial complaint, and it stayed set aside.
>>
>> After your complaint, I provided and suggested examples about
>> improving the section in the README that you complained about, I also
>> asked for your feedback, but you remained silent.
>>
>> I was hoping to get your feedback and we would improve that section together.
>>
>>>
>>> I'll consider it again, but I'm not very enthusiastic about applying
>>> stylistic fixes.  We really don't need trivial patch wars over how many
>>> exclamation points belong on a given sentence.
>>
>> I understand, but the exclamation point is just one fix, there are
>> other fixes in my patch.
>>
>>>
>>> Diego, I'd like to ask you to sit back a bit and think about what you are
>>> really trying to accomplish.  Maintainers are busy people, and you place a
>>> demand on their time whenever you post a patch.  That time is available in
>>> *very* limited quantities for patches that don't really make the kernel
>>> better.  Please think a bit about why you're doing this, and how you might
>>> direct your energy toward creating changes that maintainers actively want
>>> to apply.  That will leave everybody better off than nagging people about
>>> cosmetic changes.
>>
>> I'm just trying to improve the documentation, I want to improve the
>> state of the documentation and the README, why is this so hard to do?
>>
>> I understand you don't have the time to review small patches like
>> mine, so wouldn't it make sense to delegate this work or activity to
>> someone else that has the time?
>>
>>>
>>> Thanks,
>>>
>>> jon
>>
>> Thanks,
>>
>> Diego
>
> Would you consider my patch if I send another patch that addresses the
> complaint you brought it up?
>
> No rush, apologies for that.
>
> Diego

I've just sent a new email that I hope will address the complaints you
mentioned earlier.

Diego

Re: [PATCH] README: cosmetic fixes

[Jonathan Corbet]

On Sat,  5 Dec 2015 17:50:10 -0200
Diego Viola <diego.viola@gmail.com> wrote:

> Signed-off-by: Diego Viola <diego.viola@gmail.com>

OK, I've applied this (the original version) to the docs tree, sorry for
the delay.  In the future, though, when a maintainer asks you to relax,
please don't respond by sending five more messages :)

jon

Re: [PATCH] README: cosmetic fixes

[Diego Viola]

On Mon, Jan 25, 2016 at 5:40 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Sat,  5 Dec 2015 17:50:10 -0200
> Diego Viola <diego.viola@gmail.com> wrote:
>
>> Signed-off-by: Diego Viola <diego.viola@gmail.com>
>
> OK, I've applied this (the original version) to the docs tree, sorry for
> the delay.  In the future, though, when a maintainer asks you to relax,
> please don't respond by sending five more messages :)
>
> jon

Thanks.