What is holding up 2.20 release?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What is holding up 2.20 release?

Carl Sorensen-3
Dear Team,

It seems to me like we are pretty much in shape such that we should release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release, even if there are some critical regressions.  2.19.83 is SO much better than 2.18.2.

IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick some patches.  Is that correct?

I'd really like to see us get something out as 2.20 by the first of the year.  What can I do to help?

Thanks,

Carl


dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
Carl Sorensen <[hidden email]> writes:

> Dear Team,
>
> It seems to me like we are pretty much in shape such that we should
> release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
> even if there are some critical regressions.  2.19.83 is SO much
> better than 2.18.2.
>
> IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
> some patches.  Is that correct?

And putting out a new prerelease to be sure that those are ok, and
waiting for the translators to catch up with cherry-picked patches
containing stuff to be translated.

But the current roadblock is David K. cherry-picking some patches.  Here
is a remaining list (not completely up to date with current master,
though not missing much) to check for possible inclusion (assuming I
have not overlooked something important pickable in the sequence
before).  If you see something important here (or something not in
current master), put in a word for it.

ef2cc5e684 Issue 5471/1: relocate.cc: Add `indent' parameter to `sane_putenv'
d6428b77b6 Issue 5471/2: main.cc, relocate.cc: Improve relocation debug messages
19da23977f Issue 5471/3: relocate.cc: Don't use double forward slashes in file names
88980c4f92 Fix #5474: progerror when creating an undefined grob
0f5c046811 Functions to invert chords or drop/rise chord notes
6f1cf6c2b5 Add regtest for chord inversions and voicings
ddef2aa7b6 Issue 5472/1: yaffut.hh: Fix compilation warning
e37310a8e9 Issue 5472/2: flower/file-name.cc: Fix canonical file name representation
3bd7050543 Issue 5468: yyout2grammar.py: Various fixes
0deb785f64 Update texinfo.tex from Texinfo git master branch
cb1963c46a Web: update online editors section.
965a607096 Fix #1367: NoteNames context in any language
ed86e71eb0 Use "simple strings" rather than #"hash-prefixed Scheme strings"
3aeb41c27f Command line help: -o option takes either FILE or FOLDER as arg.
e94db23e6c C++ cleanup : get rid of some compilation warnings
804faebc79 Issue 5481/1: main.cc, relocate.cc: Minor code clean-up
7200d7365b Issue 5481/2: running.itely: Document relocation
e9c082d4d4 Issue 5481/3: flower/file-name.cc: Better handling of `.' and `..'
f0c3e7461e Issue 5481/4: relocate.cc: Rewrite relocation algorithm
5eb848b59b Issue 5484: set doubleRepeatType fallback to default
b05de1da2a pitches.itely: Fix typos and improve look of accidental name tables.
dceebb052f Website: use VERSION_DEVEL rather than MAJOR.MINOR
5eb392ddd5 Issue 5485: avoid -Wsequence-point warning
cdfb8f3fd3 Do not build PDFs from the website Texinfo sources - issue 5482
3ba581df6a Issue 5490: fix for wrong clefs.varC_change
2afb45bd85 Issue 5489/1: improve prall glyphs
56942ccc5f Issue 5489/2: rename trilelement → trillelement
1284c743b0 Issue 5487/1: add very short and Henze fermatas
77b98cbbc6 Issue 5487/2: add new fermatas to Changes doc
5a88042cc8 Scripts: Removed references to gmane
879f5b1da5 Doc: NR 4.2.2 - remove deprecated @knownissue
a99f7f83c8 Doc: Usage - Invoking Musicxml2ly - add missing switches
19677c83b0 Makelsr.py run for previous commits
464cf0d811 Fix #687: Include MIDI swing script in default distribution
13dc8b9c72 Issue 5498: Revert "Merge branch 'issue4914'"
a39c23d554 Release: bump VERSION_DEVEL.
941dfa8bed Release: update news.
54de6a24c5 Release: bump Welcome versions.
1b1b06dbc7 NR: Document usage of \change at beginning of staff.
45dedd482d Add warning message for unknown code in fret-diagram-verbose
6508284378 Clean up problems with fret-diagram-terse markups
0e6f55bb17 Change hardcoded pair to cons call for return -- remove ugh comment
64a61d9b5d Doc: extending: Fix after-line-breaking example.
c05184b3ff CG: Typo for British and American English locales
c415cb98c3 Issue 5502: NR: Add many function index entries
e0d597aed3 Typo in \oval docstring
0f047e3514 Fix German quarter tone pitch names.
f3d46cd65d Fix commit b05de1da2abe0a6d3e0eac8202ea45ba41ff47df.
9c0e1363ac Issue #5506: Add tremolo stem support to \cueDuring
9d9dc55729 Issue 5501: Avoid failed assertion in stem tremolo code
3008803555 Doc: NR added @knownissue re midi block with polymetric notation
db818c1220 ly: Adding turkish-makam.ly
f4e30857e1 Doc: Usage - Better description of -dcrop in Usage chapter 1.2
a7ef349f29 Doc: LM + NR - Typos \addlyrics and \lyricmode
ed0212b1dc Doc: Internals - clarify stem-length is in half staff space units
03f78e3e7b Doc: NR - 2.10.2 - Arabic Music - improved example
c511518a4e makelsr run for previous commit
d0730c389d Issue 5510 Add doc-string for allowVoltaHook
bd05971b2a Issue 5509 Reflect new syntax in example of define-grob-properties.scm
6ecee87252 Minor NR corrections.
8d7c176b45 Issue 5511/1: add articulation support to MMRs
4424b153c0 Issue 5511/2: deprecate \fermataMarkup
453fa92e43 Issue 5511/3: update regression tests
200658ca20 Issue 5511/4: doc: NR and Changes
59284fa692 Issue 5511/5: doc: Update translated docs
e8ad7f0c78 Minor.
ab8e7e4d89 Issue 5513: Avoid some crashes for bad "control-points" property
ff348fa75a Issue 5486/1: add very short/Henze fermata commands
c9286e87ee Issue 5486/2: add fermata commands to NR
a33f922e0f Pondings: fixed URL for Ben Lemon
bc46cc1fef Documentation: elaborate NR `custom percussion’ section
29c5443642 Issue 5519/1: Give NoteNames context an \alias Staff
f669227b46 Issue 5519/2: fix regtest accidental-voice
cfee7a3a26 Issue 5518 Document bound-details (sub-)properties in line-spanner-cc for IR
a53d6523dc lily/GNUmakefile: `sources.o' depends on `parser.hh'
e71c3c2725 Issue 5523: add `-Wno-sequence-point' to g++ CFLAGS for Guile 1.8
1272e45b49 Issue 5526 Add ly version to swing.ly
f9fe10bde4 Doc: NR - 2.10 World Music Turkish Classical additions
77b2c39186 Makelsr for previous commit
2513916bed Web: 'Productions' - introduction.itexi additions and corrections
0e1eeb7838 aclocal.m4: Whitespace and formatting.
bc4f5fdc29 Add glib-2.0 and gobject-2.0 library dependency
4cc884ee09 ly: turkish-makam.ly - minor edit to sultaniyegah
189cfb95ea Doc: NR 2.9 Ancient Notation - add verbatim to @lilypond example for custodes
00b4c4c757 Doc: NR - expressive.itely - accidentals for naturals using pitched trills
03f4723afc Issue 5520/1: Improvements to \ambitusAfter
2b52bc2bf1 Issue 5520/2: add \ambitusAfter to Changes
17d3d3a151 Issue 4362/1: head completion uses dotted breves
49f41bf1c6 Issue 4362/2: add regtest
47f74e11cf Doc: Use new syntax throughout all doc and examples
1d4717d0db NR: 2.10 Arabic Music - inlcude references to hel-arabic.ly
7ecc24c5e8 Issue #5524 New function css-color (accompanying x11-color)
53739c0ae6 Issue 5303 - Misplaced Notehead
3300acdd8d Issue 5532/1: \ottava doesn’t confuse ambitus
04a0052411 Issue 5532/2: add regtest
c5f63d33bf Add tex/txi-pt.tex
77b816a48f Issue 5535: Build logging: Improve METAFONT tracing
7583351fbf Optimize tree.gittxt messages
ebc35cb7b6 web:development: Make Release Numbers more current
34a114b835 Revert "Optimize tree.gittxt messages"
b62d62e402 Optimize tree.gittxt messages (v 2)
39c9d91c46 Fix relocate-preamble.py bug
a77f387207 Fix musicxml2ly.py / Python 2.4.5 incompatibility
3f0b5c61a7 Issue 5541: treat CENTER in Side_position_interface::aligned_side
42c45c5dfc Web: update old links to Ben Lemon tutorials
cf600cc6f8 mf/README: Describe creation of Emmentaler fonts.
6b789abd46 ly: hel-arabic - comment out Sahnaz entry
2165edafc5 Issue 5551/1: better indexing support
1eed54e8ff Issue 5551/2: improve generated documentation
714792a1eb Issue 5552/1: HOWTO.index: new guide for creating index entries
b2799c1823 Issue 5552/2: NR: complete revision of all index entries
227fac3a04 We now need texinfo 6.1 or newer.
e926c294e3 Issue 5553: fix handling of @lilypond[verbatim]
89036755a7 Replace code.google.com by SourceForge
805e6ef94c bach-schenker.ly: Completely revised.
be39d353b7 Rename `Stockhausen_Klavierstueck2' to `stockhausen-klavierstueckII'.
a6f8381ea4 stockhausen-klavierstueckII: Completely rewritten.
1d3105fce4 run-and-check: Show output directory in case of error.
0457814df4 string-tunings-init: Fix typo in Banjo tuning.
4402d6c545 Issue 5555/1: reorder checks in add_post_events for efficiency
eed07c3e54 Issue 5555/2: add_post_events: check for time-scaled-music explicitly
ab3b23941f Issue 5555/3: TimeScaledMusic should not be music-wrapper-music
c2b424f9f8 Remove old make-countdown-announcement.sh
71c4990e47 run-and-check: Display correct log file directory.
9bef63308f Issue 5557: Remove spurious '% begin verbatim' in Documentation/snippets/new
1d255547ba Run scripts/auxiliar/makelsr.py
3064ac9d3d Issue 5558/1: NR: add many index entries for snippets
7930d8777e Issue 5558/2: NR: various minor corrections
09bc2e2ed7 Issue 5560: remove script-chart.ly
2c2908c905 Issue 5563: make edges of brackets dashable
7e6a956625 Issue 5561/5562: slurs work without NoteHead stencil
476194c706 Issue 5559/1: Add user-definable ottava markups
608aa55988 Issue 5559/2: add regtest
6f319a862d Issue 5556/3: make OttavaBracket text default bold
2f1649830b Issue 5559/4: fix regression (ambitus with ottava)
d9555cda14 Issue 5565: simplify python-related makefiles
c95d96aa71 Typo.
058c7347c1 granados.ly: Improved and updated.
5674d4570d NR: add snippet to describe `NoteCollision.prefer-dotted-right'
b7532cf6e6 Issue 5568: make build output terse by default
cd11e1d06e Update python headers to match surrounding files
fa6c70e39a Issue 5567: allow slurs instead of brackets with tuplets
a6a6f019a9 Fix header variables from musicxml2ly on Windows
2d45d5247e Drop requirement for python-devel
75b16466ef Issue 5564: fix conversion warnings in beaming code
8ba40d3d69 Issue 5571: streamline cat | sed | sed
0c0a07a6d7 Issue #5574: freetype.cc: fix compiler warnings
0d7744aad0 Issue 5572/1: Compile modified C++ files automatically before testing
73aaa6d299 Issue 5572/2: Contributor's Guide updates
306fc6b509 Issue 5576: make output-distance less verbose by default
ad3effb756 Check additional names for guile-config
dbe42f9940 Issue 5583: www_post.py: don't mirror regtest baseline
014ec06a9f python: replace <> with !=
911788f173 Issue 5578: add a button to flip between old and new regtest images
2823ff0e87 Issue 5579: fix stem tremolo on rests crash
3903d2efc7 Issue 5577: scripts/build: Remove unused scripts


> I'd really like to see us get something out as 2.20 by the first of
> the year.  What can I do to help?
>
> Thanks,
>
> Carl
> 
>

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Carl Sorensen-3


On 11/16/19, 1:52 PM, "David Kastrup" <[hidden email]> wrote:

    Carl Sorensen <[hidden email]> writes:
   
    > Dear Team,
    >
    > It seems to me like we are pretty much in shape such that we should
    > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
    > even if there are some critical regressions.  2.19.83 is SO much
    > better than 2.18.2.
    >
    > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
    > some patches.  Is that correct?
   
    And putting out a new prerelease to be sure that those are ok, and
    waiting for the translators to catch up with cherry-picked patches
    containing stuff to be translated.
   
    But the current roadblock is David K. cherry-picking some patches.  

Is the reason for cherry-picking such a big list of patches to avoid some regressions?  Or are these patches that were created after we put out the last pre-release?

Would you like me to try doing the cherry-picking for you?

Carl
   

dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
Carl Sorensen <[hidden email]> writes:

> On 11/16/19, 1:52 PM, "David Kastrup" <[hidden email]> wrote:
>
>     Carl Sorensen <[hidden email]> writes:
>    
>     > Dear Team,
>     >
>     > It seems to me like we are pretty much in shape such that we should
>     > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
>     > even if there are some critical regressions.  2.19.83 is SO much
>     > better than 2.18.2.
>     >
>     > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
>     > some patches.  Is that correct?
>    
>     And putting out a new prerelease to be sure that those are ok, and
>     waiting for the translators to catch up with cherry-picked patches
>     containing stuff to be translated.
>    
>     But the current roadblock is David K. cherry-picking some patches.  
>
> Is the reason for cherry-picking such a big list of patches to avoid
> some regressions?

THIS IS NOT A LIST FOR CHERRY-PICKING!!!!  It is a unculled list of
potential candidates that _may_ need or want to be cherry-picked, in
case a particular candidate is

either
a) fixing a regression
b) fixing a problem that will foreseeably cause trouble with near-future
or our current build systems
c) fixing a problem or providing a feature that will foreseeably cause
frequent tension between 2.20 and 2.21 users if not cherry-picked
d) a definite improvement that does not show potential for causing new
regressions
e) a documentation fix/change matching 2.20 behavior

and/or/maybe
a) cherry-picks reasonably painlessly
b) does not cause significant followup tasks to be also scheduled

> Or are these patches that were created after we put out the last
> pre-release?

Minus those I already cherry-picked

> Would you like me to try doing the cherry-picking for you?

If anybody tries indiscriminately picking that list, I am going to be
pissed.  The majority of those patches likely has no place in 2.20.

--
David Kastrup

dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
David Kastrup <[hidden email]> writes:

> Carl Sorensen <[hidden email]> writes:
>
>> On 11/16/19, 1:52 PM, "David Kastrup" <[hidden email]> wrote:
>>
>>     Carl Sorensen <[hidden email]> writes:
>>    
>>     > Dear Team,
>>     >
>>     > It seems to me like we are pretty much in shape such that we should
>>     > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
>>     > even if there are some critical regressions.  2.19.83 is SO much
>>     > better than 2.18.2.
>>     >
>>     > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
>>     > some patches.  Is that correct?
>>    
>>     And putting out a new prerelease to be sure that those are ok, and
>>     waiting for the translators to catch up with cherry-picked patches
>>     containing stuff to be translated.
>>    
>>     But the current roadblock is David K. cherry-picking some patches.  
>>
>> Is the reason for cherry-picking such a big list of patches to avoid
>> some regressions?
>
> THIS IS NOT A LIST FOR CHERRY-PICKING!!!!  It is a unculled list of
> potential candidates that _may_ need or want to be cherry-picked, in
> case a particular candidate is
>
> either
> a) fixing a regression
> b) fixing a problem that will foreseeably cause trouble with near-future
> or our current build systems
> c) fixing a problem or providing a feature that will foreseeably cause
> frequent tension between 2.20 and 2.21 users if not cherry-picked
> d) a definite improvement that does not show potential for causing new
> regressions
> e) a documentation fix/change matching 2.20 behavior
>
> and/or/maybe
> a) cherry-picks reasonably painlessly
> b) does not cause significant followup tasks to be also scheduled
>
>> Or are these patches that were created after we put out the last
>> pre-release?
>
> Minus those I already cherry-picked

or already considered unfit for picking, based on seeing patches
succeeding them already getting picked.

>
>> Would you like me to try doing the cherry-picking for you?
>
> If anybody tries indiscriminately picking that list, I am going to be
> pissed.  The majority of those patches likely has no place in 2.20.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Carl Sorensen-3
In reply to this post by dak


On 11/16/19, 2:14 PM, "David Kastrup" <[hidden email]> wrote:

    Carl Sorensen <[hidden email]> writes:
   
    > On 11/16/19, 1:52 PM, "David Kastrup" <[hidden email]> wrote:
    >
    >     Carl Sorensen <[hidden email]> writes:
    >    
    >     > Dear Team,
    >     >
    >     > It seems to me like we are pretty much in shape such that we should
    >     > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
    >     > even if there are some critical regressions.  2.19.83 is SO much
    >     > better than 2.18.2.
    >     >
    >     > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
    >     > some patches.  Is that correct?
    >    
    >     And putting out a new prerelease to be sure that those are ok, and
    >     waiting for the translators to catch up with cherry-picked patches
    >     containing stuff to be translated.
    >    
    >     But the current roadblock is David K. cherry-picking some patches.  
    >
    > Is the reason for cherry-picking such a big list of patches to avoid
    > some regressions?
   
    THIS IS NOT A LIST FOR CHERRY-PICKING!!!!  It is a unculled list of
    potential candidates that _may_ need or want to be cherry-picked, in
    case a particular candidate is
   
    either
    a) fixing a regression
    b) fixing a problem that will foreseeably cause trouble with near-future
    or our current build systems
    c) fixing a problem or providing a feature that will foreseeably cause
    frequent tension between 2.20 and 2.21 users if not cherry-picked
    d) a definite improvement that does not show potential for causing new
    regressions
    e) a documentation fix/change matching 2.20 behavior
   
    and/or/maybe
    a) cherry-picks reasonably painlessly
    b) does not cause significant followup tasks to be also scheduled
   
    > Or are these patches that were created after we put out the last
    > pre-release?
   
    Minus those I already cherry-picked
   
    > Would you like me to try doing the cherry-picking for you?
   
    If anybody tries indiscriminately picking that list, I am going to be
    pissed.  The majority of those patches likely has no place in 2.20.

OK, I will not do any cherry-picking.

Is there anything else that can be done to help?

Carl
   

dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
Carl Sorensen <[hidden email]> writes:

> On 11/16/19, 2:14 PM, "David Kastrup" <[hidden email]> wrote:
>
>     Carl Sorensen <[hidden email]> writes:
>    
>     > On 11/16/19, 1:52 PM, "David Kastrup" <[hidden email]> wrote:
>     >
>     >     Carl Sorensen <[hidden email]> writes:
>     >    
>     >     > Dear Team,
>     >     >
>     >     > It seems to me like we are pretty much in shape such that we should
>     >     > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
>     >     > even if there are some critical regressions.  2.19.83 is SO much
>     >     > better than 2.18.2.
>     >     >
>     >     > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
>     >     > some patches.  Is that correct?
>     >    
>     >     And putting out a new prerelease to be sure that those are ok, and
>     >     waiting for the translators to catch up with cherry-picked patches
>     >     containing stuff to be translated.
>     >    
>     >     But the current roadblock is David K. cherry-picking some patches.  
>     >
>     > Is the reason for cherry-picking such a big list of patches to avoid
>     > some regressions?
>    
>     THIS IS NOT A LIST FOR CHERRY-PICKING!!!!  It is a unculled list of
>     potential candidates that _may_ need or want to be cherry-picked, in
>     case a particular candidate is
>    
>     either
>     a) fixing a regression
>     b) fixing a problem that will foreseeably cause trouble with near-future
>     or our current build systems
>     c) fixing a problem or providing a feature that will foreseeably cause
>     frequent tension between 2.20 and 2.21 users if not cherry-picked
>     d) a definite improvement that does not show potential for causing new
>     regressions
>     e) a documentation fix/change matching 2.20 behavior
>    
>     and/or/maybe
>     a) cherry-picks reasonably painlessly
>     b) does not cause significant followup tasks to be also scheduled
>    
>     > Or are these patches that were created after we put out the last
>     > pre-release?
>    
>     Minus those I already cherry-picked
>    
>     > Would you like me to try doing the cherry-picking for you?
>    
>     If anybody tries indiscriminately picking that list, I am going to be
>     pissed.  The majority of those patches likely has no place in 2.20.
>
> OK, I will not do any cherry-picking.
>
> Is there anything else that can be done to help?

I already mentioned _vetting_ that list but you removed that part before
replying.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Jonas Hahnfeld
In reply to this post by dak
Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:

> Carl Sorensen <
> [hidden email]
> > writes:
>
> > Dear Team,
> >
> > It seems to me like we are pretty much in shape such that we should
> > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
> > even if there are some critical regressions.  2.19.83 is SO much
> > better than 2.18.2.
> >
> > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
> > some patches.  Is that correct?
>
> And putting out a new prerelease to be sure that those are ok, and
> waiting for the translators to catch up with cherry-picked patches
> containing stuff to be translated.
>
> But the current roadblock is David K. cherry-picking some patches.  Here
> is a remaining list (not completely up to date with current master,
> though not missing much) to check for possible inclusion (assuming I
> have not overlooked something important pickable in the sequence
> before).  If you see something important here (or something not in
> current master), put in a word for it.
Thanks for the list of candidates, I processed around half of it for
now (+ some dependencies as mentioned below).
All commits that I think should be "picked" are also readily available
in my branch origin/dev/hahnjo/stable-2.20. Let me know if those are ok
and I can easily push to stable/2.20.

> ef2cc5e684 Issue 5471/1: relocate.cc: Add `indent' parameter to `sane_putenv'
> d6428b77b6 Issue 5471/2: main.cc, relocate.cc: Improve relocation debug messages
> 19da23977f Issue 5471/3: relocate.cc: Don't use double forward slashes in file names

I wouldn't pick these three: It's for better debuggability and
additionally adds translatable messages.

> 88980c4f92 Fix #5474: progerror when creating an undefined grob

picked

> 0f5c046811 Functions to invert chords or drop/rise chord notes
> 6f1cf6c2b5 Add regtest for chord inversions and voicings

I think that's a new feature, should not be picked IMO.

> ddef2aa7b6 Issue 5472/1: yaffut.hh: Fix compilation warning
> e37310a8e9 Issue 5472/2: flower/file-name.cc: Fix canonical file name representation

picked

> 3bd7050543 Issue 5468: yyout2grammar.py: Various fixes

I've picked 385ed0864c ("yyout2grammar.py: Formatted to blend with
other lilypond Python scripts") first to ease cherry-picking.

> 0deb785f64 Update texinfo.tex from Texinfo git master branch

not sure about this one...

> cb1963c46a Web: update online editors section.

picked

> 965a607096 Fix #1367: NoteNames context in any language

not sure, has quite some changes in lily/ and scm/

> ed86e71eb0 Use "simple strings" rather than #"hash-prefixed Scheme strings"

not sure: It's a very large commit, mostly in Documentation/ and
input/, but also in ly/...

> 3aeb41c27f Command line help: -o option takes either FILE or FOLDER as arg.

Picked 92d7477bf7 ("main.cc: Fix typo (`-O size', not `-O speed')" and
139f0ce98d ("main.cc: Fix `--help' output.") first and then this one.

> e94db23e6c C++ cleanup : get rid of some compilation warnings

looks small enough to take, but doesn't apply cleanly due to other
changes.

> 804faebc79 Issue 5481/1: main.cc, relocate.cc: Minor code clean-up
> 7200d7365b Issue 5481/2: running.itely: Document relocation
> e9c082d4d4 Issue 5481/3: flower/file-name.cc: Better handling of `.' and `..'
> f0c3e7461e Issue 5481/4: relocate.cc: Rewrite relocation algorithm

hmm, the last commit claims it's "much easier to follow", but I'm not
sure it's actually fixing an issue?

> 5eb848b59b Issue 5484: set doubleRepeatType fallback to default
> b05de1da2a pitches.itely: Fix typos and improve look of accidental name tables.
> dceebb052f Website: use VERSION_DEVEL rather than MAJOR.MINOR
> 5eb392ddd5 Issue 5485: avoid -Wsequence-point warning
> cdfb8f3fd3 Do not build PDFs from the website Texinfo sources - issue 5482
> 3ba581df6a Issue 5490: fix for wrong clefs.varC_change

all picked.

> 2afb45bd85 Issue 5489/1: improve prall glyphs

It says "fix erroneous shape of pralldown/prallup" in the commit
description, not sure if we want to pick this...

> 56942ccc5f Issue 5489/2: rename trilelement → trillelement

Sounds like a typo fix that potentially breaks code that worked in
earlier unstable releases?

> 1284c743b0 Issue 5487/1: add very short and Henze fermatas
> 77b98cbbc6 Issue 5487/2: add new fermatas to Changes doc

AFAICS that's a new feature, not picked.

> 5a88042cc8 Scripts: Removed references to gmane
> 879f5b1da5 Doc: NR 4.2.2 - remove deprecated @knownissue
> a99f7f83c8 Doc: Usage - Invoking Musicxml2ly - add missing switches

all picked.

> 19677c83b0 Makelsr.py run for previous commits

This mentions commits 78225bc1b3 ("Chord names clean-up [...]") and
ed86e71eb0 ("Use "simple strings" rather than #"hash-prefixed Scheme
strings""), see above.

> 464cf0d811 Fix #687: Include MIDI swing script in default distribution

new feature, not picked.

> 13dc8b9c72 Issue 5498: Revert "Merge branch 'issue4914'"

picked

> a39c23d554 Release: bump VERSION_DEVEL.
> 941dfa8bed Release: update news.
> 54de6a24c5 Release: bump Welcome versions.

Do we need these in stable/2.20?

> 1b1b06dbc7 NR: Document usage of \change at beginning of staff.

picked

> 45dedd482d Add warning message for unknown code in fret-diagram-verbose
> 6508284378 Clean up problems with fret-diagram-terse markups
> 0e6f55bb17 Change hardcoded pair to cons call for return -- remove ugh comment

all picked, I think these are small enough and add warnings to existing
cases...

> 64a61d9b5d Doc: extending: Fix after-line-breaking example.
> c05184b3ff CG: Typo for British and American English locales
> c415cb98c3 Issue 5502: NR: Add many function index entries

all picked

> e0d597aed3 Typo in \oval docstring
> 0f047e3514 Fix German quarter tone pitch names.
> f3d46cd65d Fix commit b05de1da2abe0a6d3e0eac8202ea45ba41ff47df.

all picked. The fixed commit mentioned in the last one is actually from
above, so I think we should take both (or none)

> 9c0e1363ac Issue #5506: Add tremolo stem support to \cueDuring

Looks like a small new "feature", not picked for now.

> 9d9dc55729 Issue 5501: Avoid failed assertion in stem tremolo code
> 3008803555 Doc: NR added @knownissue re midi block with polymetric notation

both picked.

> db818c1220 ly: Adding turkish-makam.ly

looks like a new feature?

> f4e30857e1 Doc: Usage - Better description of -dcrop in Usage chapter 1.2

I would propose to pick the following commits (in that order):
a6553e3cde Issue 5451: running.itely: Revise documentation of basic command line options
03f91e47a2 Issue 5452: running.itely: Revise documentation of -d command line options
f3f2b9d3d1 running.itely: Minor fixes for command line option documentation.
f4e30857e1 Doc: Usage - Better description of -dcrop in Usage chapter 1.2

(The first resulted in conflicts because the branch has c7c6c948c9
which was not in master...)

> a7ef349f29 Doc: LM + NR - Typos \addlyrics and \lyricmode
> ed0212b1dc Doc: Internals - clarify stem-length is in half staff space units
> 03f78e3e7b Doc: NR - 2.10.2 - Arabic Music - improved example

all picked.

> c511518a4e makelsr run for previous commit

not if we should pick this commit or just run makelsr on the branch?

> d0730c389d Issue 5510 Add doc-string for allowVoltaHook
> bd05971b2a Issue 5509 Reflect new syntax in example of define-grob-properties.scm
> 6ecee87252 Minor NR corrections.

all picked.

> 8d7c176b45 Issue 5511/1: add articulation support to MMRs
> 4424b153c0 Issue 5511/2: deprecate \fermataMarkup
> 453fa92e43 Issue 5511/3: update regression tests
> 200658ca20 Issue 5511/4: doc: NR and Changes
> 59284fa692 Issue 5511/5: doc: Update translated docs

looks like a new feature, not picked.

> e8ad7f0c78 Minor.
> ab8e7e4d89 Issue 5513: Avoid some crashes for bad "control-points" property

both picked.

> ff348fa75a Issue 5486/1: add very short/Henze fermata commands
> c9286e87ee Issue 5486/2: add fermata commands to NR

new feature, see above (commit 1284c743b0)

> a33f922e0f Pondings: fixed URL for Ben Lemon
> bc46cc1fef Documentation: elaborate NR `custom percussion’ section

both picked.

> 29c5443642 Issue 5519/1: Give NoteNames context an \alias Staff
> f669227b46 Issue 5519/2: fix regtest accidental-voice

I tend to say that these two should be picked as well, but not really
sure because I don't know the context...

> cfee7a3a26 Issue 5518 Document bound-details (sub-)properties in line-spanner-cc for IR
> a53d6523dc lily/GNUmakefile: `sources.o' depends on `parser.hh'
> e71c3c2725 Issue 5523: add `-Wno-sequence-point' to g++ CFLAGS for Guile 1.8

all picked.

> 1272e45b49 Issue 5526 Add ly version to swing.ly

not relevant unless we pick 464cf0d811, see above.

> f9fe10bde4 Doc: NR - 2.10 World Music Turkish Classical additions

not relevant unless we pick db818c1220, see above.

> 77b2c39186 Makelsr for previous commit

see previous commit

> 2513916bed Web: 'Productions' - introduction.itexi additions and corrections

picked 844e8cda13 ("Web: update Productions list (Issue #5445)") first
to avoid conflicts.

So much for now. The result of all "picked" commits (also in branch
origin/dev/hahnjo/stable-2.20) passes a full build, check and doc.

Regards,
Jonas

> 0e1eeb7838 aclocal.m4: Whitespace and formatting.
> bc4f5fdc29 Add glib-2.0 and gobject-2.0 library dependency
> 4cc884ee09 ly: turkish-makam.ly - minor edit to sultaniyegah
> 189cfb95ea Doc: NR 2.9 Ancient Notation - add verbatim to @lilypond example for custodes
> 00b4c4c757 Doc: NR - expressive.itely - accidentals for naturals using pitched trills
> 03f4723afc Issue 5520/1: Improvements to \ambitusAfter
> 2b52bc2bf1 Issue 5520/2: add \ambitusAfter to Changes
> 17d3d3a151 Issue 4362/1: head completion uses dotted breves
> 49f41bf1c6 Issue 4362/2: add regtest
> 47f74e11cf Doc: Use new syntax throughout all doc and examples
> 1d4717d0db NR: 2.10 Arabic Music - inlcude references to hel-arabic.ly
> 7ecc24c5e8 Issue #5524 New function css-color (accompanying x11-color)
> 53739c0ae6 Issue 5303 - Misplaced Notehead
> 3300acdd8d Issue 5532/1: \ottava doesn’t confuse ambitus
> 04a0052411 Issue 5532/2: add regtest
> c5f63d33bf Add tex/txi-pt.tex
> 77b816a48f Issue 5535: Build logging: Improve METAFONT tracing
> 7583351fbf Optimize tree.gittxt messages
> ebc35cb7b6 web:development: Make Release Numbers more current
> 34a114b835 Revert "Optimize tree.gittxt messages"
> b62d62e402 Optimize tree.gittxt messages (v 2)
> 39c9d91c46 Fix relocate-preamble.py bug
> a77f387207 Fix musicxml2ly.py / Python 2.4.5 incompatibility
> 3f0b5c61a7 Issue 5541: treat CENTER in Side_position_interface::aligned_side
> 42c45c5dfc Web: update old links to Ben Lemon tutorials
> cf600cc6f8 mf/README: Describe creation of Emmentaler fonts.
> 6b789abd46 ly: hel-arabic - comment out Sahnaz entry
> 2165edafc5 Issue 5551/1: better indexing support
> 1eed54e8ff Issue 5551/2: improve generated documentation
> 714792a1eb Issue 5552/1: HOWTO.index: new guide for creating index entries
> b2799c1823 Issue 5552/2: NR: complete revision of all index entries
> 227fac3a04 We now need texinfo 6.1 or newer.
> e926c294e3 Issue 5553: fix handling of @lilypond[verbatim]
> 89036755a7 Replace code.google.com by SourceForge
> 805e6ef94c bach-schenker.ly: Completely revised.
> be39d353b7 Rename `Stockhausen_Klavierstueck2' to `stockhausen-klavierstueckII'.
> a6f8381ea4 stockhausen-klavierstueckII: Completely rewritten.
> 1d3105fce4 run-and-check: Show output directory in case of error.
> 0457814df4 string-tunings-init: Fix typo in Banjo tuning.
> 4402d6c545 Issue 5555/1: reorder checks in add_post_events for efficiency
> eed07c3e54 Issue 5555/2: add_post_events: check for time-scaled-music explicitly
> ab3b23941f Issue 5555/3: TimeScaledMusic should not be music-wrapper-music
> c2b424f9f8 Remove old make-countdown-announcement.sh
> 71c4990e47 run-and-check: Display correct log file directory.
> 9bef63308f Issue 5557: Remove spurious '% begin verbatim' in Documentation/snippets/new
> 1d255547ba Run scripts/auxiliar/makelsr.py
> 3064ac9d3d Issue 5558/1: NR: add many index entries for snippets
> 7930d8777e Issue 5558/2: NR: various minor corrections
> 09bc2e2ed7 Issue 5560: remove script-chart.ly
> 2c2908c905 Issue 5563: make edges of brackets dashable
> 7e6a956625 Issue 5561/5562: slurs work without NoteHead stencil
> 476194c706 Issue 5559/1: Add user-definable ottava markups
> 608aa55988 Issue 5559/2: add regtest
> 6f319a862d Issue 5556/3: make OttavaBracket text default bold
> 2f1649830b Issue 5559/4: fix regression (ambitus with ottava)
> d9555cda14 Issue 5565: simplify python-related makefiles
> c95d96aa71 Typo.
> 058c7347c1 granados.ly: Improved and updated.
> 5674d4570d NR: add snippet to describe `NoteCollision.prefer-dotted-right'
> b7532cf6e6 Issue 5568: make build output terse by default
> cd11e1d06e Update python headers to match surrounding files
> fa6c70e39a Issue 5567: allow slurs instead of brackets with tuplets
> a6a6f019a9 Fix header variables from musicxml2ly on Windows
> 2d45d5247e Drop requirement for python-devel
> 75b16466ef Issue 5564: fix conversion warnings in beaming code
> 8ba40d3d69 Issue 5571: streamline cat | sed | sed
> 0c0a07a6d7 Issue #5574: freetype.cc: fix compiler warnings
> 0d7744aad0 Issue 5572/1: Compile modified C++ files automatically before testing
> 73aaa6d299 Issue 5572/2: Contributor's Guide updates
> 306fc6b509 Issue 5576: make output-distance less verbose by default
> ad3effb756 Check additional names for guile-config
> dbe42f9940 Issue 5583: www_post.py: don't mirror regtest baseline
> 014ec06a9f python: replace <> with !=
> 911788f173 Issue 5578: add a button to flip between old and new regtest images
> 2823ff0e87 Issue 5579: fix stem tremolo on rests crash
> 3903d2efc7 Issue 5577: scripts/build: Remove unused scripts
>
>
> > I'd really like to see us get something out as 2.20 by the first of
> > the year.  What can I do to help?
> >
> > Thanks,
> >
> > Carl
> > 
> >
>
>

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Werner LEMBERG

>> 0deb785f64 Update texinfo.tex from Texinfo git master branch
>
> not sure about this one...

IMHO this should be skipped.  Instead, right before the 2.20 release,
the newest `texinfo.tex` from texinfo's git master branch should be
used.

>> 804faebc79 Issue 5481/1: main.cc, relocate.cc: Minor code clean-up
>> 7200d7365b Issue 5481/2: running.itely: Document relocation
>> e9c082d4d4 Issue 5481/3: flower/file-name.cc: Better handling of `.' and `..'
>> f0c3e7461e Issue 5481/4: relocate.cc: Rewrite relocation algorithm
>
> hmm, the last commit claims it's "much easier to follow", but I'm not
> sure it's actually fixing an issue?

Since relocation is a central element of LilyPond in gub I think it
would be good to add this.

>> 2afb45bd85 Issue 5489/1: improve prall glyphs
>
> It says "fix erroneous shape of pralldown/prallup" in the commit
> description, not sure if we want to pick this...

I think this is an improvement, so I think to pick this makes sense.


   Werner

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Jonas Hahnfeld
Am Montag, den 18.11.2019, 18:48 +0100 schrieb Werner LEMBERG:
> >> 0deb785f64 Update texinfo.tex from Texinfo git master branch
> >
> > not sure about this one...
>
> IMHO this should be skipped.  Instead, right before the 2.20 release,
> the newest `texinfo.tex` from texinfo's git master branch should be
> used.

Sounds like a good plan if we want to have newer features from there.

> >> 804faebc79 Issue 5481/1: main.cc, relocate.cc: Minor code clean-up
> >> 7200d7365b Issue 5481/2: running.itely: Document relocation
> >> e9c082d4d4 Issue 5481/3: flower/file-name.cc: Better handling of `.' and `..'
> >> f0c3e7461e Issue 5481/4: relocate.cc: Rewrite relocation algorithm
> >
> > hmm, the last commit claims it's "much easier to follow", but I'm not
> > sure it's actually fixing an issue?
>
> Since relocation is a central element of LilyPond in gub I think it
> would be good to add this.
Sure, but does it fix an issue that makes it "critical" enough to add
the new relocation code fairly late in the process?

Jonas

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 18.11.2019, 18:48 +0100 schrieb Werner LEMBERG:
>> >> 0deb785f64 Update texinfo.tex from Texinfo git master branch
>> >
>> > not sure about this one...
>>
>> IMHO this should be skipped.  Instead, right before the 2.20 release,
>> the newest `texinfo.tex` from texinfo's git master branch should be
>> used.
>
> Sounds like a good plan if we want to have newer features from there.

I prefer cherry-picking the changes since that means that support files
(like for other languages) are not accidentally omitted.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Simon Albrecht-2
In reply to this post by Jonas Hahnfeld
I would like to give whatever small contribution I can make to this
without knowing so much on the technical levels; please do tell me
whether I say below is considered helpful.


On 18.11.19 18:10, Jonas Hahnfeld wrote:
>> 965a607096 Fix #1367: NoteNames context in any language
> not sure, has quite some changes in lily/ and scm/

This seems like a new feature to me that shouldn’t be picked.


>> ed86e71eb0 Use "simple strings" rather than #"hash-prefixed Scheme strings"
> not sure: It's a very large commit, mostly in Documentation/ and
> input/, but also in ly/...

This seems pretty trivial and innocuous to me; also for a major release
it is much desirable to uniformly adapt new syntax, I think.


>> 2afb45bd85 Issue 5489/1: improve prall glyphs
> It says "fix erroneous shape of pralldown/prallup" in the commit
> description, not sure if we want to pick this...

IMO this is so much non-critical that it should only be picked if the
change is very innocuous, which I can’t tell if it is.


>> 9c0e1363ac Issue #5506: Add tremolo stem support to \cueDuring
> Looks like a small new "feature", not picked for now.

Here I’d say this is not a new feature, but a bug fix, and the
mechanisms used for the change are secure enough to pick it. Again, my 2cts.

Thanks for your efforts.

Best, Simon


Reply | Threaded
Open this post in threaded view
|

Re: Re: What is holding up 2.20 release?

Mats Bengtsson-4

On 11/19/19 1:30 AM, Simon Albrecht wrote:
> 9c0e1363ac Issue #5506: Add tremolo stem support to \cueDuring
>> Looks like a small new "feature", not picked for now.
>
> Here I’d say this is not a new feature, but a bug fix, and the
> mechanisms used for the change are secure enough to pick it. Again, my
> 2cts.

+1

It's a very annoying bug if you're hit by it, and as you say the bug fix
doesn't do anything strange.

    /Mats



Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

John Mandereau-2
In reply to this post by Jonas Hahnfeld
On Mon, 2019-11-18 at 19:29 +0100, Jonas Hahnfeld wrote:
> Sure, but does it fix an issue that makes it "critical" enough to add
> the new relocation code fairly late in the process?

For the discussion that motivated these changes, see
https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg00080.html
Although they fix a bug in a very special case, IMVHO they do not sound
really critical but fall more in the cleanup category.

Note that if cherry-picking commits from issue 5481 is approved, then
the changes brought by these commits will need to be slightly reworked
or some or all commits for issue 5471 (at least 5471/1 for the
additional optional argument of sane_putenv and probably also 5471/2)
will have to be cherry-picked too.

About the general cherry-picking process, I'm happy to provide
occasional GUB build test on it – I just launched it for
dev/hahnjo/stable-2.20.

Best,
John


Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Adam Good-3
In reply to this post by Jonas Hahnfeld
Just one comment below regarding turkish-makam.ly

On Mon, Nov 18, 2019 at 12:16 PM Jonas Hahnfeld <[hidden email]> wrote:

>
> > db818c1220 ly: Adding turkish-makam.ly
>
> looks like a new feature?
>

Please let me know if I can answer any questions about it or weigh in on
thoughts. This one I made and use daily so it has been heavily tested, at
least by me. It's a large update to makam.ly

best,
Adam Good
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Malte Meyn-3
In reply to this post by dak


Am 16.11.19 um 21:52 schrieb David Kastrup:
> But the current roadblock is David K. cherry-picking some patches.  Here
> is a remaining list (not completely up to date with current master,
> though not missing much) to check for possible inclusion (assuming I
> have not overlooked something important pickable in the sequence
> before).  If you see something important here (or something not in
> current master), put in a word for it.

I just realised that the error mentioned at issue 5251
(https://sourceforge.net/p/testlilyissues/issues/5251/#f53c) is a
regression:

2.18.2 good
2.19.27 good
2.19.28 bad
2.19.83 bad
master good (and added regtest multi-measure-rest-number-threshold.ly)

Probably one of the four commits for issue 4594 (2e22eccf and ancestors)
introduced the bug.

So I’d vote for cherry-picking 253b2489, 349fb569, c7bf27ad even though
they haven’t been on your list.

> 3ba581df6a Issue 5490: fix for wrong clefs.varC_change
The varC clefs are a 2.19 feature. I think that new features in stable
versions should be bug-free if possible so I’d vote for cherry-picking
this too.

> 2afb45bd85 Issue 5489/1: improve prall glyphs
> 56942ccc5f Issue 5489/2: rename trilelement → trillelement
The wrong prall glyphs have annoyed me for years now and have seen them
every now and then in scores on the internet. It’s a simple fix, I don’t
expect heavy side effects (at least for 5489/1) so I’d vote for picking
this.

> 1284c743b0 Issue 5487/1: add very short and Henze fermatas
> 77b98cbbc6 Issue 5487/2: add new fermatas to Changes doc
> ff348fa75a Issue 5486/1: add very short/Henze fermata commands
> c9286e87ee Issue 5486/2: add fermata commands to NR
New features, don’t pick.

> 0f047e3514 Fix German quarter tone pitch names.
Simple fix, backwards-compatible, pick.

> 8d7c176b45 Issue 5511/1: add articulation support to MMRs
> 4424b153c0 Issue 5511/2: deprecate \fermataMarkup
Syntax change, don’t pick. Off-topic: maybe 2.22 or 2.24 can have MMRs
and rests be the same in the input language?

> 1272e45b49 Issue 5526 Add ly version to swing.ly
swing.ly is not part of stable/2.20 branch. IMHO swing.ly is broken and
should be postponed to 2.22, see
https://lists.gnu.org/archive/html/bug-lilypond/2019-11/msg00023.html

> 03f4723afc Issue 5520/1: Improvements to \ambitusAfter
> 2b52bc2bf1 Issue 5520/2: add \ambitusAfter to Changes
\ambitusAfter is not part of stable/2.20 so don’t pick.

> 17d3d3a151 Issue 4362/1: head completion uses dotted breves
> 49f41bf1c6 Issue 4362/2: add regtest
Simple fix, I’d consider picking it.

> 3300acdd8d Issue 5532/1: \ottava doesn’t confuse ambitus
> 04a0052411 Issue 5532/2: add regtest
Simple fix, I’d consider picking this.

> 2c2908c905 Issue 5563: make edges of brackets dashable
> 476194c706 Issue 5559/1: Add user-definable ottava markups
> 608aa55988 Issue 5559/2: add regtest
> 6f319a862d Issue 5556/3: make OttavaBracket text default boldThese should not be picked because the changes are relatively big and
neither thoroughly tested nor well documented yet.
> 2f1649830b Issue 5559/4: fix regression (ambitus with ottava)
However this one improves 5532/2 and might be picked.

> 2823ff0e87 Issue 5579: fix stem tremolo on rests crash
We don’t want crashes in stable versions, do we? ;)

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Jonas Hahnfeld
In reply to this post by Jonas Hahnfeld
Hi David,

Am Montag, den 18.11.2019, 18:10 +0100 schrieb Jonas Hahnfeld:

> Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:
> > Carl Sorensen <
> > [hidden email]
> >
> > > writes:
> > > Dear Team,
> > >
> > > It seems to me like we are pretty much in shape such that we should
> > > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
> > > even if there are some critical regressions.  2.19.83 is SO much
> > > better than 2.18.2.
> > >
> > > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
> > > some patches.  Is that correct?
> >
> > And putting out a new prerelease to be sure that those are ok, and
> > waiting for the translators to catch up with cherry-picked patches
> > containing stuff to be translated.
> >
> > But the current roadblock is David K. cherry-picking some patches.  Here
> > is a remaining list (not completely up to date with current master,
> > though not missing much) to check for possible inclusion (assuming I
> > have not overlooked something important pickable in the sequence
> > before).  If you see something important here (or something not in
> > current master), put in a word for it.
>
> Thanks for the list of candidates, I processed around half of it for
> now (+ some dependencies as mentioned below).
> All commits that I think should be "picked" are also readily available
> in my branch origin/dev/hahnjo/stable-2.20. Let me know if those are ok
> and I can easily push to stable/2.20.
I've noticed that you picked a handful of commits to stable/2.20 last
week. Does it still make sense for me to maintain my branch (and
continue going through the list) if you're doing the work yourself
anyhow?

Jonas

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
Jonas Hahnfeld <[hidden email]> writes:

> Hi David,
>
> Am Montag, den 18.11.2019, 18:10 +0100 schrieb Jonas Hahnfeld:
>> Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:
>> > Carl Sorensen <
>> > [hidden email]
>> >
>> > > writes:
>> > > Dear Team,
>> > >
>> > > It seems to me like we are pretty much in shape such that we should
>> > > release 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,
>> > > even if there are some critical regressions.  2.19.83 is SO much
>> > > better than 2.18.2.
>> > >
>> > > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-pick
>> > > some patches.  Is that correct?
>> >
>> > And putting out a new prerelease to be sure that those are ok, and
>> > waiting for the translators to catch up with cherry-picked patches
>> > containing stuff to be translated.
>> >
>> > But the current roadblock is David K. cherry-picking some patches.  Here
>> > is a remaining list (not completely up to date with current master,
>> > though not missing much) to check for possible inclusion (assuming I
>> > have not overlooked something important pickable in the sequence
>> > before).  If you see something important here (or something not in
>> > current master), put in a word for it.
>>
>> Thanks for the list of candidates, I processed around half of it for
>> now (+ some dependencies as mentioned below).
>> All commits that I think should be "picked" are also readily available
>> in my branch origin/dev/hahnjo/stable-2.20. Let me know if those are ok
>> and I can easily push to stable/2.20.
>
> I've noticed that you picked a handful of commits to stable/2.20 last
> week. Does it still make sense for me to maintain my branch (and
> continue going through the list) if you're doing the work yourself
> anyhow?

I've worked from your list so far, checking the stuff individually,
skipping over things that just were too rife in conflict and so on, and
using cherry-pick -x for keeping better track.  I'm not yet through the
annotated commit list you posted.  I've been working with your
preparatory work and its description but not with your branch.

Does this help you deciding where to focus?  As long as we have no
formal handoff of release manager duties (I won't rule that out
eventually but it seems like you'd deserve more preparation than what
you got), I think that's sort-of reasonable.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

Dev mailing list
Am Freitag, den 06.12.2019, 22:45 +0100 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> writes:
> > Hi David,
> > Am Montag, den 18.11.2019, 18:10 +0100 schrieb Jonas Hahnfeld:
> > > Am Samstag, den 16.11.2019, 21:52 +0100 schrieb David Kastrup:
> > > > Carl Sorensen <[hidden email]
> > > >
> > > > > writes:Dear Team,
> > > > > It seems to me like we are pretty much in shape such that we shouldrelease 2.20.  I'd be fine if we called 2.19.83-1 the 2.20 release,even if there are some critical regressions.  2.19.83 is SO muchbetter than 2.18.2.
> > > > > IIUC, the only thing 2.20 is waiting on is for David K. to cherry-picksome patches.  Is that correct?
> > > >
> > > > And putting out a new prerelease to be sure that those are ok, andwaiting for the translators to catch up with cherry-picked patchescontaining stuff to be translated.
> > > > But the current roadblock is David K. cherry-picking some patches.  Hereis a remaining list (not completely up to date with current master,though not missing much) to check for possible inclusion (assuming Ihave not overlooked something important pickable in the sequencebefore).  If you see something important here (or something not incurrent master), put in a word for it.
> > >
> > > Thanks for the list of candidates, I processed around half of it fornow (+ some dependencies as mentioned below).All commits that I think should be "picked" are also readily availablein my branch origin/dev/hahnjo/stable-2.20. Let me know if those are okand I can easily push to stable/2.20.
> >
> > I've noticed that you picked a handful of commits to stable/2.20 lastweek. Does it still make sense for me to maintain my branch (andcontinue going through the list) if you're doing the work yourselfanyhow?
>
> I've worked from your list so far, checking the stuff individually,skipping over things that just were too rife in conflict and so on, andusing cherry-pick -x for keeping better track.  I'm not yet through theannotated commit list you posted.  I've been working with yourpreparatory work and its description but not with your branch.
> Does this help you deciding where to focus?
Ok, then I'll continue with the second half and post my findings once done.

Jonas

signature.asc (499 bytes) Download Attachment
dak
Reply | Threaded
Open this post in threaded view
|

Re: What is holding up 2.20 release?

dak
In reply to this post by John Mandereau-2
John Mandereau <[hidden email]> writes:

> On Mon, 2019-11-18 at 19:29 +0100, Jonas Hahnfeld wrote:
>> Sure, but does it fix an issue that makes it "critical" enough to add
>> the new relocation code fairly late in the process?
>
> For the discussion that motivated these changes, see
> https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg00080.html
> Although they fix a bug in a very special case, IMVHO they do not sound
> really critical but fall more in the cleanup category.
>
> Note that if cherry-picking commits from issue 5481 is approved, then
> the changes brought by these commits will need to be slightly reworked
> or some or all commits for issue 5471 (at least 5471/1 for the
> additional optional argument of sane_putenv and probably also 5471/2)
> will have to be cherry-picked too.
>
> About the general cherry-picking process, I'm happy to provide
> occasional GUB build test on it – I just launched it for
> dev/hahnjo/stable-2.20.

This is a complete mess to cherry-pick.  I've done all of

6fe27a71ba (HEAD -> stable) Issue 5481/3: flower/file-name.cc: Better handling of `.' and `..'
7b66fff27a Issue 5481/2: running.itely: Document relocation
468898c7f1 Issue 5481/1: main.cc, relocate.cc: Minor code clean-up
b4d20ea792 Issue 5471/2: main.cc, relocate.cc: Improve relocation debug messages
e1157a2632 Issue 5471/1: relocate.cc: Add `indent' parameter to `sane_putenv'
0aed46ada6 Issue 5453/2: Make unused command line option `--relocate' a no-op
43e672b04b Issue 5453/1: Remove unused configure option `--enable-relocation'

including some minor conflict resolution and it still fails with the non-trivial

diff --cc lily/relocate.cc
index 5a85320dc1,8e97199a01..0000000000
--- a/lily/relocate.cc
+++ b/lily/relocate.cc
@@@ -110,57 -110,48 +110,91 @@@ prepend_env_path (char const *key, stri
    return -1;
  }
 
++<<<<<<< HEAD
 +static void
 +prefix_relocation (const string &prefix)
 +{
 +  string bindir = prefix + "/bin";
 +  string datadir = prefix + "/share";
 +  string localedir = datadir + "/locale";
 +  string package_datadir = datadir + "/lilypond/";
 +  string old_lilypond_datadir = lilypond_datadir;
 +
 +  if (is_dir (package_datadir + "/" TOPLEVEL_VERSION))
 +    lilypond_datadir = package_datadir + "/" TOPLEVEL_VERSION;
 +  else if (is_dir (package_datadir + "/current"))
 +    lilypond_datadir = package_datadir + "/current";
 +  else
 +    warning (_f ("Not relocating: no '%s/' or 'current/' found under '%s'",
 +                 TOPLEVEL_VERSION, package_datadir));
 +
 +#if HAVE_GETTEXT
 +  if (is_dir (localedir))
 +    bindtextdomain ("lilypond", localedir.c_str ());
 +#endif
 +
 +  prepend_env_path ("PATH", bindir);
 +
 +  debug_output (_f ("  Compiled-in datadir '%s'\n"
 +                    "  New datadir '%s'\n",
 +                    old_lilypond_datadir,
 +                    lilypond_datadir));
 +}
 +
 +/*
 +  UGH : this is a complete mess.
 +*/
 +
 +static void
 +framework_relocation (const string &prefix)
++=======
+ static string
+ set_up_directory (char const *env_name,
+                   char const *id,
+                   string compile_default,
+                   string runtime_default,
+                   string alt_runtime_default = "")
++>>>>>>> f0c3e7461e... Issue 5481/4: relocate.cc: Rewrite relocation algorithm
  {
-   debug_output (_f ("  Framework prefix '%s'", prefix));
+   string dir = "";
 
-   sane_putenv ("INSTALLER_PREFIX", prefix, true, true);
+   // check environment variable
+   if (char const *env_value = getenv (env_name))
+     {
+       dir = File_name (env_value).canonicalized ().to_string ();
+       debug_output (_f ("  Found %s environment variable,\n"
+                         "    setting %s to '%s'\n",
+                         env_name, id, dir));
+       return dir;
+     }
 
++<<<<<<< HEAD
 +  read_relocation_dir (prefix + "/etc/relocate/");
++=======
+   // otherwise check run-time value(s)
+   if (is_dir (runtime_default))
+     dir = runtime_default;
+   else if (is_dir (alt_runtime_default))
+     dir = alt_runtime_default;
++>>>>>>> f0c3e7461e... Issue 5481/4: relocate.cc: Rewrite relocation algorithm
+
+   if (!dir.empty ())
+     {
+       dir = File_name (dir).canonicalized ().to_string ();
+       debug_output (_f ("  Using run-time value for %s,\n"
+                         "    setting it to '%s'\n",
+                         id, dir));
+       return dir;
+     }
 
-   string bindir = prefix + "/bin";
-
-   prepend_env_path ("PATH", bindir);
+   // otherwise fall back to compile-time value
+   dir = File_name (compile_default).canonicalized ().to_string ();
+   debug_output (_f ("  Using compile-time value for %s,\n"
+                     "    setting it to '%s'\n",
+                     id, dir));
+   return dir;
  }
 
- /*
-   UGH : this is a complete mess.
- */
  void
  setup_paths (char const *argv0_ptr)
  {


This is so much of a mess that I'd need a very good reason (namely:
won't work otherwise) for trying to fold this in.

--
David Kastrup

12