[Koha-devel] "freezing" koha 3.0

[Eric Bégin]

Hi everybody,

Here are my thoughts on the topic.  They are not based on Koha-specific 
development, but on my past experiences as software developer manager.

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.

Now, which bugs must/should be fixes?

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.

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.

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.
> The only think I could easily live with is a new report (as reporting means only reading things).
This time, I disagree with Paul :)  We must think about 
translation/documentation.  If we want to be able to ship Koha in the 
next few month (< 3), we must stop implementing ANY features, cosmetic 
one included.  It's now time to kill bugs and stabilize Koha.
> 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).
I doubt that we can release another version 2 months after a major 
release.  We should plan as much as possible what will be part of the 
next releases. 

This planing should included:
- What major features will be included in this release (on a client 
point of view)
- How long will it take to implement them
- Who is responsible of that feature.

Only once this evaluation is done that we can give an educated guess on 
a possible release date.  Once those major features are implemented, we 
then must start stabilize the version for the 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.

Of course, nothing prevent anyone to use the latest git in production at 
anytime.

Remember that at the moment, we must all focused on SHIPPING Koha!  It's 
been at least 2 YEARS since I read about the 3.0 release.  It doesn't 
really make sense in term of software development.

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)

Wow, I didn't expect to write so much stuff, but I think that I was 
inspired :)

Have a good day!

Eric

Paul POULAIN wrote:
> 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 ;-)
>
>