Hi, All --
A small group of small NH libraries has co-sponsored a small
enhancement to get its feet wet in the Koha development world:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14365
As I understand it, once a patch has been signed off & passed on to
QA, it can hit a bottleneck a
This patch already is in PQA.
Your question is interesting btw..
Van: koha-devel-boun...@lists.koha-community.org
namens Cab Vinton
Verzonden: woensdag 29 maart 2017 16:16
Aan: koha-devel@lists.koha-community.org
Onderwerp: [Koha-devel] Development/ QA protoco
Hi Cab,
I would not expect a QAer to be paid (by the sponsor of the enh) to review
a patch, I'd call that more corruption / conflict of interest than
sponsoring :)
On Wed, 29 Mar 2017 at 11:16 Cab Vinton wrote:
> Hi, All --
>
> A small group of small NH libraries has co-sponsored a small
> enhan
On Wed, Mar 29, 2017 at 10:30 AM, Jonathan Druart
wrote:
> I would not expect a QAer to be paid (by the sponsor of the enh) to review a
> patch, I'd call that more corruption / conflict of interest than sponsoring :)
Ah. Hadn't thought of it that way. Good point. Not sure there's an
easy way arou
The developer is supposed to estimate the cost of the development including
the QA process and the different steps of submission.
A (good) developer must take care of most of the project's requirements and
follow the guidelines.
He will also provide tests for the change he made, write a valid and
c
Yes, all makes perfect sense, Jonathan.
I suspect the way in which projects work their through QA is opaque to
most libraries, and like any client, they're always happy when their
projects get lots of attention, move through quickly, etc.
I believe at any given time there are dozens of patches so
In my opinion the QA queue (as well as the signoff queue actually) should
be processed by bugs severity: blocker, critical, major, others. It's a
"should be", not a "is"...
And then the new enhancements, features.
The way the patch is written, the length of the diff, the author of the
patches (yes
>. I believe the vast majority have P5 priorities & low severity
> (i.e., are "enhancements" rather than critical or major).
Note that the priority scale (P5-P1) is not used. I agree with
Jonathan's process of evaluating the priority of bugs based on
severity. It should also be understood that sim
Thank you, Owen.
If the priority scale is unused, then seems like a good candidate for
removal/ suppression from Bugzilla, if possible.
Severity is definitely a good first pass. As I mentioned earlier,
however, the vast majority are "enhancements", so QAer's would have to
move on to other factors
There is a "Patch complexity" field, but I personally do not use it (I
should yes).
On Wed, 29 Mar 2017 at 17:48 Cab Vinton wrote:
> Thank you, Owen.
>
> If the priority scale is unused, then seems like a good candidate for
> removal/ suppression from Bugzilla, if possible.
>
> Severity is defin
On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart
wrote:
> There is a "Patch complexity" field, but I personally do not use it (I
> should yes).
I've see. Don't think anyone else uses it either :-)
Would be cool if it auto-populated with the number of new/ different
lines in the patch ... Pretty
The complexity does not depend on the size of the patch :)
A one line patch can be much more complex than a 1k lines patch
On Wed, 29 Mar 2017 at 18:00 Cab Vinton wrote:
> On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart
> wrote:
> > There is a "Patch complexity" field, but I personally do not
I always fill patch complexity. Also for patches that I qa.
And not filling that field (and/or other fields) gives it a lower priority.
And yes, the number of lines is not the same as complexity.
-Oorspronkelijk bericht-
Van: koha-devel-boun...@lists.koha-community.org
[mailto:koha-devel
13 matches
Mail list logo
