Best way to send several patches

Best way to send several patches

[Bjarke Istrup Pedersen]

Hey,

I'm reading on the kernelnewbies wiki about janitor work needing be to done.
I have been cleaning up some stuff, and have alot of patches (I have
split my changed into smaller patches).

The question is, should I just send them all to this mailinglist
(Section 3 of Documentation/SubmittingPatches - the one with the patch
bomb - suggest that this is a bad idea), or how should I do it? (I
have only submitted a single patch before, so I didn't have to worry
about that back then).

I have been thinking about sending a pull request, but since I've only
done one patch up until now, I find it unlikely to be trusted enough
to get a pull request through (correct me if I'm wrong).

Best regards,
Bjarke

Re: Best way to send several patches

[Roland Dreier]

 > The question is, should I just send them all to this mailinglist
 > (Section 3 of Documentation/SubmittingPatches - the one with the patch
 > bomb - suggest that this is a bad idea), or how should I do it? (I
 > have only submitted a single patch before, so I didn't have to worry
 > about that back then).

I would suggest sending a small batch of patches (say, four or five at
most) and see how that goes.  That way, in case you make some mistake in
formatting or something, you don't have to send another huge pile when
you resend.

Once your initial batch is accepted and you have the hang of submitting
patches, then you can submit bigger batches.  But I would recommend
having each batch have a common theme.  For example there was the recent
series of 42 fixes for confusing if indentation -- a big batch of fixes
for the same problem in different places, which is exactly the right way
to do things.

 - Roland
-- 
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Re: Best way to send several patches

[Bjarke Istrup Pedersen]

2010/8/6 Roland Dreier <rdreier@cisco.com>:
>  > The question is, should I just send them all to this mailinglist
>  > (Section 3 of Documentation/SubmittingPatches - the one with the patch
>  > bomb - suggest that this is a bad idea), or how should I do it? (I
>  > have only submitted a single patch before, so I didn't have to worry
>  > about that back then).
>
> I would suggest sending a small batch of patches (say, four or five at
> most) and see how that goes.  That way, in case you make some mistake in
> formatting or something, you don't have to send another huge pile when
> you resend.
>
> Once your initial batch is accepted and you have the hang of submitting
> patches, then you can submit bigger batches.  But I would recommend
> having each batch have a common theme.  For example there was the recent
> series of 42 fixes for confusing if indentation -- a big batch of fixes
> for the same problem in different places, which is exactly the right way
> to do things.

Thanks, I'll do that.
But I'll wait until rc1 is out as suggested :-)

>  - Roland
> --
> Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Best way to send several patches

[Stefan Richter]

Bjarke Istrup Pedersen wrote:
> I'm reading on the kernelnewbies wiki about janitor work needing be to done.
> I have been cleaning up some stuff, and have alot of patches (I have
> split my changed into smaller patches).

Good.

> The question is, should I just send them all to this mailinglist
> (Section 3 of Documentation/SubmittingPatches - the one with the patch
> bomb - suggest that this is a bad idea), or how should I do it? (I
> have only submitted a single patch before, so I didn't have to worry
> about that back then).
> 
> I have been thinking about sending a pull request, but since I've only
> done one patch up until now, I find it unlikely to be trusted enough
> to get a pull request through (correct me if I'm wrong).

Send the patches to the respective subsystem mailinglist.  Cc the
responsible maintainer and lkml.

However, the current time is not ideal:  A merge window is open, with
code in the mainline changing quickly and maintainers being busy with
integration;  not helped by the fact that some Linux conferences are
imminent.  Consider to wait until 2.6.36-rc1 was released, then check
whether your patches are still applicable on top of 2.6.36-rc1, then
post them.
-- 
Stefan Richter
-=====-==-=- =--- --=-=
http://arcgraph.de/sr/