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
