[Koha-devel] "freezing" koha 3.0

[Galen Charlton]

Hi,

On Tue, Apr 29, 2008 at 1:51 PM, Eric Bégin <Eric.Begin at inlibro.com> wrote:
>  The main point of tagging a version as Beta is that features complete.
>  This doesn't mean that there are no bugs.  Beta versions still have
>  bugs, knowned and unknowned.  However, the goal of a development team is
>  to kill those bugs as soon as possible to ship an official release.

A *good* official release - hopefully we can optimize for both speed
and quality (at the expense of sleep?) over the next few weeks. ;)

>  The first thing is to revise their severity.  I agree with Paul's when
>  he says that if there is a workaround, it should not be a blocking,
>  critical or a major bug.  If, at release time, there are important KNOWN
>  bugs in Koha with workarounds, they should be list in the Known issues
>  section.

While I think the principle proposed here is OK, we should exercise
judgment about whether any given workaround is suitable - a workaround
that is obvious to the user and requires little extra extra effort to
implement is one thing.  A known workaround that imposes an unusually
large amount of time or effort to use should not justify lowering a
bug's severity.

>  Blocking, Critical and Major bugs must be fix if there is no workaround.
>  Other bugs (normal, minor, trivial & enhancement) have to be fix only if
>  there are no major impact on Koha.  If there is a risk of making any
>  part of Koha unstable, I suggest that this bug is pushed to the next
>  point-release (in our case 3.1).
>  In that case, it is the role of each and every developers to define the
>  risks of a fix.
>  The role of the Release manager and the QA manager to decide if the bug
>  fix worth to be implemented vs the risk of making Koha unstable.

One issue we have to think about is *measuring* stability.  Courtesy
of Andy, we now have a testing framework that permits us to write unit
tests that can act on a test database.  As bugs get fixed,
particularly for the 3.0 release, I encourage all developers to write
and submit regression tests to accompany each bugfix.  If anybody has
questions about how to write test cases that use Test::Class and the
KohaTest framework, please contact me or Andy via e-mail or on #koha.

>  Every bugs fixed in 3.0 should also be fixed in 3.1.  Thanks to git to
>  make it easy.
>
>  I'm against bugs' backporting.  If a bug is found after the release, it
>  can be fixe either with a patch or in the next point release, depending
>  of the bug's severity.  Of course, if someone wants to fix it in its
>  library, he can do it using git.

I disagree, at least in the general case - some bugfixes we can and
should backport to 3.0, at least for as long as 3.0 is considered to
be maintained.  In particular, security bugfixes must be readily
available, and not just as patches floating around koha.org.

That being said, I of course do not advocate making a policy of
backporting new features or minor bugfixes.  In any event, we can
postpone making final decisions about maintaining 3.0 after its
release.

>  I really think that we should try to have an official release every 4 or
>  6 months, which is 2 or 3 releases a year.  If a feature is added later
>  on and it didn't fit the next release schedule, it's just to bad.  It
>  will have to wait the next release.

I agree that increase the frequency of releases is a good idea.
However, I object to setting release schedules in stone - we must find
a balance between shipping often and shipping when ready.

>  Only one thing left: who should put the seal of approval about when Koha
>  is ready?
>
>  Usually, this is the role of the QA Manager, which is now Henri-Damien
>  if my memory serves me well. (btw, the Koha 3.0 Roadmap still show Chris
>  C. as QA manager)

I think the QA manager could reasonably have a *veto* over declaring a
general release.  However, I don't think the QA manager should be able
to unilaterally *declare* the release -- that should be the decision
of the RM and QA jointly along with a consensus (or at least
preponderance) of the active developers.

What's the way forward?  Here's my proposal:

1. Announce a freeze on the database schema and new features for the
end of next week.  There are a few things LibLime would like to slip
in now to help clear our immediate queue,  including:

  a. a few changes to import_batches and friends to improve record
overlay - I will submit a patch for this later today
  b. possible changes to biblioitems to remove call number fields -
this was briefly discussed on #koha, but a general RFC is needed
  c. one change to accountlines to implement dropbox returns
  d. a change to labels.  As noted earlier today, this module appears
to need a lot of QA effort to prepare it for 3.0.
  e. a change to borrowers to support alternate IDs - RFC to come
  f. changes to support linking icons to authorized values
  g. cleaning up names of system preferences, to do as a single DB update
  h. any other DB schema changes that other developers are working on right now.

2. Upon freezing of the database schema, start a 3.1 branch for new
work to be added between now and when we start formally planning 3.2.
I'm using "branch" advisedly - I don't yet have a clear picture of
exactly how we should set it up in git.  However, I think it is
important that 3.1 exist so that we can keep a linear stream of
database schema changes.

3. Put the 3.0 branch into bugfix-only mode.  Focus our energy on the
release.  Besides clearing the bugzilla queue, areas LibLime is
especially interested in making sure are stable for 3.0 include SIP2
support, LDAP integration, security issues (e.g., scrubbing and/or
escaping of HTML tags in patron comments and the like), reports, OPAC
RSS feeds, and fully testing the 2.2 to 3.0 upgrade process.

4. Release 3.0.

5. Plan 3.2.  As far as I know, we're using even revision numbers for
release intended for production, so the 3.1 line of development would
end up becoming 3.2 at some point.

Step 3 will need to be planned in more detail, of course, and tied to
specific dates.

Regards,

Galen
-- 
Galen Charlton
Koha Application Developer
LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709