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

[Tom Rini <trini@konsulko.com>]

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>