Rene Herman <[EMAIL PROTECTED]> writes:
[MODULE_AUTHOR]
> Given that the email address is all that I want to
> supress; how about just deleting that instead?
Makes sense at least WRT the "problematic" modules.
include/linux/module.h says:
/* Author, ideally of form NAME [, NAME ]*[ and NAME ]
On 04/27/2007 12:03 AM, Rene Herman wrote:
With the point you make about old installed kernel modules having
outdated information forever you've in fact convinced me that
MODULE_MAINTAINER is not a good idea.
[ ... ]
Deleting the email addresses from the MODULE_AUTHOR tag would go some
ways
Gene Heskett wrote:
> On Thursday 26 April 2007, Rene Herman wrote:
>>On 04/26/2007 09:43 PM, Adrian Bunk wrote:
>>> What exactly is missing that the kernel Bugzilla doesn't already offer?
>>
>>Users?
>
> That is the best answer of all, and I've stated my objections to that very
> nearly worthles
On 04/26/2007 10:24 PM, Adrian Bunk wrote:
The problem with such a database would be the same as with the
MAINTAINERS file: The information becomes outdated, and someone has to
maintain it.
Sending a patch against MAINTAINERS is easy - I don't see a
WWW-browseable database being in any respe
On Thursday 26 April 2007, Rene Herman wrote:
>On 04/26/2007 09:43 PM, Adrian Bunk wrote:
>> What exactly is missing that the kernel Bugzilla doesn't already offer?
>
>Users?
That is the best answer of all, and I've stated my objections to that very
nearly worthless utility before. And that is e
Adrian Bunk <[EMAIL PROTECTED]> writes:
> No, even MAINTAINERS in the latest sources always contains outdated
> entries and lacks information.
Sure, but that can't be corrected using technical meanings.
> If you think "no current sources" is a problem that should be solved,
> the solution woul
On 04/26/2007 05:52 PM, Adrian Bunk wrote:
I don't think we want to expose maintainership information to users at
all:
With the point you make about old installed kernel modules having outdated
information forever you've in fact convinced me that MODULE_MAINTAINER is
not a good idea. If I de
On Thu, Apr 26, 2007 at 11:51:29PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > The problem with such a database would be the same as with the
> > MAINTAINERS file: The information becomes outdated, and someone has to
> > maintain it.
>
> Sure, I can easily gre
Adrian Bunk <[EMAIL PROTECTED]> writes:
> The problem with such a database would be the same as with the
> MAINTAINERS file: The information becomes outdated, and someone has to
> maintain it.
Sure, I can easily grep .../linux-current/MAINTAINERS. But I think the
whole problem is with people wh
On Thu, Apr 26, 2007 at 10:02:35PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > What exactly is missing that the kernel Bugzilla doesn't already offer?
>
> Basically... unless I'm mistaken, nothing of the sort exists there.
>
> Bugzilla is a database of bugs. Wh
On 04/26/2007 09:43 PM, Adrian Bunk wrote:
What exactly is missing that the kernel Bugzilla doesn't already offer?
Users?
Rene.
-
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.or
Adrian Bunk <[EMAIL PROTECTED]> writes:
> What exactly is missing that the kernel Bugzilla doesn't already offer?
Basically... unless I'm mistaken, nothing of the sort exists there.
Bugzilla is a database of bugs. What is needed is a database of
people, mailing lists and some network resources.
On Thu, Apr 26, 2007 at 09:37:59PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>...
> > IMHO the default should be that users report problems with distribution
> > kernels to their distribution and problems with ftp.kernel.org kernels
> > to either linux-kernel or the
Adrian Bunk <[EMAIL PROTECTED]> writes:
> I don't think we want to expose maintainership information to users at
> all:
> - duplicates information in MAINTAINERS
> - maintainers sometimes disappear
> - the 3 year old kernel of your distribution would contain 3 year old
> maintainership informat
On Thu, Apr 26, 2007 at 09:44:27AM -0700, Randy Dunlap wrote:
>...
> > IMHO the default should be that users report problems with distribution
> > kernels to their distribution and problems with ftp.kernel.org kernels
> > to either linux-kernel or the kernel Bugzilla.
>
> s/linux-kernel/the appr
On 04/26/2007 06:00 PM, Alan Cox wrote:
Tie Alan to his chair and take away his keyboard while we submit patches
removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non
mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)
MODULE_AUTHOR is extremely important for l
On Thu, 26 Apr 2007 17:52:06 +0200 Adrian Bunk wrote:
> On Thu, Apr 26, 2007 at 08:41:43AM -0700, Randy Dunlap wrote:
> > On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:
> >
> > > On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > > > On 04/26/2007 03:18 AM, Andrew Morton wrot
> Tie Alan to his chair and take away his keyboard while we submit patches
> removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non
> mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)
MODULE_AUTHOR is extremely important for licensing enforcement. Removing
it sho
On Thu, Apr 26, 2007 at 08:41:43AM -0700, Randy Dunlap wrote:
> On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:
>
> > On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > > On 04/26/2007 03:18 AM, Andrew Morton wrote:
> > >
> > >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[
On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:
> On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > On 04/26/2007 03:18 AM, Andrew Morton wrote:
> >
> >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]>
> >> wrote:
> >>> Provide MODULE_MAINTAINER() as a conve
On 04/26/2007 03:54 PM, Adrian Bunk wrote:
Let me try to summarize the points:
- you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users
Yes, and the frustration of composing lengthy emails to bouncing (or worse
still, silent) email adresses is severe if you just decided to for once
On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> On 04/26/2007 03:18 AM, Andrew Morton wrote:
>
>> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]>
>> wrote:
>>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
>>> email address both for drivers
On 04/26/2007 03:18 AM, Andrew Morton wrote:
On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]>
wrote:
Provide MODULE_MAINTAINER() as a convenient place to stick a name and
email address both for drivers having multiple (current and
non-current) authors and for when someone who
On Wed, 2007-04-25 at 18:18 -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]> wrote:
>
> > Provide MODULE_MAINTAINER() as a convenient place to stick a name and email
>
> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> en
On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]> wrote:
> Provide MODULE_MAINTAINER() as a convenient place to stick a name and email
> address both for drivers having multiple (current and non-current) authors
> and for when someone who wants to maintain a driver isn't so much
On Mon, 2007-04-23 at 07:52 -0400, Robert P. J. Day wrote:
> On Mon, 23 Apr 2007, Rusty Russell wrote:
>
> > On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > > On 04/04/2007 06:38 PM, Rene Herman wrote:
> > >
> > > Rusty?
> >
> > Valid points have been made on both sides. I suggest:
> >
On Mon, 23 Apr 2007, Robert P. J. Day wrote:
> On Mon, 23 Apr 2007, Rusty Russell wrote:
>
> > On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > > On 04/04/2007 06:38 PM, Rene Herman wrote:
> > >
> > > Rusty?
> >
> > Valid points have been made on both sides. I suggest:
> >
> > #define MO
On 04/23/2007 01:52 PM, Robert P. J. Day wrote:
On Mon, 23 Apr 2007, Rusty Russell wrote:
Valid points have been made on both sides. I suggest:
#define MODULE_MAINTAINER(_maintainer) \
MODULE_AUTHOR("(Maintained by) "_maintainer)
why bring MODULE_AUTHOR into it? just define it in
On Mon, 23 Apr 2007, Rusty Russell wrote:
> On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > On 04/04/2007 06:38 PM, Rene Herman wrote:
> >
> > Rusty?
>
> Valid points have been made on both sides. I suggest:
>
> #define MODULE_MAINTAINER(_maintainer) \
> MODULE_AUTHOR("(Maintained
On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> On 04/04/2007 06:38 PM, Rene Herman wrote:
>
> Rusty?
Valid points have been made on both sides. I suggest:
#define MODULE_MAINTAINER(_maintainer) \
MODULE_AUTHOR("(Maintained by) "_maintainer)
Cheers,
Rusty.
-
To unsubscribe fr
On 04/04/2007 06:38 PM, Rene Herman wrote:
Rusty?
On 04/04/2007 06:00 PM, Alan Cox wrote:
Given that people seem to agree that authorship information has no
place in the binary, that might actually be best.
Authorship information is very useful in the binary, especially when you
have to get
Adrian Bunk wrote:
> Realistically, users should report problems with vendor kernels to the
> vendor and problems with ftp.kernel.org kernels to either linux-kernel
> or the kernel Bugzilla, and forwarding issues to the responsible people
> (if any) should be done there [1].
>
>> Rene.
>
> cu
On Wed, Apr 04, 2007 at 08:01:31PM +0200, Rene Herman wrote:
> On 04/04/2007 07:48 PM, Adrian Bunk wrote:
>
> >On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
>
> >>But in general, it would be nice to have an easy way to find a
> >>maintainer (not author) from a module binary, and I
On 04/04/2007 07:48 PM, Adrian Bunk wrote:
On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
But in general, it would be nice to have an easy way to find a
maintainer (not author) from a module binary, and I agree
MODULE_MAINTAINER can work well for such a purpose. It's no mandat
On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
> At Wed, 04 Apr 2007 18:38:42 +0200,
> Rene Herman wrote:
> >
> > Other cases-in-point; I've lately been rummaging through sound/isa a
> > bit. Nothing much copyrightable again but especially in those situations
> > where (some of th
At Wed, 04 Apr 2007 18:38:42 +0200,
Rene Herman wrote:
>
> Other cases-in-point; I've lately been rummaging through sound/isa a
> bit. Nothing much copyrightable again but especially in those situations
> where (some of the) original authors are no longer active, I do again
> want people to con
Adrian Bunk wrote:
> On Wed, Apr 04, 2007 at 06:33:06PM +0200, Stefan Richter wrote:
>> - usage problems --> get in touch with the _support_
>> - bug reports --> get in touch with _maintainers_
>
> - bug reports against vendor kernels -> get in touch with the _vendor_
> (the vendor might shi
On 04/04/2007 06:00 PM, Alan Cox wrote:
Given that people seem to agree that authorship information has no place
in the binary, that might actually be best.
Authorship information is very useful in the binary, especially when you
have to get lawyers involved in explaining things to people.
O
On Wed, Apr 04, 2007 at 06:33:06PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
> >> Given modules with multiple authors, current and non-current, I believe
> >> having "modinfo -m" tell the user whom to contact is an avantage.
Adrian Bunk wrote:
> On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
>> Given modules with multiple authors, current and non-current, I believe
>> having "modinfo -m" tell the user whom to contact is an avantage.
>
> Much bigger problems are:
> - Who will maintain this information pr
Hi Alan,
> > Given that people seem to agree that authorship information has no place
> > in the binary, that might actually be best.
>
> Authorship information is very useful in the binary, especially when you
> have to get lawyers involved in explaining things to people. Company
> business and
> Given that people seem to agree that authorship information has no place
> in the binary, that might actually be best.
Authorship information is very useful in the binary, especially when you
have to get lawyers involved in explaining things to people. Company
business and management people und
On 04/04/2007 05:02 PM, Adrian Bunk wrote:
#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages,
and it's the only actually relevant for users information we
should store.
I agree. The actual author information belong into the f
On Wed, Apr 04, 2007 at 04:48:55PM +0200, Marcel Holtmann wrote:
> Hi Christoph,
>
> > > Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> >
> > #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> > MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> > the
On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
> On 04/04/2007 02:33 PM, Christoph Hellwig wrote:
>
> >On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
>
> >>Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> >
> >#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x)
Hi Christoph,
> > Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
>
> #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> the only actually relevant for users information we should store.
I agree. The ac
On 04/04/2007 02:33 PM, Christoph Hellwig wrote:
On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages, a
On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
> Hi Rusty.
>
> Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
the only actually relevant for
On 04/04/2007 01:26 PM, Rene Herman wrote:
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
And here's the accompanying patch to the module-init-tools-3.3-pre1 as
found on http://kernel.org/pub/linux/utils/kernel/module-init-tools/
Rene.
--- module-init-tools-3.3-pre1/modinfo.c.
49 matches
Mail list logo
