Werner LEMBERG <w...@gnu.org> writes: >>>>>> PS: I'll fix the `yyout2grammar' script. >>>> >>>> Done, see >>>> >>>> https://sourceforge.net/p/testlilyissues/issues/5468/ >>> >>> So what is >>> >>> >>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=385ed0864c1be511ce16eb21751cec7fb68dd978 >>> >>> all about > > Formatting only. No change in behaviour.
And grammar and wording changes in the comments and changes from ## comments to # comments (which does not appear to make a difference to Emacs though as opposed to comments in some other languages). >>> I didn't see any email that this was pushed or had been OK'd to >>> push. > > While in general I like a conservative approach to patches, there are > situations where trivial changes like the commit in question – > essentially whitespace only, with slight reformulations of comments – > should be pushed directly to the repository. I even think that they > are not worth an e-mail to the list. Stuff that has no issue number has no history to check. There is no opportunity marking it for backporting to the stable branch. A trivial change should not lead to changes in the regtests. When there is an accident and the regtests change, it is more or less left to chance whether this is discovered before the next make test-baseline or not. If it isn't, the change will typically stick around to be discovered much much later. > In particular, I would like to see many of David K's changes > immediately pushed to `staging' – except in situations where he > actually wants comments. I don't do a whole lot of trivial changes, actually. A number of them may have some urgency. In that case I tend to shorten procedure while giving notice. In case I mess up, it can be tracked what happened and in which version it happened. > The interesting part of my changes which *do* cause a different output > are then in issue #5468, making the patch much easier to read IMHO. > > The idea behind this is to speed up development. I know of no other > project which quarantines so much trivial changes. Very often, patch > C needs patch B, which in turn needs patch A. Since Rietveld always > shows a single patch per issue, not being able to visualize a series > of commits, it's *very* time consuming to prepare issues that fit > single commits. > > I admit that unreviewed, direct commits to `staging' sometimes fail, > and I have already caused some trouble. However, reverting is rather > easy with git. You first need to find the culprit. Then you need to figure out what problem it was supposed to fix and why it wasn't flagged by the regtests. > Am I alone with this opinion? Please comment. After checking the commit this mail has been about, it appears to indeed introduce no code-relevant changes. The standard checks would have corroborated that. A notice "I pushed a formatting change to staging in preparation for this issue" would have notified the patch master. It also would have avoided the problem that he might have tried checking the second patch against an unchanged master while the first patch was still making its way through staging. Our review process and patch coddling process was developed while Graham was still in charge and it replaced a basic trust-based system where a set of core developers relied on one another to do the right thing and new developers were in significant danger of having their work dropped through the floor. This happened to me repeatedly. I did not deal gracefully with that at the time which may or may not have been a good thing. For better or worse, several people try keeping track of what happens to LilyPond. Giving notice on the mailing list even when you are not considering the full-blown procedure for a particular change of relevance is, if nothing else, a courtesy and nod to them. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel