lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Patchy email


From: David Kastrup
Subject: Re: [Lilypond-auto] Patchy email
Date: Wed, 18 Jul 2012 13:58:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

John Mandereau <address@hidden> writes:

> Il giorno mer, 18/07/2012 alle 09.27 +0200, David Kastrup ha scritto:
>> Well, now the accumulated mess in master is final, anyway.  I have
>> bumped staging to match it, so nothing is blocked anymore.  I am not
>> really interested in checking the consistency of all that since it
>> consists of manually messing with the results of makelsr, and I have no
>> clue about that.  It is likely to work at least until the next run of
>> makelsr.
>
> All this mess results from ignorance and "broken implementation" (I
> mean here scripts malfunction with respect to documentation) of
> policies, management of staging/master on my side and mangagement of
> snippets/makelsr on your side, and we both have an "excuse" for this
> ignorance:
>
> - makelsr does not work as advertised in
> http://lilypond.org/doc/v2.15/Documentation/contributor/adding-and-editing-snippets
> before as well as after last change to makelsr, it unconditionnally
> removes every .ly and .snippet-list files in Documentation/snippets,
> which is not what you want when you'd like to update one snippet from
> Documentation/snippets/new into Documentation/snippets without
> downloading and unpacking tarball from LSR web site.

No idea.  I mean this definitely started with me checking in a
documentation snippet that did not work on master and still got through
Patchy since I did not expect this to go untested.  I even distinctly
remember being surprised that this last-minute change worked when
rethinking it, and I might not have tested it separately (apart from
running Patchy), or with a binary that already accepted it.

For the CG, I think we can state "It may happen occasionally that the
staging branch breaks automated testing.  In this case the automatic
move of staging material to master gets halted in order to avoid broken
material entering master.  This is a safety net.  Please don't try
breaking out from it by adding fixes on top of staging: in that case the
whole sequence will end up in master after all, defeating the purpose of
the system.  The proper fix usually involves rewriting the staging
branch and is best left to core developers after discussion on the
developer list."

> - I have not found anything in the CG that says that history rewrite is
> allowed in staging in order to eliminate/squash/edit commits that break
> build, and so that you should make sure to keep your commits safe in
> your local tree until they reach master; this is a smart feature allowed
> by Patchy/staging/master system, but I realized it after your messages
> tonight; this morning I found discussions in the list archives about
> this, when I was completely idle in LilyPond development, so my next
> patch will be documenting this in the CG.

See above for a first draft.

> Sorry for bearing with my move to a more disciplined developer from a
> hybrid of pyromaniac and fireman of the build system I used to be :-P

It's not really trivial to get into LilyPond development and the
documentation is not the best.  I'd rather have people try and make
mistakes and improve the documentation for this kind of thing than
keeping new developers away even before they try.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]