U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Robert P. J. Day <rpjday@crashcourse.ca>
To: u-boot@lists.denx.de
Subject: [U-Boot] speaking of fixing spelling mistakes and stuff like that ...
Date: Tue, 3 May 2016 18:47:02 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.20.1605031845480.15079@localhost.localdomain> (raw)
In-Reply-To: <20160503191558.GB7884@bill-the-cat>

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
========================================================================

  reply	other threads:[~2016-05-03 22:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-03 10:17 [U-Boot] speaking of fixing spelling mistakes and stuff like that Robert P. J. Day
2016-05-03 19:15 ` Tom Rini
2016-05-03 22:47   ` Robert P. J. Day [this message]
2016-05-03 22:50     ` Tom Rini
2016-05-03 23:22       ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.20.1605031845480.15079@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox