This patch removes bouncing email addresses of Tigran Aivazian from the
kernel tree.
Signed-off-by: Adrian Bunk <[email protected]>
---
Documentation/filesystems/bfs.txt | 2 +-
arch/i386/kernel/microcode.c | 28 ++++++++++++++--------------
arch/sh/kernel/kgdb_stub.c | 2 +-
drivers/net/tlan.c | 2 +-
fs/bfs/bfs.h | 2 +-
fs/bfs/dir.c | 2 +-
fs/bfs/file.c | 2 +-
fs/bfs/inode.c | 2 +-
fs/proc/kcore.c | 4 ++--
include/asm-sh/kgdb.h | 2 +-
include/linux/bfs_fs.h | 2 +-
mm/vmalloc.c | 2 +-
12 files changed, 26 insertions(+), 26 deletions(-)
--- linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c.old 2006-11-30 06:04:39.000000000 +0100
+++ linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c 2006-11-30 06:08:32.000000000 +0100
@@ -20,25 +20,25 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
- * 1.0 16 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.0 16 Feb 2000, Tigran Aivazian
* Initial release.
- * 1.01 18 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.01 18 Feb 2000, Tigran Aivazian
* Added read() support + cleanups.
- * 1.02 21 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.02 21 Feb 2000, Tigran Aivazian
* Added 'device trimming' support. open(O_WRONLY) zeroes
* and frees the saved copy of applied microcode.
- * 1.03 29 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.03 29 Feb 2000, Tigran Aivazian
* Made to use devfs (/dev/cpu/microcode) + cleanups.
* 1.04 06 Jun 2000, Simon Trimmer <[email protected]>
* Added misc device support (now uses both devfs and misc).
* Added MICROCODE_IOCFREE ioctl to clear memory.
* 1.05 09 Jun 2000, Simon Trimmer <[email protected]>
* Messages for error cases (non Intel & no suitable microcode).
- * 1.06 03 Aug 2000, Tigran Aivazian <[email protected]>
+ * 1.06 03 Aug 2000, Tigran Aivazian
* Removed ->release(). Removed exclusive open and status bitmap.
* Added microcode_rwsem to serialize read()/write()/ioctl().
* Removed global kernel lock usage.
- * 1.07 07 Sep 2000, Tigran Aivazian <[email protected]>
+ * 1.07 07 Sep 2000, Tigran Aivazian
* Write 0 to 0x8B msr and then cpuid before reading revision,
* so that it works even if there were no update done by the
* BIOS. Otherwise, reading from 0x8B gives junk (which happened
@@ -46,26 +46,26 @@
* disabled update by the BIOS)
* Thanks to Eric W. Biederman <[email protected]> for the fix.
* 1.08 11 Dec 2000, Richard Schaal <[email protected]> and
- * Tigran Aivazian <[email protected]>
+ * Tigran Aivazian
* Intel Pentium 4 processor support and bugfixes.
- * 1.09 30 Oct 2001, Tigran Aivazian <[email protected]>
+ * 1.09 30 Oct 2001, Tigran Aivazian
* Bugfix for HT (Hyper-Threading) enabled processors
* whereby processor resources are shared by all logical processors
* in a single CPU package.
* 1.10 28 Feb 2002 Asit K Mallick <[email protected]> and
- * Tigran Aivazian <[email protected]>,
+ * Tigran Aivazian
* Serialize updates as required on HT processors due to speculative
* nature of implementation.
- * 1.11 22 Mar 2002 Tigran Aivazian <[email protected]>
+ * 1.11 22 Mar 2002 Tigran Aivazian
* Fix the panic when writing zero-length microcode chunk.
* 1.12 29 Sep 2003 Nitin Kamble <[email protected]>,
* Jun Nakajima <[email protected]>
* Support for the microcode updates in the new format.
- * 1.13 10 Oct 2003 Tigran Aivazian <[email protected]>
+ * 1.13 10 Oct 2003 Tigran Aivazian
* Removed ->read() method and obsoleted MICROCODE_IOCFREE ioctl
* because we no longer hold a copy of applied microcode
* in kernel memory.
- * 1.14 25 Jun 2004 Tigran Aivazian <[email protected]>
+ * 1.14 25 Jun 2004 Tigran Aivazian
* Fix sigmatch() macro to handle old CPUs with pf == 0.
* Thanks to Stuart Swales for pointing out this bug.
*/
@@ -92,7 +92,7 @@
#include <asm/processor.h>
MODULE_DESCRIPTION("Intel CPU (IA-32) Microcode Update Driver");
-MODULE_AUTHOR("Tigran Aivazian <[email protected]>");
+MODULE_AUTHOR("Tigran Aivazian");
MODULE_LICENSE("GPL");
#define MICROCODE_VERSION "1.14a"
@@ -752,7 +752,7 @@
register_hotcpu_notifier(&mc_cpu_notifier);
printk(KERN_INFO
- "IA-32 Microcode Update Driver: v" MICROCODE_VERSION " <[email protected]>\n");
+ "IA-32 Microcode Update Driver: v" MICROCODE_VERSION "\n");
return 0;
}
--- linux-2.6.19-rc6-mm2/Documentation/filesystems/bfs.txt.old 2006-11-30 06:07:30.000000000 +0100
+++ linux-2.6.19-rc6-mm2/Documentation/filesystems/bfs.txt 2006-11-30 06:08:00.000000000 +0100
@@ -54,4 +54,4 @@
If you have any patches, questions or suggestions regarding this BFS
implementation please contact the author:
-Tigran A. Aivazian <[email protected]>
+Tigran A. Aivazian <[email protected]>
--- linux-2.6.19-rc6-mm2/arch/sh/kernel/kgdb_stub.c.old 2006-11-30 06:08:47.000000000 +0100
+++ linux-2.6.19-rc6-mm2/arch/sh/kernel/kgdb_stub.c 2006-11-30 06:08:58.000000000 +0100
@@ -3,7 +3,7 @@
* License. See linux/COPYING for more information.
*
* Containes extracts from code by Glenn Engel, Jim Kingdon,
- * David Grothe <[email protected]>, Tigran Aivazian <[email protected]>,
+ * David Grothe <[email protected]>, Tigran Aivazian,
* Amit S. Kale <[email protected]>, William Gatliff <[email protected]>,
* Ben Lee, Steve Chamberlain and Benoit Miller <[email protected]>.
*
--- linux-2.6.19-rc6-mm2/drivers/net/tlan.c.old 2006-11-30 06:09:09.000000000 +0100
+++ linux-2.6.19-rc6-mm2/drivers/net/tlan.c 2006-11-30 06:09:26.000000000 +0100
@@ -29,7 +29,7 @@
*
* Change History
*
- * Tigran Aivazian <[email protected]>: TLan_PciProbe() now uses
+ * Tigran Aivazian : TLan_PciProbe() now uses
* new PCI BIOS interface.
* Alan Cox <[email protected]>: Fixed the out of memory
* handling.
--- linux-2.6.19-rc6-mm2/fs/bfs/bfs.h.old 2006-11-30 06:09:35.000000000 +0100
+++ linux-2.6.19-rc6-mm2/fs/bfs/bfs.h 2006-11-30 06:09:40.000000000 +0100
@@ -1,6 +1,6 @@
/*
* fs/bfs/bfs.h
- * Copyright (C) 1999 Tigran Aivazian <[email protected]>
+ * Copyright (C) 1999 Tigran Aivazian
*/
#ifndef _FS_BFS_BFS_H
#define _FS_BFS_BFS_H
--- linux-2.6.19-rc6-mm2/fs/bfs/dir.c.old 2006-11-30 06:09:46.000000000 +0100
+++ linux-2.6.19-rc6-mm2/fs/bfs/dir.c 2006-11-30 06:09:51.000000000 +0100
@@ -1,7 +1,7 @@
/*
* fs/bfs/dir.c
* BFS directory operations.
- * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
+ * Copyright (C) 1999,2000 Tigran Aivazian
* Made endianness-clean by Andrew Stribblehill <[email protected]> 2005
*/
--- linux-2.6.19-rc6-mm2/fs/bfs/file.c.old 2006-11-30 06:09:57.000000000 +0100
+++ linux-2.6.19-rc6-mm2/fs/bfs/file.c 2006-11-30 06:10:02.000000000 +0100
@@ -1,7 +1,7 @@
/*
* fs/bfs/file.c
* BFS file operations.
- * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
+ * Copyright (C) 1999,2000 Tigran Aivazian
*/
#include <linux/fs.h>
--- linux-2.6.19-rc6-mm2/fs/bfs/inode.c.old 2006-11-30 06:10:11.000000000 +0100
+++ linux-2.6.19-rc6-mm2/fs/bfs/inode.c 2006-11-30 06:10:16.000000000 +0100
@@ -1,7 +1,7 @@
/*
* fs/bfs/inode.c
* BFS superblock and inode operations.
- * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
+ * Copyright (C) 1999,2000 Tigran Aivazian
* From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
*
* Made endianness-clean by Andrew Stribblehill <[email protected]>, 2005.
--- linux-2.6.19-rc6-mm2/fs/proc/kcore.c.old 2006-11-30 06:10:43.000000000 +0100
+++ linux-2.6.19-rc6-mm2/fs/proc/kcore.c 2006-11-30 06:11:00.000000000 +0100
@@ -4,8 +4,8 @@
* Modelled on fs/exec.c:aout_core_dump()
* Jeremy Fitzhardinge <[email protected]>
* ELF version written by David Howells <[email protected]>
- * Modified and incorporated into 2.3.x by Tigran Aivazian <[email protected]>
- * Support to dump vmalloc'd areas (ELF only), Tigran Aivazian <[email protected]>
+ * Modified and incorporated into 2.3.x by Tigran Aivazian
+ * Support to dump vmalloc'd areas (ELF only), Tigran Aivazian
* Safe accesses to vmalloc/direct-mapped discontiguous areas, Kanoj Sarcar <[email protected]>
*/
--- linux-2.6.19-rc6-mm2/include/asm-sh/kgdb.h.old 2006-11-30 06:11:08.000000000 +0100
+++ linux-2.6.19-rc6-mm2/include/asm-sh/kgdb.h 2006-11-30 06:11:16.000000000 +0100
@@ -3,7 +3,7 @@
* License. See linux/COPYING for more information.
*
* Based on original code by Glenn Engel, Jim Kingdon,
- * David Grothe <[email protected]>, Tigran Aivazian, <[email protected]> and
+ * David Grothe <[email protected]>, Tigran Aivazian, and
* Amit S. Kale <[email protected]>
*
* Super-H port based on sh-stub.c (Ben Lee and Steve Chamberlain) by
--- linux-2.6.19-rc6-mm2/include/linux/bfs_fs.h.old 2006-11-30 06:11:26.000000000 +0100
+++ linux-2.6.19-rc6-mm2/include/linux/bfs_fs.h 2006-11-30 06:11:31.000000000 +0100
@@ -1,6 +1,6 @@
/*
* include/linux/bfs_fs.h - BFS data structures on disk.
- * Copyright (C) 1999 Tigran Aivazian <[email protected]>
+ * Copyright (C) 1999 Tigran Aivazian
*/
#ifndef _LINUX_BFS_FS_H
--- linux-2.6.19-rc6-mm2/mm/vmalloc.c.old 2006-11-30 06:11:38.000000000 +0100
+++ linux-2.6.19-rc6-mm2/mm/vmalloc.c 2006-11-30 06:11:46.000000000 +0100
@@ -3,7 +3,7 @@
*
* Copyright (C) 1993 Linus Torvalds
* Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
- * SMP-safe vmalloc/vfree/ioremap, Tigran Aivazian <[email protected]>, May 2000
+ * SMP-safe vmalloc/vfree/ioremap, Tigran Aivazian, May 2000
* Major rework to support vmap/vunmap, Christoph Hellwig, SGI, August 2002
* Numa awareness, Christoph Lameter, SGI, June 2005
*/
I am curious, what's the point?
These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
were at that point.
It's not MAINTAINERS. If people want to contact someone, go find the latest address there.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Adrian Bunk
> Sent: Thursday, November 30, 2006 9:52 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [2.6 patch] Tigran Aivazian: remove bouncing email addresses
>
> This patch removes bouncing email addresses of Tigran
> Aivazian from the kernel tree.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> ---
>
> Documentation/filesystems/bfs.txt | 2 +-
> arch/i386/kernel/microcode.c | 28 ++++++++++++++--------------
> arch/sh/kernel/kgdb_stub.c | 2 +-
> drivers/net/tlan.c | 2 +-
> fs/bfs/bfs.h | 2 +-
> fs/bfs/dir.c | 2 +-
> fs/bfs/file.c | 2 +-
> fs/bfs/inode.c | 2 +-
> fs/proc/kcore.c | 4 ++--
> include/asm-sh/kgdb.h | 2 +-
> include/linux/bfs_fs.h | 2 +-
> mm/vmalloc.c | 2 +-
> 12 files changed, 26 insertions(+), 26 deletions(-)
>
> --- linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c.old
> 2006-11-30 06:04:39.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/arch/i386/kernel/microcode.c
> 2006-11-30 06:08:32.000000000 +0100
> @@ -20,25 +20,25 @@
> * as published by the Free Software Foundation; either version
> * 2 of the License, or (at your option) any later version.
> *
> - * 1.0 16 Feb 2000, Tigran Aivazian <[email protected]>
> + * 1.0 16 Feb 2000, Tigran Aivazian
> * Initial release.
> - * 1.01 18 Feb 2000, Tigran Aivazian <[email protected]>
> + * 1.01 18 Feb 2000, Tigran Aivazian
> * Added read() support + cleanups.
> - * 1.02 21 Feb 2000, Tigran Aivazian <[email protected]>
> + * 1.02 21 Feb 2000, Tigran Aivazian
> * Added 'device trimming' support. open(O_WRONLY) zeroes
> * and frees the saved copy of applied microcode.
> - * 1.03 29 Feb 2000, Tigran Aivazian <[email protected]>
> + * 1.03 29 Feb 2000, Tigran Aivazian
> * Made to use devfs (/dev/cpu/microcode) + cleanups.
> * 1.04 06 Jun 2000, Simon Trimmer <[email protected]>
> * Added misc device support (now uses both devfs
> and misc).
> * Added MICROCODE_IOCFREE ioctl to clear memory.
> * 1.05 09 Jun 2000, Simon Trimmer <[email protected]>
> * Messages for error cases (non Intel & no
> suitable microcode).
> - * 1.06 03 Aug 2000, Tigran Aivazian <[email protected]>
> + * 1.06 03 Aug 2000, Tigran Aivazian
> * Removed ->release(). Removed exclusive open and
> status bitmap.
> * Added microcode_rwsem to serialize
> read()/write()/ioctl().
> * Removed global kernel lock usage.
> - * 1.07 07 Sep 2000, Tigran Aivazian <[email protected]>
> + * 1.07 07 Sep 2000, Tigran Aivazian
> * Write 0 to 0x8B msr and then cpuid before
> reading revision,
> * so that it works even if there were no update
> done by the
> * BIOS. Otherwise, reading from 0x8B gives junk
> (which happened
> @@ -46,26 +46,26 @@
> * disabled update by the BIOS)
> * Thanks to Eric W. Biederman
> <[email protected]> for the fix.
> * 1.08 11 Dec 2000, Richard Schaal
> <[email protected]> and
> - * Tigran Aivazian <[email protected]>
> + * Tigran Aivazian
> * Intel Pentium 4 processor support and bugfixes.
> - * 1.09 30 Oct 2001, Tigran Aivazian <[email protected]>
> + * 1.09 30 Oct 2001, Tigran Aivazian
> * Bugfix for HT (Hyper-Threading) enabled processors
> * whereby processor resources are shared by all
> logical processors
> * in a single CPU package.
> * 1.10 28 Feb 2002 Asit K Mallick
> <[email protected]> and
> - * Tigran Aivazian <[email protected]>,
> + * Tigran Aivazian
> * Serialize updates as required on HT processors
> due to speculative
> * nature of implementation.
> - * 1.11 22 Mar 2002 Tigran Aivazian <[email protected]>
> + * 1.11 22 Mar 2002 Tigran Aivazian
> * Fix the panic when writing zero-length microcode chunk.
> * 1.12 29 Sep 2003 Nitin Kamble <[email protected]>,
> * Jun Nakajima <[email protected]>
> * Support for the microcode updates in the new format.
> - * 1.13 10 Oct 2003 Tigran Aivazian <[email protected]>
> + * 1.13 10 Oct 2003 Tigran Aivazian
> * Removed ->read() method and obsoleted
> MICROCODE_IOCFREE ioctl
> * because we no longer hold a copy of applied microcode
> * in kernel memory.
> - * 1.14 25 Jun 2004 Tigran Aivazian <[email protected]>
> + * 1.14 25 Jun 2004 Tigran Aivazian
> * Fix sigmatch() macro to handle old CPUs with pf == 0.
> * Thanks to Stuart Swales for pointing out this bug.
> */
> @@ -92,7 +92,7 @@
> #include <asm/processor.h>
>
> MODULE_DESCRIPTION("Intel CPU (IA-32) Microcode Update
> Driver"); -MODULE_AUTHOR("Tigran Aivazian <[email protected]>");
> +MODULE_AUTHOR("Tigran Aivazian");
> MODULE_LICENSE("GPL");
>
> #define MICROCODE_VERSION "1.14a"
> @@ -752,7 +752,7 @@
> register_hotcpu_notifier(&mc_cpu_notifier);
>
> printk(KERN_INFO
> - "IA-32 Microcode Update Driver: v"
> MICROCODE_VERSION " <[email protected]>\n");
> + "IA-32 Microcode Update Driver: v"
> MICROCODE_VERSION "\n");
> return 0;
> }
>
> ---
> linux-2.6.19-rc6-mm2/Documentation/filesystems/bfs.txt.old
> 2006-11-30 06:07:30.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/Documentation/filesystems/bfs.txt
> 2006-11-30 06:08:00.000000000 +0100
> @@ -54,4 +54,4 @@
> If you have any patches, questions or suggestions regarding
> this BFS implementation please contact the author:
>
> -Tigran A. Aivazian <[email protected]>
> +Tigran A. Aivazian <[email protected]>
> --- linux-2.6.19-rc6-mm2/arch/sh/kernel/kgdb_stub.c.old
> 2006-11-30 06:08:47.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/arch/sh/kernel/kgdb_stub.c
> 2006-11-30 06:08:58.000000000 +0100
> @@ -3,7 +3,7 @@
> * License. See linux/COPYING for more information.
> *
> * Containes extracts from code by Glenn Engel, Jim Kingdon,
> - * David Grothe <[email protected]>, Tigran Aivazian <[email protected]>,
> + * David Grothe <[email protected]>, Tigran Aivazian,
> * Amit S. Kale <[email protected]>, William Gatliff
> <[email protected]>,
> * Ben Lee, Steve Chamberlain and Benoit Miller <[email protected]>.
> *
> --- linux-2.6.19-rc6-mm2/drivers/net/tlan.c.old
> 2006-11-30 06:09:09.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/drivers/net/tlan.c 2006-11-30
> 06:09:26.000000000 +0100
> @@ -29,7 +29,7 @@
> *
> * Change History
> *
> - * Tigran Aivazian <[email protected]>: TLan_PciProbe() now uses
> + * Tigran Aivazian : TLan_PciProbe() now uses
> * new PCI BIOS interface.
> * Alan Cox <[email protected]>: Fixed the out of memory
> * handling.
> --- linux-2.6.19-rc6-mm2/fs/bfs/bfs.h.old 2006-11-30
> 06:09:35.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/fs/bfs/bfs.h 2006-11-30
> 06:09:40.000000000 +0100
> @@ -1,6 +1,6 @@
> /*
> * fs/bfs/bfs.h
> - * Copyright (C) 1999 Tigran Aivazian <[email protected]>
> + * Copyright (C) 1999 Tigran Aivazian
> */
> #ifndef _FS_BFS_BFS_H
> #define _FS_BFS_BFS_H
> --- linux-2.6.19-rc6-mm2/fs/bfs/dir.c.old 2006-11-30
> 06:09:46.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/fs/bfs/dir.c 2006-11-30
> 06:09:51.000000000 +0100
> @@ -1,7 +1,7 @@
> /*
> * fs/bfs/dir.c
> * BFS directory operations.
> - * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
> + * Copyright (C) 1999,2000 Tigran Aivazian
> * Made endianness-clean by Andrew Stribblehill
> <[email protected]> 2005
> */
>
> --- linux-2.6.19-rc6-mm2/fs/bfs/file.c.old 2006-11-30
> 06:09:57.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/fs/bfs/file.c 2006-11-30
> 06:10:02.000000000 +0100
> @@ -1,7 +1,7 @@
> /*
> * fs/bfs/file.c
> * BFS file operations.
> - * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
> + * Copyright (C) 1999,2000 Tigran Aivazian
> */
>
> #include <linux/fs.h>
> --- linux-2.6.19-rc6-mm2/fs/bfs/inode.c.old 2006-11-30
> 06:10:11.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/fs/bfs/inode.c 2006-11-30
> 06:10:16.000000000 +0100
> @@ -1,7 +1,7 @@
> /*
> * fs/bfs/inode.c
> * BFS superblock and inode operations.
> - * Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
> + * Copyright (C) 1999,2000 Tigran Aivazian
> * From fs/minix, Copyright (C) 1991, 1992 Linus Torvalds.
> *
> * Made endianness-clean by Andrew Stribblehill
> <[email protected]>, 2005.
> --- linux-2.6.19-rc6-mm2/fs/proc/kcore.c.old 2006-11-30
> 06:10:43.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/fs/proc/kcore.c 2006-11-30
> 06:11:00.000000000 +0100
> @@ -4,8 +4,8 @@
> * Modelled on fs/exec.c:aout_core_dump()
> * Jeremy Fitzhardinge <[email protected]>
> * ELF version written by David Howells <[email protected]>
> - * Modified and incorporated into 2.3.x by Tigran Aivazian
> <[email protected]>
> - * Support to dump vmalloc'd areas (ELF only), Tigran
> Aivazian <[email protected]>
> + * Modified and incorporated into 2.3.x by Tigran Aivazian
> + * Support to dump vmalloc'd areas (ELF only), Tigran Aivazian
> * Safe accesses to vmalloc/direct-mapped discontiguous
> areas, Kanoj Sarcar <[email protected]>
> */
>
> --- linux-2.6.19-rc6-mm2/include/asm-sh/kgdb.h.old
> 2006-11-30 06:11:08.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/include/asm-sh/kgdb.h
> 2006-11-30 06:11:16.000000000 +0100
> @@ -3,7 +3,7 @@
> * License. See linux/COPYING for more information.
> *
> * Based on original code by Glenn Engel, Jim Kingdon,
> - * David Grothe <[email protected]>, Tigran Aivazian,
> <[email protected]> and
> + * David Grothe <[email protected]>, Tigran Aivazian, and
> * Amit S. Kale <[email protected]>
> *
> * Super-H port based on sh-stub.c (Ben Lee and Steve Chamberlain) by
> --- linux-2.6.19-rc6-mm2/include/linux/bfs_fs.h.old
> 2006-11-30 06:11:26.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/include/linux/bfs_fs.h
> 2006-11-30 06:11:31.000000000 +0100
> @@ -1,6 +1,6 @@
> /*
> * include/linux/bfs_fs.h - BFS data structures on disk.
> - * Copyright (C) 1999 Tigran Aivazian <[email protected]>
> + * Copyright (C) 1999 Tigran Aivazian
> */
>
> #ifndef _LINUX_BFS_FS_H
> --- linux-2.6.19-rc6-mm2/mm/vmalloc.c.old 2006-11-30
> 06:11:38.000000000 +0100
> +++ linux-2.6.19-rc6-mm2/mm/vmalloc.c 2006-11-30
> 06:11:46.000000000 +0100
> @@ -3,7 +3,7 @@
> *
> * Copyright (C) 1993 Linus Torvalds
> * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
> - * SMP-safe vmalloc/vfree/ioremap, Tigran Aivazian
> <[email protected]>, May 2000
> + * SMP-safe vmalloc/vfree/ioremap, Tigran Aivazian, May 2000
> * Major rework to support vmap/vunmap, Christoph Hellwig,
> SGI, August 2002
> * Numa awareness, Christoph Lameter, SGI, June 2005
> */
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, Nov 30, 2006 at 10:00:35PM -0800, Hua Zhong wrote:
> I am curious, what's the point?
Email addresses are for contacting people.
> These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
> were at that point.
For historical purposes, you can always use historical kernels.
> It's not MAINTAINERS. If people want to contact someone, go find the latest address there.
It's also MODULE_AUTHOR() and printk() which are far more user-visible
than MAINTAINERS.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> On Thu, Nov 30, 2006 at 10:00:35PM -0800, Hua Zhong wrote:
>
> > I am curious, what's the point?
>
> Email addresses are for contacting people.
Do you go back and change all the signed-off lines too when people change jobs?
> > These email addresses serve a "historical" purpose: they tell
> > when the contribution was made, what the author's email addresses
> > were at that point.
>
> For historical purposes, you can always use historical kernels.
Then remove all the lines like the following:
- * 1.0 16 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.0 16 Feb 2000, Tigran Aivazian
* Initial release.
- * 1.01 18 Feb 2000, Tigran Aivazian <[email protected]>
+ * 1.01 18 Feb 2000, Tigran Aivazian
* Added read() support + cleanups.
If you keep them, they tell the history and email addresses are part of the history.
Or simply remove all the history and tell people to look for the information in git changelogs.
The way you are doing it, serves no purpose other than losing information.
> > It's not MAINTAINERS. If people want to contact someone, go
> > find the latest address there.
>
> It's also MODULE_AUTHOR() and printk() which are far more
> user-visible than MAINTAINERS.
Those are OK. But majority of you patch isn't the case.
On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
> I am curious, what's the point?
>
> These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
> were at that point.
.. and which company owns the copyright.
Lets not remove historical email addresses. Just make sure there's a
current one in MODULE_AUTHOR / MAINTAINERS.
Hi Arjan,
On Fri, 1 Dec 2006, Arjan van de Ven wrote:
> On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
>> I am curious, what's the point?
>>
>> These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
>> were at that point.
>
>
> .. and which company owns the copyright.
VERITAS doesn't own any copyright of the microcode driver because I wrote
it _before_ I joined VERITAS.
> Lets not remove historical email addresses. Just make sure there's a
> current one in MODULE_AUTHOR / MAINTAINERS.
I agree, so I should have included in the patch the change to
MODULE_AUTHOR (in both microcode and bfs).
Or maybe MODULE_AUTHOR shouldn't contain the email address, if the module
is mentioned in the MAINTAINERS which does contain it? Why repeat the data
and so have to remember to maintain it?
Kind regards
Tigran
> Or maybe MODULE_AUTHOR shouldn't contain the email address, if the module
> is mentioned in the MAINTAINERS which does contain it? Why repeat the data
> and so have to remember to maintain it?
MODULE_AUTHOR is actually nicer than MAINTAINERS in many ways; for
example end users can see it with "modinfo". Also for non-kernel experts
it's not always easy to map module names to the descriptions in the
MAINTAINERS file...
On Fri, Dec 01, 2006 at 10:08:39AM +0100, Arjan van de Ven wrote:
> On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
> > I am curious, what's the point?
> >
> > These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
> > were at that point.
>
>
> .. and which company owns the copyright.
>...
Email addresses aren't good for this kind of information.
As an example, what is stusta.de and does it have any rights on my
contributions? [1]
cu
Adrian
[1] it can't own the copyright since in Germany the copyright belongs
untransferably [2] to the author [3]
[2] except for heritage
[3] but he can give exclusive usage rights for known kinds of usage
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On 12/1/06, Arjan van de Ven <[email protected]> wrote:
> On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
> > I am curious, what's the point?
> >
> > These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
> > were at that point.
Approximately when I wish the copyright dates were comma separated
iso8601 date ranges myself.
I also am not likely to typically care what their email address was
then, I want current information in the current kernel sources.
If I want old email address I got old tarballs I can get at least.
> .. and which company owns the copyright.
Not in the USA according to http://www.copyright.gov/title17/92chap4.html#401 .
[[ ... ? 401. Notice of copyright: Visually perceptible copies ...
b) Form of Notice. ? If a notice appears on the copies, it shall
consist of the following three elements:
(1) the symbol (c) (the letter C in a circle), or the word
"Copyright", or the abbreviation "Copr."; and
(2) the year of first publication of the work; in the case of
compilations or derivative works incorporating previously published
material, the year date of first publication of the compilation or
derivative work is sufficient. The year date may be omitted where a
pictorial, graphic, or sculptural work, with accompanying text matter,
if any, is reproduced in or on greeting cards, postcards, stationery,
jewelry, dolls, toys, or any useful articles; and
(3) the name of the owner of copyright in the work, or an abbreviation
by which the name can be recognized, or a generally known alternative
designation of the owner. ]]
For source code generally there are a few changes for typical copyright notices:
They use "Copyright (C)" because ASCII and EBCDIC didn't have native
copyright symbol like unicode does now.
They include years in which they were published and not just the first
year in which in this version was published.
The name of copyright owner typically also includes an email address.
Copyright (C) 1999,2000 Tigran Aivazian <[email protected]>
Copyright (C) 1999 Tigran Aivazian <[email protected]>
etc seems like only copyright notices changed effect Tigran and if
Tigran meant for it to be copyrighted by veritas he would have done
Copyright (C) 1999 Veritas Inc. http://www.veritas.com/
However he did not do so.
Of course I'd prefer something closer to
Copyright (C) 1999-07-05/2000-03-12 Tigran Aivazian
<[email protected]>
or at least
Copyright (C) 1999-07-05/2000-03 Tigran Aivazian <[email protected]>
Especially if the laws ever get changed to make copyright durations
shorter. Like 14 years instead of 50 years ,70 years, or as old as
Disney's Steam Boat Willie.
>
> Lets not remove historical email addresses. Just make sure there's a
> current one in MODULE_AUTHOR / MAINTAINERS.
I think whoever should either remove or update the email addresses.
--
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
On 01/12/06, Hua Zhong <[email protected]> wrote:
> I am curious, what's the point?
>
> These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
> were at that point.
>
> It's not MAINTAINERS. If people want to contact someone, go find the latest address there.
>
Yes, MAINTAINERS is the preferred location for maintainer info, but
when there is no entry in maintainers (or when the person listed there
is not responsive), many people (including me) use the names or email
addresses listed in source files as people to contact. So it's nice
when the email addresses are up to date.
In my opinion the addresses should be working ones or not present at
all (or at the very least there should be a note that the email
address is outdated).
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Hi Adrian,
I have only now had time to read your patch and reject most of it --- the
email addresses in the revision histories etc are for historical purposes
and as such are very useful. They are NOT meant to be valid except at the
moment of time when they are written. The only purpose of email address in
the revision history is the indication where the person worked _at the
time_.
The only bits that should be made sure to remain valid are the
MODULE_AUTHOR, as Arjan also mentioned.
Also, it is very strange that I have _not_ received your original email
containing the patch --- I only saw it now via lkml archive.
Kind regards
Tigran
On Fri, 1 Dec 2006, Adrian Bunk wrote:
> On Fri, Dec 01, 2006 at 10:08:39AM +0100, Arjan van de Ven wrote:
>> On Thu, 2006-11-30 at 22:00 -0800, Hua Zhong wrote:
>>> I am curious, what's the point?
>>>
>>> These email addresses serve a "historical" purpose: they tell when the contribution was made, what the author's email addresses
>>> were at that point.
>>
>>
>> .. and which company owns the copyright.
>> ...
>
> Email addresses aren't good for this kind of information.
>
> As an example, what is stusta.de and does it have any rights on my
> contributions? [1]
>
> cu
> Adrian
>
> [1] it can't own the copyright since in Germany the copyright belongs
> untransferably [2] to the author [3]
> [2] except for heritage
> [3] but he can give exclusive usage rights for known kinds of usage
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
>
>
On Sat, Dec 02, 2006 at 09:08:56PM +0000, Tigran Aivazian wrote:
> Hi Adrian,
Hi Tigran,
> I have only now had time to read your patch and reject most of it --- the
> email addresses in the revision histories etc are for historical purposes
> and as such are very useful. They are NOT meant to be valid except at the
> moment of time when they are written. The only purpose of email address in
> the revision history is the indication where the person worked _at the
> time_.
as I explained with my email address as an example, email addresses
aren't suitable for this.
> The only bits that should be made sure to remain valid are the
> MODULE_AUTHOR, as Arjan also mentioned.
Even the "please contact the author" and the printk() should continue to
contain known bouncing addresses?
> Also, it is very strange that I have _not_ received your original email
> containing the patch --- I only saw it now via lkml archive.
I haven't yet gotten a bounce from [email protected].
Do you have a spamfilter?
Or a provider doing some kind of email filtering?
> Kind regards
> Tigran
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 1 Dec 2006, Jesper Juhl wrote:
> In my opinion the addresses should be working ones or not present at
> all (or at the very least there should be a note that the email
> address is outdated).
The above argument is not valid for entries in a revision history.
Most likely (though not necessarily), when there are multiple entries in a
revision history with different email addresses, some are going to
contain obsolete parts.
Besides, I am sure there are thousands of stale email addresses throughout
the current kernel source tree (and there have always been such) --- why
start with me? Start with the top --- Linus Torvalds :) Try finding an
obsolete email address for him in the kernel. By 2030 my turn may come :)
Kind regards
Tigran
On Sat, 2 Dec 2006 22:32:00 +0100 Adrian Bunk <[email protected]> wrote:
> as I explained with my email address as an example, email addresses
> aren't suitable for this.
I disagree. They can be very useful for tracking people down, and also
for finding information as the email address (old or otherwise) is a
great search key for info on a driver in mailing lists.
> Even the "please contact the author" and the printk() should continue to
> contain known bouncing addresses?
Possibly not.
On Sat, 2 Dec 2006, Adrian Bunk wrote:
>> The only bits that should be made sure to remain valid are the
>> MODULE_AUTHOR, as Arjan also mentioned.
>
> Even the "please contact the author" and the printk() should continue to
> contain known bouncing addresses?
Ah, I forgot about that one, but I see Alan Cox already replied and I
agree with both you and Alan on this.
Kind regards
Tigran
El Sat, 2 Dec 2006 21:42:13 +0000,
Alan <[email protected]> escribi?:
> I disagree. They can be very useful for tracking people down, and also
If their mission is to be useful, they should at least have a
"[email protected] (broken address)"
warning.