From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 3 May 2016 18:50:49 -0400 Subject: [U-Boot] speaking of fixing spelling mistakes and stuff like that ... In-Reply-To: References: <20160503191558.GB7884@bill-the-cat> Message-ID: <20160503225049.GH7884@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: