On Thu, Jul 12, 2012 at 8:43 AM, Colin Campbell
<colin.campbell@ptfs-europe.com> 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)
colin.campbell@ptfs-europe.com
skype: colin_campbell2
http://www.ptfs-europe.com