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 ]
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 EMAIL[, NAME EMAIL]*[ and
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
st and personal e-mail. Also, "my" subsystem (ieee1394) almost
doesn't have to deal anymore with new development, neither on the kernel
side nor as far as available hardware is concerned. Therefore my
findings certainly do not reflect what other subsystem maintainers are
facing.
Back to MO
, neither on the kernel
side nor as far as available hardware is concerned. Therefore my
findings certainly do not reflect what other subsystem maintainers are
facing.
Back to MODULE_MAINTAINER and what Adrian said about where to report bugs:
From the maintainer's point of view, my personal
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
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
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
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
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
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
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
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.
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
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
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
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
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
n 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
> > &
> 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.
on, 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
> > >>>
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]>
> >>
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
&
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 s
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 ./M
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
end up
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 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 having
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, 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 convenient place
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 an author.
[ snip ]
I'm not sure we want to do
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
:
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
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
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 appropriate
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 information
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 kernel
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 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
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. What is
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 who
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 grep
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
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 would
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
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
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
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
lid 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 terms of
> MODULE_INFO:
Because author is an
een 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 terms of
> MODULE_INFO:
>
> #define MODULE_MAINTAINE
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? j
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(_ma
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.
"which one
of the three people listed here is maintaining this" is yet another.
MODULE_AUTHOR may be approximately right but especially with old drivers
it also has little relation with who's maintaining the thing.
If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER plea
of the three people listed here is maintaining this is yet another.
MODULE_AUTHOR may be approximately right but especially with old drivers
it also has little relation with who's maintaining the thing.
If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It
doesn't need to be added
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 from
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 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
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 MODULE_MAINTAINER
MODULE_MAINTAINER(_maintainer) \
MODULE_AUTHOR((Maintained by) _maintainer)
why bring MODULE_AUTHOR into it? just define it in terms of
MODULE_INFO:
Because author is an established field. People might well search for
it. This is fairly clear, and assuming that the maintainer has actually
done
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
(not author) from a module binary, and I agree
> >>MODULE_MAINTAINER can work well for such a purpose. It's no mandatory
> >>field, but could be some help.
> >
> >Yes, it would be nice.
> >
> >But would this information always be kept up-to-date for the whol
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
go through subsystem maintainers to
> specific person (you) in such a case, as the tree is still more or
> less maintained by subsystem maintainers.
>
> 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
> MO
less maintained by subsystem maintainers.
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 mandatory
field, but could be some help.
Takashi
-
To unsubscribe from this list
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
is maintaining this" is yet another.
MODULE_AUTHOR may be approximately right but especially with old drivers
it also has little relation with who's maintaining the thing.
If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It
doesn't need to be added to drivers directly, it can j
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
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
> 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
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
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 maintain
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
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 shou
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
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
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
Hi Rusty.
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
Often a module grows multiple authors over time, but initial authors
aren't around (or too interested) anymore. And sometimes, if someone
maintaining a driver is just doing minor peripheral updates to keep it
compiling
Hi Rusty.
Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
Often a module grows multiple authors over time, but initial authors
aren't around (or too interested) anymore. And sometimes, if someone
maintaining a driver is just doing minor peripheral updates to keep it
compiling
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
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
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
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 actual
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), please
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 only
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
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
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
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 properly?
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.
Much
this is yet another.
MODULE_AUTHOR may be approximately right but especially with old drivers
it also has little relation with who's maintaining the thing.
If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It
doesn't need to be added to drivers directly, it can just grow (and
being
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 ship a
.
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 mandatory
field, but could be some help.
Takashi
-
To unsubscribe from this list: send the line unsubscribe linux
, as the tree is still more or
less maintained by subsystem maintainers.
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 mandatory
field, but could be some help
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
MODULE_MAINTAINER can work well for such a purpose. It's no mandatory
field, but could be some help.
Yes, it would be nice.
But would this information always be kept up-to-date for the whole tree?
I don't see this happen.
I believe it would largely stay up to date yes. The tag wouldn't
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
Adrian
100 matches
Mail list logo
