tl;dr: if James does a regtest check of your patch and sees
problems, you should be ashamed.
In the past few weeks, we've had a fantastic deluge of patches.
Fantastic deluge is fantastic.
However, our ratio of regtest-passing-patches vs. problem-patches
has gone way down. That's not fantastic.
Mike recently posted a patch with the comment "don't run the
regtests on this; this patch is just a proof-of-concept" (or
something like that). I think this is a great idea; let's do more
of it! If a patch is not explicitly called "proof of concept",
then we should assume that the patch is for reals.
in the tracker:
Proof-of-concept patches: mark as patch-needs_work, since the
submitter knows that he needs to do more work.
All other patches: mark as patch-new, and James should check
them. James should not find any regtest problems --
obviously he will from time to time as things slip through
the cracks, but this should be approximately 5% of the time.
I'm not saying that we should tar and feather anybody who sends in
a broken patch for review; mistakes happen! But those should be
viewed as mistakes, and if a few people are making more mistakes
than others, we should try to figure out what's going wrong.
If somebody has a seriously slow computer and cannot run a regtest
comparison in a reasonable amount of time, then we can talk about
that. I'd like to pair you up with somebody who *does* have a
computer built in the last 4 years, or something. But I don't
think you should be paired with James; I'd rather keep him as the
"sanity check" and avoid "dulling his edge" with lots of testing
of incomplete patches.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
