[Koha-devel] "freezing" koha 3.0

[Joshua Ferraro]

On Fri, May 2, 2008 at 5:32 AM, Paul POULAIN <paul.poulain at free.fr> wrote:
> 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.
Agreed.

>  > 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 like the idea proposed by someone, of having the release manager
'retire' and take over as release maintainer; stepping aside for the next
release manager. So that would mean I'd be the release maintainer for
3.0 ;-).

This leaves open the question of who should be release manager of
3.2. I believe Galen would be in the best position of all of us to take over
the role right now:

1. he only works on programming Koha, doesn't have to worry about any
business or other concerns

2. he knows the code inside and out

3. he's demonstrated over the past months that he's very careful and takes
both MARC21 and UNIMARC concerns into consideration

4. he has vast experience with library standards

Certainly up for more discussion, but those are the top reasons I believe he'd
be the best candidate for 3.2 RM.

>  >>  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...
This question has come up before. The ultimate question is, who is the Koha
project for? Some projects, take the Linux Kernel for example, the project is
designed primarily for distribution packagers to create operating systems that
can be used by users (Debian, Fedora, etc.). Other projects, for example,
Firefox, are downloaded and used directly by users. The Koha project has
examples of both types of 'users'.

I think that, especially since we have a lot of direct users downloading and
installing Koha, it's especially important that we package it in a way that is
usable by the greater community; and that any features that are developed
are actually usable by non-programmers.

>  >>  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.
Perhaps. However, do they use authority control? Do they use
IndependentBranches?
Do they use LDAP and SIP2?

There are definitely libraries running on Koha 3.0 beta, no question.
And no doubt
the core functions work bug-free enough; however, that's no reason to assume
that 3.0-stable should be released. When we put out a stable release, we are
telling the community that the features advertised can be used by them.

>  > 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
Perhaps Ryan can expand on this..

>  >   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
well, if not added to 3.0, it will force us to put it live for several
customers,
who can't wait for 3.2 to have it. This will mean that LibLime customers won't
be running the exact code as the release. It's a lot of extra overhead for us
to maintain two branches, but perhaps it's necessary.

Since the code is already mostly written, and will be heavily tested, I don't
see any harm in adding it.

>  >   f. changes to support linking icons to authorized values
>
>  I definetly would not add that to 3.0
Done already. It was the counter to the itemtype icons added a while back. Most
US libraries find item-type icons to be useless. They are more
interested in linking
icons to bib-level information like audience, format, etc.

>  >   g. cleaning up names of system preferences, to do as a single DB update
>
>  I definetly would not add that to 3.0
I think we could negotiate on this point. However, I'll just point out
that if we
delay this change until 3.2, all of the 3.0 libraries will have to
learn a whole new
set of vocabulary for system preferences -- it could be pretty confusing.

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