Re: rebasing inside staging

[Adam Spiers]

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 <address@hidden> 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.