[OPEN-ILS-DEV] QA proposals

Galen Charlton gmc at esilibrary.com
Wed Aug 5 16:42:56 EDT 2015


Hi,

Per today's dev meeting, the second guideline has been revised to:

"A change to database or Perl code that fixes a bug should be
accompanied by a Perl (t or live_t) or pgTAP regression test – or by a
statement from the patch author explaining why a test is infeasible
without significant refactoring. In the latter case, it is expected
that an extra signoff be obtained before the patch is merged."

I've updated the following pages on the wiki accordingly:

http://wiki.evergreen-ils.org/doku.php?id=contributing
http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist
http://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa

Regards,

Galen

On Fri, Jul 17, 2015 at 9:12 AM, Dan Wells <dbw2 at calvin.edu> wrote:
> I've thought about this a bit more, and have a simple suggestion to offer.  What about, for bug fixes, requiring tests OR an increased number of signoffs?  We could bump it up by any amount depending on what we feel is the right balance, but I'd say starting with one more (a total of three), seems like it would bring meaningful improvement.  This could also then replace the "or it's too hard to write tests" cop-out clause, and thereby remove subjectivity from the process.  Bugs that are naturally too hard to write tests for will follow the multi-signoff route to entry.
>
> If, down the line, we see that our tests are still woefully inadequate, or our overall code quality is still insufficient, then we just keep bumping up the sign-off bar until we get a good balance.
>
> Thoughts?
>
>
> Dan



-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org


More information about the Open-ils-dev mailing list