I've been sitting on some trivial patches for a while, and I'd just
like to get them out of the way.
Here is the series:
[1] Docs: Kconfig: For readability, offset modifiers with commas
[2] Docs: Kconfig: Use consistent whitespace indentation
[3] Docs: Kconfig: Clean up the radiotap documentation
[4] Docs: Kconfig: `devlopers' -> `developers'
[5] DRM: comment: `halve' -> `half'
[6] DRM: comment: `gdm_proc_lists' -> `drm_info_lists'
[7] DRM: cleanup: Remove unused `gamma_size'
drivers/gpu/drm/drm_fb_helper.c | 3 --
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_proc.c | 2 +-
drivers/net/wireless/ipw2x00/Kconfig | 102 +++++++++++++++++------------------
fs/btrfs/Kconfig | 3 +-
init/Kconfig | 4 +-
6 files changed, 58 insertions(+), 60 deletions(-)
Each patch is provided in an email, but you may pull from the
following:
https://github.com/mfwitten/linux.git trivial/misc/3
which is the result of applying these patches to commit
b36f4be3de1b123d8601de062e7dbfc904f305fb (Linux 3.11-rc6).
--
1.7.11.2.252.gc4a64c8
Date: Mon, 22 Apr 2013 02:21:32 +0000
This updates the Kconfig descriptions for the following:
* UTC namespace (UTS_NS)
* IPC namespace (IPC_NS)
Signed-off-by: Michael Witten <[email protected]>
---
init/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 247084b..6ba39b6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1093,7 +1093,7 @@ config UTS_NS
bool "UTS namespace"
default y
help
- In this namespace tasks see different info provided with the
+ In this namespace, tasks see different info provided with the
uname() system call
config IPC_NS
@@ -1101,7 +1101,7 @@ config IPC_NS
depends on (SYSVIPC || POSIX_MQUEUE)
default y
help
- In this namespace tasks work with IPC ids which correspond to
+ In this namespace, tasks work with IPC ids which correspond to
different IPC objects in different namespaces.
config USER_NS
--
1.7.11.2.252.gc4a64c8
Date: Fri, 8 Apr 2011 14:30:21 +0000
Indentation is one tab; help text is offset by a further 2 spaces.
Only whitespace has been changed, as evidenced by:
git diff --ignore-space-change
which exits successfully (no difference).
Signed-off-by: Michael Witten <[email protected]>
---
drivers/net/wireless/ipw2x00/Kconfig | 98 ++++++++++++++++++------------------
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/Kconfig b/drivers/net/wireless/ipw2x00/Kconfig
index 91c0cb3..001efb4 100644
--- a/drivers/net/wireless/ipw2x00/Kconfig
+++ b/drivers/net/wireless/ipw2x00/Kconfig
@@ -12,37 +12,37 @@ config IPW2100
select LIB80211
select LIBIPW
---help---
- A driver for the Intel PRO/Wireless 2100 Network
+ A driver for the Intel PRO/Wireless 2100 Network
Connection 802.11b wireless network adapter.
- See <file:Documentation/networking/README.ipw2100> for information on
+ See <file:Documentation/networking/README.ipw2100> for information on
- the capabilities currently enabled in this driver and for tips
+ the capabilities currently enabled in this driver and for tips
- for debugging issues and problems.
+ for debugging issues and problems.
In order to use this driver, you will need a firmware image for it.
- You can obtain the firmware from
+ You can obtain the firmware from
- <http://ipw2100.sf.net/>. Once you have the firmware image, you
+ <http://ipw2100.sf.net/>. Once you have the firmware image, you
will need to place it in /lib/firmware.
- You will also very likely need the Wireless Tools in order to
+ You will also very likely need the Wireless Tools in order to
- configure your card:
+ configure your card:
- <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
+ <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
- It is recommended that you compile this driver as a module (M)
+ It is recommended that you compile this driver as a module (M)
- rather than built-in (Y). This driver requires firmware at device
+ rather than built-in (Y). This driver requires firmware at device
- initialization time, and when built-in this typically happens
+ initialization time, and when built-in this typically happens
- before the filesystem is accessible (hence firmware will be
+ before the filesystem is accessible (hence firmware will be
- unavailable and initialization will fail). If you do choose to build
+ unavailable and initialization will fail). If you do choose to build
- this driver into your kernel image, you can avoid this problem by
+ this driver into your kernel image, you can avoid this problem by
- including the firmware and a firmware loader in an initramfs.
+ including the firmware and a firmware loader in an initramfs.
-
+
config IPW2100_MONITOR
- bool "Enable promiscuous mode"
+ bool "Enable promiscuous mode"
- depends on IPW2100
+ depends on IPW2100
- ---help---
+ ---help---
Enables promiscuous/monitor mode support for the ipw2100 driver.
- With this feature compiled into the driver, you can switch to
+ With this feature compiled into the driver, you can switch to
promiscuous mode via the Wireless Tool's Monitor mode. While in this
mode, no packets can be sent.
@@ -50,17 +50,17 @@ config IPW2100_DEBUG
bool "Enable full debugging output in IPW2100 module."
depends on IPW2100
---help---
- This option will enable debug tracing output for the IPW2100.
+ This option will enable debug tracing output for the IPW2100.
- This will result in the kernel module being ~60k larger. You can
+ This will result in the kernel module being ~60k larger. You can
- control which debug output is sent to the kernel log by setting the
+ control which debug output is sent to the kernel log by setting the
- value in
+ value in
/sys/bus/pci/drivers/ipw2100/debug_level
This entry will only exist if this option is enabled.
- If you are not trying to debug or develop the IPW2100 driver, you
+ If you are not trying to debug or develop the IPW2100 driver, you
most likely want to say N here.
config IPW2200
@@ -73,37 +73,37 @@ config IPW2200
select LIB80211
select LIBIPW
---help---
- A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network
+ A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network
- Connection adapters.
+ Connection adapters.
- See <file:Documentation/networking/README.ipw2200> for
+ See <file:Documentation/networking/README.ipw2200> for
- information on the capabilities currently enabled in this
+ information on the capabilities currently enabled in this
driver and for tips for debugging issues and problems.
In order to use this driver, you will need a firmware image for it.
- You can obtain the firmware from
+ You can obtain the firmware from
- <http://ipw2200.sf.net/>. See the above referenced README.ipw2200
+ <http://ipw2200.sf.net/>. See the above referenced README.ipw2200
for information on where to install the firmware images.
- You will also very likely need the Wireless Tools in order to
+ You will also very likely need the Wireless Tools in order to
- configure your card:
+ configure your card:
- <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
+ <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
- It is recommended that you compile this driver as a module (M)
+ It is recommended that you compile this driver as a module (M)
- rather than built-in (Y). This driver requires firmware at device
+ rather than built-in (Y). This driver requires firmware at device
- initialization time, and when built-in this typically happens
+ initialization time, and when built-in this typically happens
- before the filesystem is accessible (hence firmware will be
+ before the filesystem is accessible (hence firmware will be
- unavailable and initialization will fail). If you do choose to build
+ unavailable and initialization will fail). If you do choose to build
- this driver into your kernel image, you can avoid this problem by
+ this driver into your kernel image, you can avoid this problem by
- including the firmware and a firmware loader in an initramfs.
+ including the firmware and a firmware loader in an initramfs.
config IPW2200_MONITOR
- bool "Enable promiscuous mode"
+ bool "Enable promiscuous mode"
- depends on IPW2200
+ depends on IPW2200
- ---help---
+ ---help---
Enables promiscuous/monitor mode support for the ipw2200 driver.
- With this feature compiled into the driver, you can switch to
+ With this feature compiled into the driver, you can switch to
promiscuous mode via the Wireless Tool's Monitor mode. While in this
mode, no packets can be sent.
@@ -116,28 +116,28 @@ config IPW2200_PROMISCUOUS
depends on IPW2200_MONITOR
select IPW2200_RADIOTAP
---help---
- Enables the creation of a second interface prefixed 'rtap'.
+ Enables the creation of a second interface prefixed 'rtap'.
- This second interface will provide every received in radiotap
+ This second interface will provide every received in radiotap
format.
- This is useful for performing wireless network analysis while
+ This is useful for performing wireless network analysis while
- maintaining an active association.
+ maintaining an active association.
- Example usage:
+ Example usage:
- % modprobe ipw2200 rtap_iface=1
+ % modprobe ipw2200 rtap_iface=1
- % ifconfig rtap0 up
+ % ifconfig rtap0 up
- % tethereal -i rtap0
+ % tethereal -i rtap0
- If you do not specify 'rtap_iface=1' as a module parameter then
+ If you do not specify 'rtap_iface=1' as a module parameter then
- the rtap interface will not be created and you will need to turn
+ the rtap interface will not be created and you will need to turn
- it on via sysfs:
+ it on via sysfs:
-
+
- % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
+ % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
config IPW2200_QOS
- bool "Enable QoS support"
+ bool "Enable QoS support"
- depends on IPW2200
+ depends on IPW2200
config IPW2200_DEBUG
bool "Enable full debugging output in IPW2200 module."
Date: Fri, 8 Apr 2011 14:18:54 +0000
In particular:
* The word `frame' was missing in `received frame',
so it has been added.
* The `RF' in `a RF' was both superfluous and awkward,
so it has been removed.
As for the rest of the changes, well, I just couldn't help myself!
Signed-off-by: Michael Witten <[email protected]>
---
drivers/net/wireless/ipw2x00/Kconfig | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/Kconfig b/drivers/net/wireless/ipw2x00/Kconfig
index 5397cd1..5abf297 100644
--- a/drivers/net/wireless/ipw2x00/Kconfig
+++ b/drivers/net/wireless/ipw2x00/Kconfig
@@ -112,13 +112,13 @@ config IPW2200_RADIOTAP
depends on IPW2200_MONITOR
config IPW2200_PROMISCUOUS
- bool "Enable creation of a RF radiotap promiscuous interface"
+ bool "Enable creation of a radiotap promiscuous interface"
depends on IPW2200_MONITOR
select IPW2200_RADIOTAP
---help---
- Enables the creation of a second interface prefixed 'rtap'.
- This second interface will provide every received in radiotap
- format.
+ Enables the creation of a second interface (the name of which
+ is prefixed with 'rtap'), which provides every received frame
+ in radiotap format.
This is useful for performing wireless network analysis while
maintaining an active association.
@@ -129,9 +129,9 @@ config IPW2200_PROMISCUOUS
% ifconfig rtap0 up
% tethereal -i rtap0
- If you do not specify 'rtap_iface=1' as a module parameter then
- the rtap interface will not be created and you will need to turn
- it on via sysfs:
+ If you do not specify 'rtap_iface=1' as a module parameter, then
+ the rtap interface will not be created automatically, but it can
+ still be created via sysfs:
% echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
--
1.7.11.2.252.gc4a64c8
Date: Wed, 14 Aug 2013 09:59:45 +0000
Signed-off-by: Michael Witten <[email protected]>
---
fs/btrfs/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 2b3b832..e374bf9 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -59,7 +59,8 @@ config BTRFS_FS_RUN_SANITY_TESTS
help
This will run some basic sanity tests on the free space cache
code to make sure it is acting as it should. These are mostly
- regression tests and are only really interesting to btrfs devlopers.
+ regression tests and are only really interesting to btrfs
+ developers.
If unsure, say N.
--
1.7.11.2.252.gc4a64c8
Date: Thu, 15 Sep 2011 21:07:26 +0000
Signed-off-by: Michael Witten <[email protected]>
---
drivers/gpu/drm/drm_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f92da0a..062dc22 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -497,8 +497,8 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc)
/* Dot clock in Hz: */
dotclock = (u64) crtc->hwmode.clock * 1000;
- /* Fields of interlaced scanout modes are only halve a frame duration.
+ /* Fields of interlaced scanout modes are only half a frame duration.
- * Double the dotclock to get halve the frame-/line-/pixelduration.
+ * Double the dotclock to get half the frame-/line-/pixelduration.
*/
if (crtc->hwmode.flags & DRM_MODE_FLAG_INTERLACE)
dotclock *= 2;
--
1.7.11.2.252.gc4a64c8
Date: Thu, 15 Sep 2011 14:43:00 +0000
I assume `gdm_proc_lists' is a vestigial spelling.
Signed-off-by: Michael Witten <[email protected]>
---
drivers/gpu/drm/drm_proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index d7f2324..dfc6f1f 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -87,7 +87,7 @@ static const struct file_operations drm_proc_fops = {
* \return Zero on success, non-zero on failure
*
* Create a given set of proc files represented by an array of
- * gdm_proc_lists in the given root directory.
+ * drm_info_lists in the given root directory.
*/
static int drm_proc_create_files(const struct drm_info_list *files, int count,
struct proc_dir_entry *root, struct drm_minor *minor)
--
1.7.11.2.252.gc4a64c8
Date: Thu, 15 Sep 2011 21:12:19 +0000
The value of `gamma_size' is guaranteed to be zero when
the following `if' statement is reached:
if (gamma_size == 0)
gamma_size = fb_helper->crtc_info[i].mode_set.crtc->gamma_size
Thus, it could be reduced to just the following:
gamma_size = fb_helper->crtc_info[i].mode_set.crtc->gamma_size
However, `gamma_size' is never actually used anywhere. So, what's
the point? This commit removes it entirely from the function.
Signed-off-by: Michael Witten <[email protected]>
---
drivers/gpu/drm/drm_fb_helper.c | 3 ---
1 file changed, 3 deletions(-)
FOR YOUR CONVENIENCE, THE ENTIRE FUNCTION
IN QUESTION IS REPRODUCED HERE IN THE PATCH;
NOTICE THAT `gamma_size' IS NEVER USED
MEANINGFULLY.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3d13ca6e2..a6aab13 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -883,119 +883,116 @@
static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
int preferred_bpp)
{
int ret = 0;
int crtc_count = 0;
int i;
struct fb_info *info;
struct drm_fb_helper_surface_size sizes;
- int gamma_size = 0;
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
sizes.surface_bpp = 32;
sizes.fb_width = (unsigned)-1;
sizes.fb_height = (unsigned)-1;
/* if driver picks 8 or 16 by default use that
for both depth/bpp */
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
/* first up get a count of crtcs now in use and new min/maxes width/heights */
for (i = 0; i < fb_helper->connector_count; i++) {
struct drm_fb_helper_connector *fb_helper_conn = fb_helper->connector_info[i];
struct drm_cmdline_mode *cmdline_mode;
cmdline_mode = &fb_helper_conn->cmdline_mode;
if (cmdline_mode->bpp_specified) {
switch (cmdline_mode->bpp) {
case 8:
sizes.surface_depth = sizes.surface_bpp = 8;
break;
case 15:
sizes.surface_depth = 15;
sizes.surface_bpp = 16;
break;
case 16:
sizes.surface_depth = sizes.surface_bpp = 16;
break;
case 24:
sizes.surface_depth = sizes.surface_bpp = 24;
break;
case 32:
sizes.surface_depth = 24;
sizes.surface_bpp = 32;
break;
}
break;
}
}
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
desired_mode = fb_helper->crtc_info[i].desired_mode;
if (desired_mode) {
- if (gamma_size == 0)
- gamma_size = fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
if (desired_mode->hdisplay < sizes.fb_width)
sizes.fb_width = desired_mode->hdisplay;
if (desired_mode->vdisplay < sizes.fb_height)
sizes.fb_height = desired_mode->vdisplay;
if (desired_mode->hdisplay > sizes.surface_width)
sizes.surface_width = desired_mode->hdisplay;
if (desired_mode->vdisplay > sizes.surface_height)
sizes.surface_height = desired_mode->vdisplay;
crtc_count++;
}
}
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
/* hmm everyone went away - assume VGA cable just fell out
and will come back later. */
DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
sizes.fb_width = sizes.surface_width = 1024;
sizes.fb_height = sizes.surface_height = 768;
}
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
if (ret < 0)
return ret;
info = fb_helper->fbdev;
/*
* Set the fb pointer - usually drm_setup_crtcs does this for hotplug
* events, but at init time drm_setup_crtcs needs to be called before
* the fb is allocated (since we need to figure out the desired size of
* the fb before we can allocate it ...). Hence we need to fix things up
* here again.
*/
for (i = 0; i < fb_helper->crtc_count; i++)
if (fb_helper->crtc_info[i].mode_set.num_connectors)
fb_helper->crtc_info[i].mode_set.fb = fb_helper->fb;
info->var.pixclock = 0;
if (register_framebuffer(info) < 0)
return -EINVAL;
dev_info(fb_helper->dev->dev, "fb%d: %s frame buffer device\n",
info->node, info->fix.id);
/* Switch back to kernel console on panic */
/* multi card linked list maybe */
if (list_empty(&kernel_fb_helper_list)) {
dev_info(fb_helper->dev->dev, "registered panic notifier\n");
atomic_notifier_chain_register(&panic_notifier_list,
&paniced);
register_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
}
list_add(&fb_helper->kernel_fb_list, &kernel_fb_helper_list);
return 0;
}
--
1.7.11.2.252.gc4a64c8
On 08/20/2013 11:02:42 AM, Michael Witten wrote:
> I've been sitting on some trivial patches for a while, and I'd just
> like to get them out of the way.
>
> Here is the series:
>
> [1] Docs: Kconfig: For readability, offset modifiers with commas
> [2] Docs: Kconfig: Use consistent whitespace indentation
> [3] Docs: Kconfig: Clean up the radiotap documentation
Not a single worthwhile change in any of those three.
Excuse me:
Not a single, worthwhile change, in any of those three.
> [4] Docs: Kconfig: `devlopers' -> `developers'
Sure, a typo, why not.
Rob-
On Tue, 20 Aug 2013 16:20:02 -0500, Rob Landley wrote:
> On 08/20/2013 11:02:42 AM, Michael Witten wrote:
>> I've been sitting on some trivial patches for a while, and I'd just
>> like to get them out of the way.
>>
>> Here is the series:
>>
>> [1] Docs: Kconfig: For readability, offset modifiers with commas
>> [2] Docs: Kconfig: Use consistent whitespace indentation
>> [3] Docs: Kconfig: Clean up the radiotap documentation
>
> Not a single worthwhile change in any of those three.
>
> Excuse me:
>
> Not a single, worthwhile change, in any of those three.
Actually, your second attempt doesn't use commas properly.
In any case, this is *trivial*, miscellaneous work. I do not pretend
to be making a major contribution; this is why I sent these patches `To:'
Jiri Kosina <[email protected]>
Other people are included as some kind of courtesy, and also so that
any change that is actually non-trivial might be caught (as with the
`hotplug' patch).
>> [4] Docs: Kconfig: `devlopers' -> `developers'
>
> Sure, a typo, why not.
When does a series of *trivial* changes become worthwhile? What's wrong
with making refinements when it costs nothing? Must one always hide
trivial alterations inside something more substantial?
All right. I get it; you personally don't give a damn. I certainly
don't hold that against you. However, there *are* people who *do*
care about such refinements, and a nasty, condescending email
isn't going to alter our behavior.
Sincerely,
Michael Witten
On 08/20/2013 05:27:53 PM, Michael Witten wrote:
> On Tue, 20 Aug 2013 16:20:02 -0500, Rob Landley wrote:
> > On 08/20/2013 11:02:42 AM, Michael Witten wrote:
> >> I've been sitting on some trivial patches for a while, and I'd just
> >> like to get them out of the way.
> >>
> >> Here is the series:
> >>
> >> [1] Docs: Kconfig: For readability, offset modifiers with commas
> >> [2] Docs: Kconfig: Use consistent whitespace indentation
> >> [3] Docs: Kconfig: Clean up the radiotap documentation
> >
> > Not a single worthwhile change in any of those three.
> >
> > Excuse me:
> >
> > Not a single, worthwhile change, in any of those three.
>
> Actually, your second attempt doesn't use commas properly.
Sorry, forgot the <shatner> tags. (Or possibly <sarcasm>.)
> In any case, this is *trivial*, miscellaneous work. I do not pretend
> to be making a major contribution; this is why I sent these patches
> `To:'
>
> Jiri Kosina <[email protected]>
>
> Other people are included as some kind of courtesy, and also so that
> any change that is actually non-trivial might be caught (as with the
> `hotplug' patch).
If you were modifying the vfs would you cc the VFS maintainer as a
"courtesy" too?
> >> [4] Docs: Kconfig: `devlopers' -> `developers'
> >
> > Sure, a typo, why not.
>
> When does a series of *trivial* changes become worthwhile? What's
> wrong
> with making refinements when it costs nothing? Must one always hide
> trivial alterations inside something more substantial?
Because some people actually read the commit logs and changes that
don't do anything add noise for no benefit? (Your fourth change was a
single typo fix. The previous three changes _combined_ were less
valuable than that single typo fix. Hence asking if we really needed
three separate commits to accomplish something that didn't actually
need to be done in the first place.)
> All right. I get it; you personally don't give a damn. I certainly
> don't hold that against you. However, there *are* people who *do*
> care about such refinements, and a nasty, condescending email
> isn't going to alter our behavior.
Actually my objection is that it's not worth the churn in the commit
logs.
But yeah, why would a guy listed in MAINTAINERS as caring about the
Documentation directory pay attention to proposed changes to the
Documentation directory? Madness. I'll butt out now...
Rob-
On Tue, 20 Aug 2013 19:19:37 -0500, Rob Landley wrote:
> Because some people actually read the commit logs and changes that
> don't do anything add noise for no benefit? (Your fourth change was a
> single typo fix. The previous three changes _combined_ were less
> valuable than that single typo fix. Hence asking if we really needed
> three separate commits to accomplish something that didn't actually
> need to be done in the first place.)
> ...
> Actually my objection is that it's not worth the churn in the commit logs.
Naturally, we don't NEED three separate commits! Squash all of them
into one commit if that's something worth hissing about.
Do you need help with the relevant commands?
Because you are the former and current maintainer of large and active
projects, I'd expect you to *appreciate* the value of taking in
fine-grained patches for REVIEW (even if you don't appreciate their
sum total).
The patches have been written in a way to *ease* the job of the
maintainer in understanding the changes. The fact that you find each
patch ludicrously trivial is a GREAT sign, especially considering
that I sent them mainly to the maintainer of... *TRIVIAL* changes.
> But yeah, why would a guy listed in MAINTAINERS as caring about the
> Documentation directory pay attention to proposed changes to the
> Documentation directory? Madness. I'll butt out now...
Madness is thinking that it means something to have your name listed in
some file. You are the maintainer when people send you patches and pull
from your repo---that is, when people *like* working with you. That's it.
A name in a file is simply a starting point for those contributors who
may not know any better.
Don't take "your" position for granted.
On 08/20/2013 10:32:02 PM, Michael Witten wrote:
> On Tue, 20 Aug 2013 19:19:37 -0500, Rob Landley wrote:
>
> > Hence asking if we really needed
> > three separate commits to accomplish something that didn't actually
> > need to be done in the first place.)
> > ...
> > Actually my objection is that it's not worth the churn in the
> commit logs.
>
> Naturally, we don't NEED three separate commits! Squash all of them
> into one commit if that's something worth hissing about.
>
> Do you need help with the relevant commands?
The correct response to someone disagreeing you is to patronize them?
Query: did you notice the phrase "something that didn't actually need
to be done in the first place"? You quoted it and everything, so I'm
assuming you ignored it intentionally rather than simply not noticing.
> Because you are the former and current maintainer of large and active
> projects, I'd expect you to *appreciate* the value of taking in
> fine-grained patches for REVIEW (even if you don't appreciate their
> sum total).
I reviewed them. The result of that review is what you're objecting to.
> The patches have been written in a way to *ease* the job of the
> maintainer in understanding the changes.
My understanding is that they're pointless churn.
> The fact that you find each
> patch ludicrously trivial is a GREAT sign, especially considering
> that I sent them mainly to the maintainer of... *TRIVIAL* changes.
1) Not everything trivial is worth doing.
2) "A maintainer's job is to say no." - Alan Cox
> > But yeah, why would a guy listed in MAINTAINERS as caring about the
> > Documentation directory pay attention to proposed changes to the
> > Documentation directory? Madness. I'll butt out now...
>
> Madness is thinking that it means something to have your name listed
> in
> some file.
Huh. Oddly specific definition. Has anyone informed the psychiatric
profession?
> You are the maintainer when people send you patches and pull
> from your repo---that is, when people *like* working with you. That's
> it.
> A name in a file is simply a starting point for those contributors who
> may not know any better.
I only brought it up becauase you were objecting to me butting my nose
into your affairs.
> Don't take "your" position for granted.
Obviously when someone disagrees with you, threatening to get them
fired will immediately convince them of the virtue of your position. (I
presume this is how you handle restaurants as well?)
You misunderstand the nature of the position: this is volunteer
janitorial work. I don't get paid for it, and haven't even bothered to
list the maintainership on my resume. (Programmers get paid more than
tech writers.) I'd be pretty _happy_ to find somebody else willing to
do a better job at it. (I'd also love somebody to start up
kernel-traffic or the kernel podcast again, restart h-online, re-enable
rsync support in kernel.org...) I have way too many demands on my time,
but was _asked_ by the previous guy to take over when he didn't have
time anymore. I've been trying to carve out more time to clean up the
directory (in a librarian sort of way; didn't write the books but I can
shelve them more neatly), but free time seems to be self-consuming
these days...
None of this changes my opinion that your first three changes are
pointless churn, a waste of time, and not worth merging. (Your
indignant and self-important reaction to that evaluation _has_ changed
my opinion of your technical judgement and likelihood of listening to
you in the future, so that's something.)
Nothing stops one of the other maintainers from taking your patch over
my objections. Most documentation goes in through other trees anyway,
generally as part of series with code and documentation components. But
_my_ evaluation remains "NAK".
Rob-
On Wed, 21 Aug 2013 02:04:17 -0500, Rob Landley wrote:
> On 08/20/2013 10:32:02 PM, Michael Witten wrote:
>
>> On Tue, 20 Aug 2013 19:19:37 -0500, Rob Landley wrote:
>>
>>> Hence asking if we really needed
>>> three separate commits to accomplish something that didn't actually
>>> need to be done in the first place.)
>>> ...
>>> Actually my objection is that it's not worth the churn in the commit logs.
>>
>> Naturally, we don't NEED three separate commits! Squash all of them
>> into one commit if that's something worth hissing about.
>>
>> Do you need help with the relevant commands?
>
> The correct response to someone disagreeing you is to patronize them?
That's rich.
> Query: did you notice the phrase "something that didn't actually need
> to be done in the first place"? You quoted it and everything, so I'm
> assuming you ignored it intentionally rather than simply not noticing.
I quote my quote of your text:
> Hence asking if we really needed three separate commits to accomplish
> something that didn't actually need to be done in the first place.)
> ...
> Actually my objection is that it's not worth the churn in the commit
> logs.
Query: Do you not even know what you write, documentation maintainer?
>> Because you are the former and current maintainer of large and active
>> projects, I'd expect you to *appreciate* the value of taking in
>> fine-grained patches for REVIEW (even if you don't appreciate their
>> sum total).
>
> I reviewed them. The result of that review is what you're objecting to.
I'm objecting to your style.
> You misunderstand the nature of the position: this is volunteer
> janitorial work. I don't get paid for it
Some janitors mop whole floors. Other janitors scrub patches of moldy
grout with a toothbrush. There's no reason for one to belittle the
other---especially when *both* aren't getting paid.
> (Your indignant and self-important reaction to that evaluation _has_ changed
> my opinion of your technical judgement and likelihood of listening to
> you in the future, so that's something.)
My sentiments exactly.
You are a master of irony.
> Nothing stops one of the other maintainers from taking your patch over
> my objections. Most documentation goes in through other trees anyway,
> generally as part of series with code and documentation components. But
> _my_ evaluation remains "NAK".
Good grief. The destiny of these trivial patches is irrelevant at this
point in our conversation; please reflect instead on the destiny of
your relationship with other people.