Whilst the procedure of marking an issue as fixed, with an additional Fixed_mm_MM_ss label, is briefly mentioned at the end of the "Issue classification section" in the Contributor's Guide:
http://lilypond.org/doc/v2.17/Documentation/contributor/issue-classification it is slightly misleading, and also omits important details: - Fixed_mm_MM_ss suggests fixed width, e.g. Fixed_02_17_01, but this is not the case. It would be better to call it Fixed_X_Y_Z. - What's the correct value of X, Y, and Z? (Answer is presumably that they come from MAJOR_VERSION, MINOR_VERSION, and PATCH_LEVEL in $LILYPOND_GIT/VERSION) - Are developers supposed to mark the issue as fixed immediately after pushing the corresponding patch series to staging, or should they first wait for the tests to automatically advance master? Additionally, the above information still needs to be explicitly referenced from the two[1] places where pushing to staging is documented: http://lilypond.org/doc/v2.17/Documentation/contributor/git-for-the-impatient http://lilypond.org/doc/v2.17/Documentation/contributor/pushing-to-staging I think it would be better to reference via links back to the 'Issue classification' section, rather than have the same information duplicated three times. Thanks, Adam [1] Speaking of duplication, why do we document the procedure for pushing to staging twice? The version in 'Git for the impatient' is hardly any shorter than the full version in 'Pushing to staging', and violating the DRY rule increases the maintenance burden and also risks information becoming out of date in one of the two places. Should impatient git users even be allowed to push to staging? _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel