[Koha-devel] About Release process

[Brendan Gallagher]

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 <
colin.campbell at 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 at ptfs-europe.com
> skype: colin_campbell2
>
> http://www.ptfs-europe.com
> _______________________________________________
> 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/
>



-- 
---------------------------------------------------------------------------------------------------------------
Brendan A. Gallagher
ByWater Solutions
CEO
Headquarters: Santa Barbara, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120712/82e32e93/attachment-0001.htm>