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) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list Koha-devel@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/