"m...@apollinemike.com" <m...@apollinemike.com> writes: > On Oct 24, 2011, at 4:29 PM, David Kastrup wrote: > >> >> Mike has pushed directly 671b7b63408893c33b4c1f196e87db19a7dbcd1e to >> master, as far as I can see without any discussion and without going >> through staging. >> > > This got to patch push after going through a countdown.
Ok, so my mistake, and the only one not following rules at all am I. The problem is that to do a full review of convertrules means actually _applying_ them and looking at the results (including testing them, but also checking visually). Which does not appear to have happened here. > As for staging, I'm still waiting on a response for how that works so > I can do it. git fetch git rebase origin/dev/staging git push origin HEAD:dev/staging > However, I did a complete build with this patch and know it doesn't > break anything, so I don't see how staging would have helped here. The patch does not break anything, but the output of actually _running_ the convertrules (which is their whole point) is partly not pretty, partly wrong (because of double updates). > Which files? Were these files part of a countdown and, if so, were > they commented upon? Going through the Flag patch was my first time > making a change like this, and it would have helped to get comments > from people who know how this works regarding versioning. The problems are the convertrules, not the files that have _not_ _yet_ been committed but which will result from running convert-ly. I recommend you do the following: first pull from master (if you are not interested in seeing why I improved the rules). Make sure you have no uncommitted changes (git diff should be empty). Then run scripts/auxiliar/update-with-convert-ly When it finishes, check the output of "git diff". You will see that there are files which now contain duplicate fixes. Verify that those contain _only_ duplicate fixes (manual and automatic) as well as the version number update and write down their names. Now do git reset --hard For all of the files which were double-fixed, edit their version string to indicate that they are already up to date (according to your last convertrule). Do a commit that contains just these files with their updated version string, reflecting the version they represent after your previous manual fixes. Now run scripts/auxiliar/update-with-convert-ly Check that the output of "git diff" is sane. Run the regtests. If they work out, commit. Put out for review and/or push to dev/staging. Since we are talking about fixups to something which has already passed reviews and countdowns, I'd consider dev/staging reasonable, and I won't be stalled anymore. If Graham disagrees with that assessment, he need not pull the changes over into master. Note that this procedure is only ok if the intermediate state before running convert-ly also does not break regtests (merely looking ugly does not count), or bisecting will get hampered. Since we already arrived at this "intermediate" state with working regtests, this is just something to keep in mind next time around. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
