[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[Robert P. J. Day]

  as i dig through the u-boot code, i frequently run across spelling
mistakes and other apparently non-functional issues, but i don't want
to pollute the list with patch after patch of trivial fixups, so i
started a local git branch called "typos" to which i add these things
and, eventually, i'll just send it in as one big patch, which inspires
two questions.

  first, is it still considered bad form to submit patches which might
touch numerous subsystems all over the code base? certainly, actual
functional changes shouldn't do that, but what about aesthetic fixes?
is it still necessary to CC each subsystem maintainer affected if
there are, like, a dozen of them? (whenever i find a particular typo,
i do a code-wide grep to nail all of them and add all of them to the
typos branch, so i could find them all over the place.) what to do?

  and second, is it worth (like the kernel folks do) adding a
"trivial" branch (in kernel case, email "trivial at kernel.org"), which
could collect trivial things like this off to the side, and eventually
just add it all as one big patch?

  i'm happy to send in typo fixes, but i have no interest in
generating all that churn if there's a better way.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[Tom Rini]

On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote:

>   as i dig through the u-boot code, i frequently run across spelling
> mistakes and other apparently non-functional issues, but i don't want
> to pollute the list with patch after patch of trivial fixups, so i
> started a local git branch called "typos" to which i add these things
> and, eventually, i'll just send it in as one big patch, which inspires
> two questions.
> 
>   first, is it still considered bad form to submit patches which might
> touch numerous subsystems all over the code base? certainly, actual
> functional changes shouldn't do that, but what about aesthetic fixes?
> is it still necessary to CC each subsystem maintainer affected if
> there are, like, a dozen of them? (whenever i find a particular typo,
> i do a code-wide grep to nail all of them and add all of them to the
> typos branch, so i could find them all over the place.) what to do?
> 
>   and second, is it worth (like the kernel folks do) adding a
> "trivial" branch (in kernel case, email "trivial at kernel.org"), which
> could collect trivial things like this off to the side, and eventually
> just add it all as one big patch?
> 
>   i'm happy to send in typo fixes, but i have no interest in
> generating all that churn if there's a better way.

In my mind, the best time to submit a whole bunch of just typo fixes
(esp that do not change a CONFIG name/value) is in the last two weeks
before the release.  Why?  Because I'm not going to take any other big
changes in so these aren't going to possibly conflict with what other
people are doing.  Other people doing big series changes inside of git
for the next release should be able to pull these changes in and have
git figure out the right thing.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160503/3ab400b2/attachment.sig>

[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[Robert P. J. Day]

On Tue, 3 May 2016, Tom Rini wrote:

> On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote:
>
> >   as i dig through the u-boot code, i frequently run across spelling
> > mistakes and other apparently non-functional issues, but i don't want
> > to pollute the list with patch after patch of trivial fixups, so i
> > started a local git branch called "typos" to which i add these things
> > and, eventually, i'll just send it in as one big patch, which inspires
> > two questions.
> >
> >   first, is it still considered bad form to submit patches which might
> > touch numerous subsystems all over the code base? certainly, actual
> > functional changes shouldn't do that, but what about aesthetic fixes?
> > is it still necessary to CC each subsystem maintainer affected if
> > there are, like, a dozen of them? (whenever i find a particular typo,
> > i do a code-wide grep to nail all of them and add all of them to the
> > typos branch, so i could find them all over the place.) what to do?
> >
> >   and second, is it worth (like the kernel folks do) adding a
> > "trivial" branch (in kernel case, email "trivial at kernel.org"), which
> > could collect trivial things like this off to the side, and eventually
> > just add it all as one big patch?
> >
> >   i'm happy to send in typo fixes, but i have no interest in
> > generating all that churn if there's a better way.
>
> In my mind, the best time to submit a whole bunch of just typo fixes
> (esp that do not change a CONFIG name/value) is in the last two
> weeks before the release.  Why?  Because I'm not going to take any
> other big changes in so these aren't going to possibly conflict with
> what other people are doing.  Other people doing big series changes
> inside of git for the next release should be able to pull these
> changes in and have git figure out the right thing.

  sounds reasonable ... i'll keep tabs on the schedule and try to
remember to send them all in during that window. i've already got a
collection.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[Tom Rini]

On Tue, May 03, 2016 at 06:47:02PM -0400, Robert P. J. Day wrote:
> On Tue, 3 May 2016, Tom Rini wrote:
> 
> > On Tue, May 03, 2016 at 06:17:08AM -0400, Robert P. J. Day wrote:
> >
> > >   as i dig through the u-boot code, i frequently run across spelling
> > > mistakes and other apparently non-functional issues, but i don't want
> > > to pollute the list with patch after patch of trivial fixups, so i
> > > started a local git branch called "typos" to which i add these things
> > > and, eventually, i'll just send it in as one big patch, which inspires
> > > two questions.
> > >
> > >   first, is it still considered bad form to submit patches which might
> > > touch numerous subsystems all over the code base? certainly, actual
> > > functional changes shouldn't do that, but what about aesthetic fixes?
> > > is it still necessary to CC each subsystem maintainer affected if
> > > there are, like, a dozen of them? (whenever i find a particular typo,
> > > i do a code-wide grep to nail all of them and add all of them to the
> > > typos branch, so i could find them all over the place.) what to do?
> > >
> > >   and second, is it worth (like the kernel folks do) adding a
> > > "trivial" branch (in kernel case, email "trivial at kernel.org"), which
> > > could collect trivial things like this off to the side, and eventually
> > > just add it all as one big patch?
> > >
> > >   i'm happy to send in typo fixes, but i have no interest in
> > > generating all that churn if there's a better way.
> >
> > In my mind, the best time to submit a whole bunch of just typo fixes
> > (esp that do not change a CONFIG name/value) is in the last two
> > weeks before the release.  Why?  Because I'm not going to take any
> > other big changes in so these aren't going to possibly conflict with
> > what other people are doing.  Other people doing big series changes
> > inside of git for the next release should be able to pull these
> > changes in and have git figure out the right thing.
> 
>   sounds reasonable ... i'll keep tabs on the schedule and try to
> remember to send them all in during that window. i've already got a
> collection.

"today" is the day, next Monday is release :)  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160503/4fb342b0/attachment.sig>

[U-Boot] speaking of fixing spelling mistakes and stuff like that ...

[Robert P. J. Day]

On Tue, 3 May 2016, Tom Rini wrote:

> On Tue, May 03, 2016 at 06:47:02PM -0400, Robert P. J. Day wrote:
> >
> >   sounds reasonable ... i'll keep tabs on the schedule and try to
> > remember to send them all in during that window. i've already got a
> > collection.
>
> "today" is the day, next Monday is release :)  Thanks!

  ack ... early tomorrow morning. promise.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================