[Koha-devel] "freezing" koha 3.0

[Joshua Ferraro]

On Mon, Apr 28, 2008 at 1:05 PM, Paul POULAIN <paul.poulain at free.fr> wrote:
> Hello,
>
>  I begin to be really troubled by all those new features added in the
>  main trunk...
>
>  I think we really should stop hacking koha that much & work only on
>  stabilizing things. And by stabilizing I mean "stop adding anything new,
>  strictly, really strictly, just fix things that have to be fixed"
Hi Paul et al,

First off, as usual, you raise excellent points. I think there
are a few questions that we should ask ourselves directly:

Is Koha 3.0 stable enough to be released? If not, what must
be fixed before it's ready?

This question has to do with what we are saying when we 'release'
software as 'stable'. My assumption is that the reason to
release is that the software is ready to be deployed in production
environments; it symbolizes a point at which we believe that the
implemented features are usable, and that the software is ready
to be put into 'maintenance' mode, where only bugfixes and
security patches are to be applied.

Presumably the users of that version will expect to get some
mileage out of a stable release, as opposed to running something
that is in 'beta' mode, where bugs are expected to turn up on a
regular basis. We also assume that the DB is stable, and that
documentation and installation/upgrade procedures are in place.

Assuming we're all on the same page there, how to proceed?

There are clearly blocker bugs on bugzilla, for some of these,
a bugfix might look a lot like a rewrite of much of the
functionality. (XXX bugs in bugzilla, give stats). Should that
be done in 3.0 or a future version? If in a future version,
do we back-port those bugfixes to the 3.0 version? Who is
responsible for maintaining that 3.0 version, for how long,
etc.

Obviously, as you've alluded to, none of us can just work on
bugfixing. Many of us also have new features that we must
create, which brings us to the next question: why would we
want them to go into 3.<futurenumber> instead of 3.0, since
3.0 isn't stable; and assuming that  I agree it should go into
3.2, how do I get it there? How is the process managed?

Until now, with the 3.x repository, Small features have
been added in conjunction with major bug fixes, primarily
because we haven't been able to afford the maintenance
overhead of maintaining two Koha branches; we may be at a
point where this is now possible given existing community
resources; or perhaps we can arrive at an alternative to
running more than one branch or head of Koha.

Clearly, while we have a very well-thought-out process
for installing and upgrading koha, as well as releasing
from a HEAD branch, we do not have, and have not defined,
what the process becomes when we branch that needs to be
specified/defined before we jump in with a final
release and start adding stuff to a 3.1 or 3.2 branch.

It may be ovious to git experts and previous RMs what the
process is for branching, then working in the new environment
with branches, but most of our developers, myself included,
haven't had experience with that, so we need to document it
just like we did with the wiki page on git_usage.
In fact, we should actually do some dry runs with branching
i.e., make a copy of the git repo, set up brances, run
through scenarios involving dealing with bugfixes and
enhancement patches

On the other hand, can we get away with tagging releases
for a few more releases until things stabilize? That is,
can we just say that we work against MAIN/HEAD and tag
releases, and all bugfixes and new features go into the
next version?

How about managing patch submissions? Lets say you develop
against rel_3_0-stable ... and you submit a patch to
patches at koha.org, how do patch maintainers know it's for
rel_3_0-stable and not MAIN/HEAD/ (maybe git takes care
of this for us, I don't know). Maybe we simply don't
accept patches for rel_3_0-stable or perhaps we have
a separate mailing list.

How will these decisions affect the upgrade process for
users that expect the 'stable' release to be stable (if
we release 3.2 in two months for instance). People may
intentionally not want new features.

These are just a few of the issues surrounding this topic
that I've been able to come up with, I'm sure others can
come up with more.

Also, I think this issue is currently too large to hash out
on #koha, particularly if we get all of the active developers
invovled. I would prefer that we not immediately jump to an
IRC meeting, but instead give people a few days to discuss
over email and hopefully reach consensus. With any luck,
the IRC meeting will end up being more of a confirmation
and discussion of a decision made over koha-devel.

So ... let the discussions begin!

Cheers,

-- 
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS