[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rebasing inside staging

From: Adam Spiers
Subject: Re: rebasing inside staging
Date: Tue, 29 Nov 2011 11:10:47 +0000

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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]