All of lore.kernel.org
 help / color / mirror / Atom feed
* [KJ] de-initialization of = 0 globals
@ 2005-12-13 14:01 Jaco Kroon
  2005-12-13 14:19 ` Bernd Petrovitsch
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: Jaco Kroon @ 2005-12-13 14:01 UTC (permalink / raw)
  To: kernel-janitors

Has there been decided on a standard for these?  There are approximately
800  (in just under 500 files) of these statements left in the kernel
sources.

Currently these will read something like:

static int variable_name = 0;

Are we going with

static int variable_name;

or

static int variable_name; /* =0 */

?

Also, if I'm going to be sending patches for these it's obviously a patch
per affected file, so if I'm going to be sending let's say a hundred of
these patches it's still a mail per patch or do I just archive them
somehow and attach them or do I place them on a webserver and mail a uri
to them?


-- 
There are 10 kinds of people in the world, those who understand binary,
and those who don't.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
@ 2005-12-13 14:19 ` Bernd Petrovitsch
  2005-12-13 15:16 ` Jaco Kroon
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: Bernd Petrovitsch @ 2005-12-13 14:19 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

On Tue, 2005-12-13 at 16:01 +0200, Jaco Kroon wrote:
[...]
> Also, if I'm going to be sending patches for these it's obviously a patch
> per affected file, so if I'm going to be sending let's say a hundred of
> these patches it's still a mail per patch or do I just archive them
> somehow and attach them or do I place them on a webserver and mail a uri
> to them?

Make one patch per subsystem (unless told otherwise from core LKML
personnel directly) since
-) these are trivial patches and
-) you actually want to mail them to the relevant
   maintainer/mailing-list and Cc: LKML/k-j only.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
  2005-12-13 14:19 ` Bernd Petrovitsch
@ 2005-12-13 15:16 ` Jaco Kroon
  2005-12-13 15:35 ` Bernd Petrovitsch
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: Jaco Kroon @ 2005-12-13 15:16 UTC (permalink / raw)
  To: kernel-janitors


[-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --]

Bernd Petrovitsch wrote:
> On Tue, 2005-12-13 at 16:01 +0200, Jaco Kroon wrote:
> [...]
> 
>>Also, if I'm going to be sending patches for these it's obviously a patch
>>per affected file, so if I'm going to be sending let's say a hundred of
>>these patches it's still a mail per patch or do I just archive them
>>somehow and attach them or do I place them on a webserver and mail a uri
>>to them?
> 
> 
> Make one patch per subsystem (unless told otherwise from core LKML
> personnel directly) since
> -) these are trivial patches and
> -) you actually want to mail them to the relevant
>    maintainer/mailing-list and Cc: LKML/k-j only.
> 
> 	Bernd

Ah bugger.  That makes it quite a bit more complex :(.  It's relatively
easy to single out all the cases (and fix them), but automating the
grouping of files into subsystems and assigning maintainers to those
subsystems isn't as trivial.

Thanks.

-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3166 bytes --]

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
  2005-12-13 14:19 ` Bernd Petrovitsch
  2005-12-13 15:16 ` Jaco Kroon
@ 2005-12-13 15:35 ` Bernd Petrovitsch
  2005-12-13 20:41 ` Jesper Juhl
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: Bernd Petrovitsch @ 2005-12-13 15:35 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On Tue, 2005-12-13 at 17:16 +0200, Jaco Kroon wrote:
> Bernd Petrovitsch wrote:
> > On Tue, 2005-12-13 at 16:01 +0200, Jaco Kroon wrote:
> > [...]
> > 
> >>Also, if I'm going to be sending patches for these it's obviously a patch
> >>per affected file, so if I'm going to be sending let's say a hundred of
> >>these patches it's still a mail per patch or do I just archive them
> >>somehow and attach them or do I place them on a webserver and mail a uri
> >>to them?
> > 
> > 
> > Make one patch per subsystem (unless told otherwise from core LKML
> > personnel directly) since
> > -) these are trivial patches and
> > -) you actually want to mail them to the relevant
> >    maintainer/mailing-list and Cc: LKML/k-j only.
> > 
> > 	Bernd
> 
> Ah bugger. That makes it quite a bit more complex :(.  It's relatively

Yes. But otherwise it is IMHO more "complex" (or cumbersome) for the
readers (and their will be more than only 1) getting e.g. 100 mails with
trivial fixes for 100 files or flooding some linux-<subsystem>@ ML with
12 Emails fixin such trivial stuff in 12 different files.

> easy to single out all the cases (and fix them), but automating the
> grouping of files into subsystems and assigning maintainers to those
> subsystems isn't as trivial.

I thought about proposing a new field to maintainers where the relevant
subdirectories/files listed so that one knows whom to bug if I changed a
list of given files.
But this is quite a work, ongoing since this changes and I don't know
how people react.

The simpler start is probably to generate one large patch for the Kernel
and separate patches for larger subsystems (IDE, SCSI, etc.) out of it
since you can just work with an editor.
And near the end you can send the last ones in one patch and see what
happens (in the best of all worlds, the patch is accept for -mm which
usually creates directly enough pressure so that subsystem maintainers
take it from there).

Or you just send the one large patch and see what happens.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
                   ` (2 preceding siblings ...)
  2005-12-13 15:35 ` Bernd Petrovitsch
@ 2005-12-13 20:41 ` Jesper Juhl
  2005-12-13 21:01 ` Jaco Kroon
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: Jesper Juhl @ 2005-12-13 20:41 UTC (permalink / raw)
  To: kernel-janitors

On 12/13/05, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Tue, 2005-12-13 at 17:16 +0200, Jaco Kroon wrote:
> > Bernd Petrovitsch wrote:
> > > On Tue, 2005-12-13 at 16:01 +0200, Jaco Kroon wrote:
> > > [...]
> > >
> > >>Also, if I'm going to be sending patches for these it's obviously a patch
> > >>per affected file, so if I'm going to be sending let's say a hundred of
> > >>these patches it's still a mail per patch or do I just archive them
> > >>somehow and attach them or do I place them on a webserver and mail a uri
> > >>to them?
> > >
> > >
> > > Make one patch per subsystem (unless told otherwise from core LKML
> > > personnel directly) since
> > > -) these are trivial patches and
> > > -) you actually want to mail them to the relevant
> > >    maintainer/mailing-list and Cc: LKML/k-j only.
> > >
> > >     Bernd
> >
> > Ah bugger. That makes it quite a bit more complex :(.  It's relatively
>
> Yes. But otherwise it is IMHO more "complex" (or cumbersome) for the
> readers (and their will be more than only 1) getting e.g. 100 mails with
> trivial fixes for 100 files or flooding some linux-<subsystem>@ ML with
> 12 Emails fixin such trivial stuff in 12 different files.
>
> > easy to single out all the cases (and fix them), but automating the
> > grouping of files into subsystems and assigning maintainers to those
> > subsystems isn't as trivial.
>
> I thought about proposing a new field to maintainers where the relevant
> subdirectories/files listed so that one knows whom to bug if I changed a
> list of given files.
> But this is quite a work, ongoing since this changes and I don't know
> how people react.
>
> The simpler start is probably to generate one large patch for the Kernel
> and separate patches for larger subsystems (IDE, SCSI, etc.) out of it
> since you can just work with an editor.
> And near the end you can send the last ones in one patch and see what
> happens (in the best of all worlds, the patch is accept for -mm which
> usually creates directly enough pressure so that subsystem maintainers
> take it from there).
>
> Or you just send the one large patch and see what happens.
>

Another way into the kernel for patches like this is via the Trivial
Patch Monkey (aka Adrian Bunk) - trivial@rustcorp.com.au

http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
http://lkml.org/lkml/2005/11/7/159


--
Jesper Juhl <jesper.juhl@gmail.com>
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

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
                   ` (3 preceding siblings ...)
  2005-12-13 20:41 ` Jesper Juhl
@ 2005-12-13 21:01 ` Jaco Kroon
  2005-12-13 21:43 ` Jesper Juhl
  2005-12-13 21:59 ` Jesper Juhl
  6 siblings, 0 replies; 8+ messages in thread
From: Jaco Kroon @ 2005-12-13 21:01 UTC (permalink / raw)
  To: kernel-janitors


[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]

>>The simpler start is probably to generate one large patch for the Kernel
>>and separate patches for larger subsystems (IDE, SCSI, etc.) out of it
>>since you can just work with an editor.
>>And near the end you can send the last ones in one patch and see what
>>happens (in the best of all worlds, the patch is accept for -mm which
>>usually creates directly enough pressure so that subsystem maintainers
>>take it from there).
>>
>>Or you just send the one large patch and see what happens.
> 
> Another way into the kernel for patches like this is via the Trivial
> Patch Monkey (aka Adrian Bunk) - trivial@rustcorp.com.au
> 
> http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
> http://lkml.org/lkml/2005/11/7/159

I guess that would be the way to go then.  Send one huge patch off to
trivial at rustcorp.

Should I cc LKLM and KJ?

-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3166 bytes --]

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
                   ` (4 preceding siblings ...)
  2005-12-13 21:01 ` Jaco Kroon
@ 2005-12-13 21:43 ` Jesper Juhl
  2005-12-13 21:59 ` Jesper Juhl
  6 siblings, 0 replies; 8+ messages in thread
From: Jesper Juhl @ 2005-12-13 21:43 UTC (permalink / raw)
  To: kernel-janitors

On 12/13/05, Jaco Kroon <jaco@kroon.co.za> wrote:
> >>The simpler start is probably to generate one large patch for the Kernel
> >>and separate patches for larger subsystems (IDE, SCSI, etc.) out of it
> >>since you can just work with an editor.
> >>And near the end you can send the last ones in one patch and see what
> >>happens (in the best of all worlds, the patch is accept for -mm which
> >>usually creates directly enough pressure so that subsystem maintainers
> >>take it from there).
> >>
> >>Or you just send the one large patch and see what happens.
> >
> > Another way into the kernel for patches like this is via the Trivial
> > Patch Monkey (aka Adrian Bunk) - trivial@rustcorp.com.au
> >
> > http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
> > http://lkml.org/lkml/2005/11/7/159
>
> I guess that would be the way to go then.  Send one huge patch off to
> trivial at rustcorp.
>
You can try it and if you are lucky Adrian will take it and take care
of forwarding it for you.

> Should I cc LKLM and KJ?
>
Personally I'd probably cc LKML to give other people a chance to
comment, and also, Andrew Morton is pretty good at picking up atches
like this from LKML and merging them into -mm.
Btw; if the patch is large (>50Kb or so) then you should probably not
include it in the mail, but instead put it online somewhere and
include an URL to the patch instead or split it into parts and send a
series of patches.

But in my oppinion, a much better approach (this is what I do myself
and it usually works out well) would be to make patches for each
subsystem (or each major dir in the kernel source) and then send the
patches to LKML with cc to relevant maintainers.   Yes, it takes time
to do it that way, but your success rate will probably be better and
eople are likely to respond more ositively to that than just having
one huge patch dumed on the mailing list.

Before sending a patch series like this I usually do 2 or 3 patches
for a few different areas, then send those to LKML with maintainers cc
to get some feedback on wether or not such patches are wanted at all
before I waste time doing it for the entire tree.
In this case you could do one patch for everything inside kernel/ and
another for everything inside something like drivers/usb (just icking
two random locations with different people maintaining stuff in them).
Then find out, for each file you change, who is the author of the file
(looking at comments in the top of each file is usually a good place
to start) and who is the maintainer (may be the author, may not be) -
looking in MAINTAINERS and CREDITS is usually good spots to find out.
Then mail the patches to LKML and cc the people you dug out.
In the mails you send ask for feedback on wether or not such patches
are wanted and offer to do the rest of the kernel source if they are.
Also be sure to include the following info in each mail :
 - What the patch does
 - Why the patch does what it does
 - What testing you've done (compile tested, booted a kernel with the
patch, etc)
 - A Signed-off-by line
 - diffstat -p1 output for the patch

To see an example of this in action look at my recent submission of
some pointer dereference cleanups.
Here's my initial "test the waters" mail/patch :
http://lkml.org/lkml/2005/12/6/362
And since people responded well to that I then followed up with a
series of patches that do more similar cleanup (and those patches have
recently been merged) - here are a few of them :
 http://lkml.org/lkml/2005/12/11/6
 http://lkml.org/lkml/2005/12/11/9


--
Jesper Juhl <jesper.juhl@gmail.com>
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

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [KJ] de-initialization of = 0 globals
  2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
                   ` (5 preceding siblings ...)
  2005-12-13 21:43 ` Jesper Juhl
@ 2005-12-13 21:59 ` Jesper Juhl
  6 siblings, 0 replies; 8+ messages in thread
From: Jesper Juhl @ 2005-12-13 21:59 UTC (permalink / raw)
  To: kernel-janitors

On 12/13/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 12/13/05, Jaco Kroon <jaco@kroon.co.za> wrote:
> > >>The simpler start is probably to generate one large patch for the Kernel
> > >>and separate patches for larger subsystems (IDE, SCSI, etc.) out of it
> > >>since you can just work with an editor.
> > >>And near the end you can send the last ones in one patch and see what
> > >>happens (in the best of all worlds, the patch is accept for -mm which
> > >>usually creates directly enough pressure so that subsystem maintainers
> > >>take it from there).
> > >>
> > >>Or you just send the one large patch and see what happens.
> > >
> > > Another way into the kernel for patches like this is via the Trivial
> > > Patch Monkey (aka Adrian Bunk) - trivial@rustcorp.com.au
> > >
> > > http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/
> > > http://lkml.org/lkml/2005/11/7/159
> >
> > I guess that would be the way to go then.  Send one huge patch off to
> > trivial at rustcorp.
> >
> You can try it and if you are lucky Adrian will take it and take care
> of forwarding it for you.
>
> > Should I cc LKLM and KJ?
> >
> Personally I'd probably cc LKML to give other people a chance to
> comment, and also, Andrew Morton is pretty good at picking up atches
> like this from LKML and merging them into -mm.
> Btw; if the patch is large (>50Kb or so) then you should probably not
> include it in the mail, but instead put it online somewhere and
> include an URL to the patch instead or split it into parts and send a
> series of patches.
>
> But in my oppinion, a much better approach (this is what I do myself
> and it usually works out well) would be to make patches for each
> subsystem (or each major dir in the kernel source) and then send the
> patches to LKML with cc to relevant maintainers.   Yes, it takes time
> to do it that way, but your success rate will probably be better and
> eople are likely to respond more ositively to that than just having
> one huge patch dumed on the mailing list.
>
> Before sending a patch series like this I usually do 2 or 3 patches
> for a few different areas, then send those to LKML with maintainers cc
> to get some feedback on wether or not such patches are wanted at all
> before I waste time doing it for the entire tree.
> In this case you could do one patch for everything inside kernel/ and
> another for everything inside something like drivers/usb (just icking
> two random locations with different people maintaining stuff in them).
> Then find out, for each file you change, who is the author of the file
> (looking at comments in the top of each file is usually a good place
> to start) and who is the maintainer (may be the author, may not be) -
> looking in MAINTAINERS and CREDITS is usually good spots to find out.
> Then mail the patches to LKML and cc the people you dug out.
> In the mails you send ask for feedback on wether or not such patches
> are wanted and offer to do the rest of the kernel source if they are.
> Also be sure to include the following info in each mail :
>  - What the patch does
>  - Why the patch does what it does
>  - What testing you've done (compile tested, booted a kernel with the
> patch, etc)
>  - A Signed-off-by line
>  - diffstat -p1 output for the patch
>
> To see an example of this in action look at my recent submission of
> some pointer dereference cleanups.
> Here's my initial "test the waters" mail/patch :
> http://lkml.org/lkml/2005/12/6/362
> And since people responded well to that I then followed up with a
> series of patches that do more similar cleanup (and those patches have
> recently been merged) - here are a few of them :
>  http://lkml.org/lkml/2005/12/11/6
>  http://lkml.org/lkml/2005/12/11/9
>

Forgot to mention a few nice documents I'd recommend you read :

Andrew Morton's "The perfect patch"
   http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
The "SubmittingPatches" document from Documentation/
   http://sosdg.org/~coywolf/lxr/source/Documentation/SubmittingPatches
   (do read the references linked to at the bottom of this document as well)


--
Jesper Juhl <jesper.juhl@gmail.com>
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

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-12-13 21:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-13 14:01 [KJ] de-initialization of = 0 globals Jaco Kroon
2005-12-13 14:19 ` Bernd Petrovitsch
2005-12-13 15:16 ` Jaco Kroon
2005-12-13 15:35 ` Bernd Petrovitsch
2005-12-13 20:41 ` Jesper Juhl
2005-12-13 21:01 ` Jaco Kroon
2005-12-13 21:43 ` Jesper Juhl
2005-12-13 21:59 ` Jesper Juhl

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.