Re: visible-over-note-heads snippet

[Jean Abou Samra]

Le 14/10/2022 à 18:13, Martín Rincón Botero a écrit :
> Hello,
>
> as suggested by Jean, I still intend to make a snippet for the new
> visible-over-note-heads in the rhythm snippets section of the
> documentation. Is it something that should be merged into the 2.25 branch
> or into 2.24? (the feature per se is already merged, so it makes sense that
> it's in 2.24).



As told by Jonas, preferably in the master branch, and
he'll cherry-pick it for you. In other words, you don't
have to change anything to your contribution process.


> Is it a matter of adding the snippet in
> Documentation/en/notation/rhythms.itely and nothing else (so, no makelsr,
> etc.?).


Depends on how you do it. You could just add a sentence or
two and a @lilypond[verbatim,quote] example in the docs, in
which case there is no additional busywork involved. However,
it could be beneficial to have this as an LSR snippet too,
i.e. make it appear both in the Snippets document from the
official documentation and on lsr.di.unimi.it. In that case
you would add it to Documentation/snippets/new/ (see the
existing snippets there for examples), and then
run "scripts/auxiliar/makelsr.pl --new" and commit the
file that gets added by this under Documentation/snippets/
(and run makelsr.pl again every time you make a change to the
snippet under new/, to update the one in snippets/).


> Should I submit a MR or present it in this mailing list as a
> "suggestion"? (the way that the Contributor Guide seems to imply, because I
> don't think a single snippet falls into the category of "large
> contribution").


This part of the CG is about simple contribution processes for those
who are not comfortable with Git etc. You are, so do it as an MR.
(Our contribution process today is also a lot simpler today than
it was at the time this was written.)


> Because of the "build freeze", is all of this something
> that should happen after 2.24 has been launched or should it happen nowish?



I think you are misunderstanding "build freeze". It means a freeze
of the build system, namely all the code that defines how LilyPond
itself is compiled, as well as its documentation. This is contained
in the various files called "GNUmakefile", the files under make/,
the file "configure.ac" and a few other things. We did a build freeze
on the master branch some time before branching because stability
of the build system is important for Linux distributions.

Now, we have two branches, the 2.24 branch which is in full freeze
(not just of the build system but of everything; no new features or
refactorings go in this branch), and the master branch that will
be released as 2.25, which is open again for development, i.e. no freeze
at all.

Since your snippet will document a feature that is in 2.24, it should
go in 2.24.


> Sorry for all the questions, it shows that I've barely done anything
> related to Documentation in my MRs.
>
> —Martín.
> PS: Since there are a few patches in "waiting" I assume that I shouldn't be
> making any MRs at the moment, right?


master is open again for development, and these MRs should progressively
get reset to ~"Patch::new" and enter the countdown cycle again.

Jean