* Submitting patches question
@ 2014-12-08 21:05 Dean Michael Ancajas
2014-12-08 21:16 ` Paul Bolle
2014-12-08 21:24 ` Valdis.Kletnieks at vt.edu
0 siblings, 2 replies; 3+ messages in thread
From: Dean Michael Ancajas @ 2014-12-08 21:05 UTC (permalink / raw)
To: kernelnewbies
Hi,
I have submitted single line patches. I was wondering what is the
policy on the # of changes per patch? For instance the code below:
if (Index) {
data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAL);
} else {
data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAH);
}
the braces are not necessary according to the rules. Should I
A. submit 1 patch for the "if" portion and another for the "else" on
separate emails (i.e. two patches on separate emails)?
B. 1 patch for the whole thing (considering this is trivial change) ?
C. 2 separate patches but in 1-email only?
Thanks
^ permalink raw reply [flat|nested] 3+ messages in thread* Submitting patches question
2014-12-08 21:05 Submitting patches question Dean Michael Ancajas
@ 2014-12-08 21:16 ` Paul Bolle
2014-12-08 21:24 ` Valdis.Kletnieks at vt.edu
1 sibling, 0 replies; 3+ messages in thread
From: Paul Bolle @ 2014-12-08 21:16 UTC (permalink / raw)
To: kernelnewbies
On Mon, 2014-12-08 at 14:05 -0700, Dean Michael Ancajas wrote:
> Hi,
> I have submitted single line patches. I was wondering what is the
> policy on the # of changes per patch? For instance the code below:
>
> if (Index) {
> data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAL);
> } else {
> data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAH);
> }
>
> the braces are not necessary according to the rules. Should I
>
> A. submit 1 patch for the "if" portion and another for the "else" on
> separate emails (i.e. two patches on separate emails)?
>
> B. 1 patch for the whole thing (considering this is trivial change) ?
>
> C. 2 separate patches but in 1-email only?
B.
Good luck,
Paul Bolle
^ permalink raw reply [flat|nested] 3+ messages in thread* Submitting patches question
2014-12-08 21:05 Submitting patches question Dean Michael Ancajas
2014-12-08 21:16 ` Paul Bolle
@ 2014-12-08 21:24 ` Valdis.Kletnieks at vt.edu
1 sibling, 0 replies; 3+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2014-12-08 21:24 UTC (permalink / raw)
To: kernelnewbies
On Mon, 08 Dec 2014 14:05:45 -0700, Dean Michael Ancajas said:
> Hi,
> I have submitted single line patches. I was wondering what is the
> policy on the # of changes per patch? For instance the code below:
>
> if (Index) {
> data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAL);
> } else {
> data = ft1000_read_reg(dev, FT1000_REG_MAG_DPDATAH);
> }
>
> the braces are not necessary according to the rules. Should I
>
> A. submit 1 patch for the "if" portion and another for the "else" on
> separate emails (i.e. two patches on separate emails)?
>
> B. 1 patch for the whole thing (considering this is trivial change) ?
>
> C. 2 separate patches but in 1-email only?
The general rule is "one patch for one thing". In this case, "one thing"
would be "fix braces" across an entire .c file (which meant that if there were
5 or 10 "if" statements that needed fixing in foo.c, you'd submit one patch
that fixed all of them. But a patch that fixed leading tabs/blanks issues or
too-long line issues would be a separate patch.
So you'd want (B).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141208/213ebcf1/attachment.bin
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-08 21:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-08 21:05 Submitting patches question Dean Michael Ancajas
2014-12-08 21:16 ` Paul Bolle
2014-12-08 21:24 ` Valdis.Kletnieks at vt.edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).