[Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community

[David Cook]

I like the sound of this. As I mentioned in my other email, I think stability is super important. I rather a feature languish indefinitely than have an unstable system that is going to give people major problems and corrupt the integrity of their data.  

Of course, it can be tough to test some features in test environments. I think Brendan mentioned how sometimes they'll push a feature locally and then upstream it only when it's been proven at the local level. I think that this is also really good idea. I've done this from time to time as well, although usually for small things relating to display. I'm generally very hesitant to make local enhancements that affect data in any way. 

At the moment, I'm looking at adding an OAI harvester client again, and I'm developing against master. I thought about doing it locally and then pushing it up, but it requires too many database additions and I want it to benefit from community scrutiny.

I feel sometimes that we try to add too many bells and whistles. At this moment, there are 164 patches waiting to be tested. Only 41 of those are bugs.

Personally, I would love more attention shown to bugs than enhancements.

But again... that's just my two cents as someone with not a lot of time atm.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007

> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Owen Leonard
> Sent: Wednesday, 15 October 2014 11:23 PM
> To: Koha Devel
> Subject: Re: [Koha-devel] Proposal for a change in guidelines for the sign-off
> process in the Koha-community
> 
> > I’d like to put forward a motion for removal of the guideline that one
> > company shouldn’t sign-off on the same company's patches within the
> > community.
> 
> I think this is a good rule, and I think our current process has proved that by
> showing that with many different points of view looking at the code more
> issues can be found which need to be addressed before something is ready.
> 
> I realize how frustrating it is to have something big and hard to test languish
> in the QA process, but I think the right solution might be to get more creative
> about how to help things move along.
> 
> From my perspective as a bug tester the biggest thing I can say about it is to
> have good test plans. I mean really really good test plans.
> List, explicitly, every possible step that the tester could take to test the
> patch.
> 
> The obvious example here is Bug 6427 - Rewrite of the accounts system
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big
> patch that touches a LOT of files and involves one of the most mission-critical
> aspects of Koha's circulation functionality. Pushing it before it was properly
> tested could be disastrous for libraries who collect fines throughout the day.
> 
> The bug has a pretty good test plan, but is that enough? What else could we
> do to make sure it's ready for production? Perhaps set up a dedicated test
> instance with some good sample data, give out logins which give permission
> to circulate and collect fines, assign multiple days' worth of tests to be
> performed by multiple testers?
> 
> Getting volunteer testers is hard, and getting multiple volunteer testers is
> harder, but sometimes I think we need to take a more active hand in
> soliciting and promoting testing.
> 
>   -- Owen
> 
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : http://git.koha-
> community.org/ bugs : http://bugs.koha-community.org/