Re: Emacs lilypond mode

[James Lowe]

Hello,

On Tue, 29 Jan 2019 08:07:58 +0100 (CET), Werner LEMBERG <address@hidden> wrote:

> 
> >> 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).
> 
> Yes.  `#' and `##' were mixed up without a system.  I'm curious: is
> there any other programming language besides Lisp (and its dialects)
> where such a distinction is commonly used?
> 
> >> 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.
> 
> This is something I admittedly haven't thought of.  However, it again
> points to a major weakness of Rietveld not being able to display a
> series of commits separately...
> 
> What about changing the commit message so that preliminary commits are
> explicitly mentioned?  This should ease backporting.
> 
> >> 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.
> 
> Yep.
> 
> > 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.
> 
> Hmm.  A serious question: Is this *really* necessary?  My reasoning:
> 
> (1) I've already announced publicly that I'm going to work on the
>     yyout2grammar script.  Given that `lilypond-devel' is a
>     high-traffic list, announcing such trivial commits feels like
>     posting digestion status messages on Facebook...
> 
> (2) I've waited with submitting the Rietveld issue until my
>     preliminary change was in the *master* branch – since the patch
>     master always have to start with a `git pull', there shouldn't be
>     any problem of applying Rietveld stuff for testing.  Do I miss
>     something?
> 
> > 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.
> 
> Basically, I agree.  What I want to know, however, is the
> `significance threshold' such courtesy messages should have.  

Pretty much any commit you are about to push to staging. It's as simple as that.

While I can take things like minor typos or translation pushing changes, it can 
be quite hard making sure that all issues and rietvelds are properly accounted 
for and the admin done on any tracker issues (so that the trackers can be 
verified) without having to wonder if the checkin that has just merged to 
master has an issue or not for me to follow and check that the rest of the team 
are OK with it.

Typos in doc and translations aside, even just a 'would anyone mind me making 
this change .... and pushing directly to staging' would if nothing else save me 
wasted time hunting for potential trackers that I may need to update.

>For my
> formatting stuff on the Python script, I considered it not significant
> enough.  Is there a single LilyPond developer who doesn't use the
> wonderful `gitk' tool (or one of its siblings) to check commits?

It isn't about checking what is and what is not in master, it is making sure 
that I - as someone who tests the patches fully (offers of help always welcome) 
and keeping a handle on significant patches in progress, so that developers 
don't have to care and can keep on developing.

I realise that some don't like the way we do things 
(rietveld/sourceforge/seemingly complicated patch submission process) but it 
does work, keeps developers developing, makes sure there are no suprises (more 
or less) and developersd wanting to move things up the patch process more 
quickly that others, for example when there are related issues that also need 
pushing, is not unheard of.

I don't want to start any bitterness, but just to make sure we don't slip into 
the old ways where we constantly broke staging/master or developers would get 
frustrated because their patches no longer applied for testing and needed 
rebasing.

Thanks for your understanding.

James