ARGH. My bad :-( Really sorry guys. It's very simple what happened,
and in fact you already know most of it:
- There was a long period of time in between the completion of the
review and pushing to staging, due to my misunderstanding of the
development process (which I will partially blame on the CG being
incomplete ;-)
- When I finally came to rebase my patches onto staging in order to
be able to push them, there was a one-line merge conflict due
David's patch providing the new $() syntax.
- I read up on the change, and decided that I could resolve the
conflict simply by taking his version and changing \super to
\normal-size-super. As I was already way over time budget on this
whole series and the push was already late, I made a judgement
call that this was all simple enough that I could get away without
waiting another hour or two for a full build and run of the
regression tests. However while using kdiff3 to resolve the
conflict, somehow (I'm guessing too many late night hacking
sessions) I managed to totally screw it up. I could have sworn I
eyeballed the rebased patch after and thought it looked fine, but
obviously it wasn't.
- A few hours later I saw a mail from James saying that staging was
not compiling, and I wondered if it might have been my fault, so
I launched a build and saw the failure:
/home/adam/.GIT/3rd-party/lilypond/build/out/share/lilypond/current/scm/lily.scm:847:21:
Unbound variable: x00f8
but I never touched lily.scm and this didn't look like it could be
related to my changes, so I assumed someone else had broken it.
I definitely agree with Graham that there's no reason to panic about
this, since it arose due to a combination of unusual circumstances,
and if any single one of those was different, it would not have
happened. There's certainly no reason to increase the red tape - in
fact one could argue that it was red tape which caused the latency
between review and push to staging in the first place.
I suggest the following morals to the story:
- I underestimate my own capacity for making mistakes.
- Untested work will empirically demonstrate Murphy's Law.
- A slow build/test cycle encourages developers (or me, at least) to
be sloppy. I'm not sure I have a good solution for that though,
other than perhaps substantially simplifying and optimizing the
build system.
- Cumbersome project tools encourage developers (or me, at least) to
be sloppy. If I hadn't gone so far over time budget due to the
inadequacies of Rietveld and its lack of integration with the
Google Code issue tracker, I most likely would not have been
tempted to cut corners in testing.
- It's really important that critical sections of the CG are
complete and up to date.
- The build error could have been better at pointing out the real
culprit file (GOP 5?)
On Tue, Nov 29, 2011 at 3:09 AM, David Kastrup <d...@gnu.org> wrote:
> I backed out all of the jazz chord changes. Since they were last in
> staging, this did not actually require a rebase. This should likely be
> pretty painless. It does have the disadvantage that anybody who already
> fetched them can accidentally push them back in without the git server
> complaining about this not being a fast forward.
Yup - I agree this is the best approach. I'm building a fixed version
of the patch series as I type this, and will push as soon as I'm
convinced it's good, in order to minimise the risk of someone else
accidentally pushing the old series back in.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
