[Koha-devel] "freezing" koha 3.0

[Paul POULAIN]

Joshua Ferraro a écrit :
> First off, as usual, you raise excellent points.

Thanks to say that.

> I think there
> are a few questions that we should ask ourselves directly:
> 
> Is Koha 3.0 stable enough to be released?

Here in France, if I don't mind, we have 6 libraries running live with 
Koha 3.0beta2

> If not, what must
> be fixed before it's ready?

which does not mean there are no more bugs. but none of them can't be 
"workaround-ed".

> 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.

I agree. Even if we had previously seen that the term (BibLibre, french) 
of "useable" is not the same than your (LibLime, USA).

> 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.

Important point the DB. The 2nd one being the API.
Previously, I had decided to release 2.0 and 2.2 after something like 3 
1.9.x release without any change in the DB or in the API.

> 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. 

I would add that some of them could have a status lowered to "normal" by 
an easy workaround that would not solve the problem on the long term, 
but give us a solution for the short term.

> (XXX bugs in bugzilla, give stats).
bugs.koha.org tells me :
- 302 bugs
- 14 BLOckings
- 8 CRItical
- 12 MAJors
- lots or NORmal, MINor, TRIvials, and ENHancement requests

I suspect some of the BLO/CRI/MAJ one are already solved or have an 
acceptable workaround that could lower their severity. for example : 
1621 and 1719 ( => XSLT), 2022...

> 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.
see my opinion below about that
> 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, 
atm, our (BibLibre) most common daily work is deploying the v3 for our 
customers (& writing answers to RFPs)
> 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;
because that's the best way to have a never stable software !!!
> 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
I don't consider that the features i've pointed are "small". And even a 
small feature is a risk for stability. The only think I could easily 
live with is a new report (as reporting means only reading things). When 
a code write something in the DB, there is a risk. When an API changes, 
there is a risk.
> 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.
I think so.
> 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
my proposal (summarized) :
git-branch koha30 => to create a branch koha for koha 3.0, that is for 
strict bugfixes only

for developpers :
- have a git repo from git.koha.org (say in ~/head)
- clone the local repo himself : git clone ~/head ~/stable
- cd ~/stable
- git checkout -b koha30 origin/koha30 => to have ~/head reflect the 
stable version

work on HEAD : as usual

work on koha30 :
- cd ~/stable
- git pull to update the stable version (in case a patch came from 
official repo
- do your stuff & commit it
- git-format-patch git-send-email patches30 at koha.org (new mailbox)

The question is : how to work with patches that could go to the other 
branch... the answer is ... cherry pick.
the HEAD Release Manager should be responsible for applying a patch from 
3.0 to head if needed. Or the 3.0 Release Maintainer.

Cherry picking patch from HEAD to 3.0 should almost never happend imo.

> 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?
I don't understand what you say here.
> 
> 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.
I vote for a specific mailbox & 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).
good question. Your opinion ? I don't have a definitive one I think
> People may
> intentionally not want new features.
???
> 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. 
I agreed, so I started the discussion ;-)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : 04 91 31 45 19