Hello - We have recently hired another Developer (Elliot Davis - libsysguy ;) ), who is charged with creating a more integrated testing suite for ByWater and getting/challenging some of our partners to complete testing that isn't automated already or would be difficult to automate.
As for the options... I totally agree with Colin that the releases are an Event and should be promoted as an exciting EVENT. That being said, I would not want to delay any major new features being put into a new release no matter the time (we can never really fight the timing of things). I think my thought and my response is that We (ByWater at least) need to do better testing (what does that mean - well we are still working on that). I think the thing that I struggle with is the definition of a "Freeze"... Please speak up and correct me if I am wrong here. This is what I think it means currently - if something has an enhancement bug listed (i.e. the idea is out there before the freeze date) - then it could still be included as long as the developer gets the code onto the bug report sometime around the freeze date. What I think should happen - The code should be pushed to master before the freeze date - nothing new after the freeze date.... (I hope that makes sense - with what I am trying to explain). But as others have said - this is really up to the RM. Here's a hint - whomever is going to be the next RM, please include a definition of "Freeze" for me ;) Thanks, Brendan On Thu, Jul 12, 2012 at 8:43 AM, Colin Campbell < [email protected]> wrote: > On Thu, Jul 12, 2012 at 06:54:36AM -0500, Elliott Davis wrote: > > I think I too side with option 1. > > > Releases are inherently evil things, (like all deadlines). There is a > temptation always to pack stuff in there to make a release an event. I > dont think having beta releases helps ( or skipping .1 releases in > deployment) because a lot of that testing just does not occur until the > release goes out into the world no matter how good our intentions are. > How can we improve things, well any big changes should go into master > sooner rather than later. The longer big changes are promised the more > pressure the RM is to ship them. The key task for the RM is really > deciding what's not yet been proved, and should not make this iteration. > We do need lots more tests. We rely on far too much untested > functionality (which may mean we're wrong in our assumptions of what it > does) > We have a specific problem that it is much easier to add bits of > functionality to the system, bits that up the level of entropy in the > code base, rather than make the strategic changes that build reliability > into core. > A specific problem is that we tend to test functionality of an > enhancement not necessarily how that enhancement integrates with the > eco-system of Koha and its these kind of conflicts that tend not to > surface until its been deployed in the real world. > Colin > > -- > Colin Campbell > Chief Software Engineer, > PTFS Europe Limited > Content Management and Library Solutions > +44 (0) 800 756 6803 (phone) > +44 (0) 7759 633626 (mobile) > [email protected] > skype: colin_campbell2 > > http://www.ptfs-europe.com > _______________________________________________ > Koha-devel mailing list > [email protected] > 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/ > -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Headquarters: Santa Barbara, CA
_______________________________________________ Koha-devel mailing list [email protected] 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/
