[Koha-devel] "freezing" koha 3.0

[Paul POULAIN]

Galen Charlton a écrit :
>>  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.

I think we also have to separate a bug that results in an "unworking 
feature" from a bug resulting in an "data corruption".
For a "data corruption bug", even a workaround is not acceptable.

Let me give you an (small & fixed) example : the renew button. There was 
a place were it was not working well : the renew counter was 
incremented, but the renew date didn't change.
Not blocking, as there are at least 2 other ways to do a renewal.
Bug blocking because the offending button result in data corruption 
(although small)
In this case, I prefer an "internal server error" without data 
corruption to such a behaviour !!!

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

imho, we need a "Release Maintainer" that will be responsible for 
deciding wether a patch has to be backported or not.


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

what about version number. We are supposed to be numbered like linux 
kernel : odd numbers = unstable, even numbers = stable.
so why couldn't we release 3.1.x every month/almost stable 
milestone/when the RM think it's worth
and release 3.even.x twice a year ?

It's an important question that LibLime and BibLibre will have -for 
sure- to answer :
when a feature is ready in git, but not officially released, should we 
have specific branches for that specific customer of just say "it's 
almost ready, but you'll have to wait for next official release".

Depending on the case (sponsored dev, signed timeline...) I think the 
answers will differ. but the question is VERY important (that's the 
businessman who speaks)

Let's me explain : atm, BibLibre has 3 major projects. One started, 2 
waiting for customer decision.
If both reaches the "contract" phase :
- that's very good news, we will have to hire 3 or 4 more people...
- those customers have must-respect timelines (at least for one of them).
- those projects will require the developpment of many new things.
will we :
- work on a specific branch, then merge
- work on main branch directly, at the price of a risk with the timeline ?

I don't see clearly the answer to this question. If ppl from LibLime 
have an idea about this ...
joshua, that's probably something we can speak of in Lyon, in june.

We have to organize the future of Koha in 2 ways :
- coordinate the community & help anyone that want to be involved
- coordinate our businesses projects. We are 2 major companies (I mean 
BibLibre is a major one ;-) ), we will have to find how to coordinate 
our businesses.
LibLime has won WALDO and announced that "WALDO has commissioned LibLime 
to substantially enhance Koha to meet the requirements of academic 
libraries"
BibLibre has announced a new acquisition system, that is underway (see 
mail here some months ago)

How to deal with those projects, the coordination of our businesses, and 
the community aspect of all of this...

>>  Only one thing left: who should put the seal of approval about when Koha
>>  is ready?

I think it's :
- the Release Manager
- the Community general opinion

As I said, 6 or 7 libraries here are running 3.0 live. All of them are 
happy with it.

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

I prefer consensus.
And I think the consensus will be quickly reached if we branch, and stop 
working like mad on patches.

every morning, I spend between 10mn and 1 hours to look at patches, do 
some testing... because I know that sometimes some patches can break 
some things.

> 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
OK
>   b. possible changes to biblioitems to remove call number fields -
> this was briefly discussed on #koha, but a general RFC is needed

maybe OK. Although i'll wait for RFC. I think what we have now can be 
kept as is and just unused ?

>   c. one change to accountlines to implement dropbox returns

I still don't have understood that it is, even after some kados 
explanations on #koha

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

agree

>   e. a change to borrowers to support alternate IDs - RFC to come

I definetly would not add that to 3.0

>   f. changes to support linking icons to authorized values

I definetly would not add that to 3.0

>   g. cleaning up names of system preferences, to do as a single DB update

I definetly would not add that to 3.0


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

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