[Koha-devel] "freezing" koha 3.0

[Paul POULAIN]

Joshua Ferraro a écrit :
>>  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 ;-).

I've nothing against that personnaly.
I'm just wondering whether you'll have the time needed for that. In 
fact, I think you're already doing too much things (LibLime CEO, 
translation manager, Release Manager, ...). sometimes, we need 4 or 5 
days to have a patch applied (or rejected).
Even if the amount of time needed will decrease, I just wanted to ask.
Note that I don't apply for this role, as we (BibLibre) are already 
overwhelmed.
We (BibLibre) hope that hdl will be able to dedicate a little bit more 
time in the next months for community role. For instance, the role of QA 
manager means almost nothing in real life. I'm sorry about that, we 
should speak of how to introduce the QA role in the git process.

> 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:
> 2. he knows the code inside and out
I agree

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

> 4. he has vast experience with library standards
I agree

You can add 5. he's a nice guy always available on #irc & very community 
oriented.

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

That's the only point I have questions about. (see later in this mail)

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

I don't see anyone else to propose atm anyway.

>>  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?
yes

> Do they use IndependentBranches?
yes

> Do they use LDAP and SIP2?
no.

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

my experience show me 2 things :
- there are *always* consequences you don't imagine when you code something.
- that's the best way to never have a stable release. Look at your mails 
5 months ago. You've announced that you'll just ad "this and that" (mail 
on koha-devel when releasing alpha or beta). Now you must add another 
feature for another customer. In 2 months, there will be another one. 
And you can be sure every addition will result in a new unstability. I 
bet whatever you want (for both new customer need & unstability)

Some months ago, you told me "LibLime has decided to deploy only 
official version of Koha to hit customers". I was very happy with this 
news. I'm not sure anymore that i'm so happy.
The risk, with this decision and the pressure your customers put on you 
will be to have no more a time based release or a feature based release, 
but a "LibLime Customer needs" based release. Which would be a real 
problem for our (BibLibre) business, and for the community as well.
And, to say my deepest thought, I think this will result in never 
releasing a stable version at all.
Releasing a stable version means "stop running".

Another way to say that : you wrote you planned to release 3.0 in march, 
and 3.2 in june. aren't you planing in fact to release directly the 3.2 
in june (I mean a version numbered 3.0 with all the features you planned 
to include in 3.2 previously)

On the other hand, having a LibLime version of Koha and an official 
version will be a shame as well, as I understand you don't have so much 
ressources to put on doing things twice & maintaining 2 releases.

My feeling (as BibLibre CEO), is that there are 2 cases :
- very time pressuring customers : have a specific release with the 
feature they want without waiting for an official release. And include 
in the proposal the fee to reintroduce the feature in official version 
later.
- other consumers : be cheaper, and tell them the feature will be 
available in version X, that will be ready in Y months.

That's how we plan to do for our 3 large projects I spoke of in my 
previous mail : the features will be in an independant git branch, that 
we will synch in koha official asap, but after the customer deployment.
(and the git repo being available to anyone interested. The git repo 
with the new acquisition module -announced here in january- should have 
been opened for weeks now, but I couldn't find time to do it. sorry & 
shame on me)

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

I agree it has already be done... And it has broken something !!! 
Authorized_valued can't be edited anymore.
hdl has submitted a patch yesterday if I don't mind.
sorry to be hard on that, but almost everytime we add a feature those 
times, we introduce some kind of unstability !

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

I agree on the point you point. But I think it's less important that 
going to stability.
And i'm also really sure it's impossible to fix that without introducing 
many problems. Really sure

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