[Koha-devel] updatedatabase (bug 7167)

[Paul Poulain]

Le 30/11/2011 15:54, Chris Nighswonger a écrit :

> We do need to make adjustments to make the life of a vendor as easy as
> possible.
OK, so we agree. I just want that ! (is my english saying something so
different than this ?)

> But rushing a db update change because Biblibre, or any
> other vendor, has clients who run non-master modifications, is not at
> all a valid option.
agreed. And I don't want to rush pushing. I just rushed proposing
something. Now, please test !
I want to do this quickly not because our customers are in a hurry, but
because i'm starting pushing for 3.8 and I want to have a clean
situation, not a mechanism that is the old one for the first 3 months,
and the new one for the last 3 months.

> Having said that, if you have the proposed db update changes throughly
> tested, debugged, and production ready, then by all means, let's
> implement them in master.
OK, so, feel free to test !

> You will carefully recall my objections:
> 
> 1. We should not introduce this "feature" without proof-of-concept
> *and* through testing. This "feature" over any other must be as stable
> as we can make it when it is introduced into master simply because
> instability could greatly slow down development.
agreed. And that's why we made so many tests (Jonathan and me) and took
care of some problems that have been noticed.
Now, I think I've submitted a patch that works quite well, with
documentation.
So please test & report any issue you could find !

> And while we are
> speaking of vendor/client relationships, imagine what problems ensue
> for vendors who have clients running over master when master breaks?
> Well, the vendor knows the risk and assumes liability for it in those
> cases, but you can see where we would be if we suddenly judged every
> move by vendor/client relationships.
agreed (even if we don't have any library running master)

> 2. If the db update improvements are introduced into master during the
> 3.7.x development cycle, they must be back ported to the 3.6.x branch.
> The only condition I will withdraw this objection under is if this
> "feature" is pushed immediately prior to the release of 3.8.0.
I don't understand why we need to backport this new mechanism.
With the new system, we can address separately updateDB patches for
stable and master version (with the same patch, I don't mean in 2
different patches). I think that's how we must do it.

Let me give you an example with actual mechanism:
Day 1 => updatedatabase for bugfix passes QA and can be pushed
Day 2 => updatedatabase for a new feature passes QA and can be pushed
Day 3 => updatedatabase for a bugfix passes QA and can be pushed

How will you deal with D2 patch ?
ATM, you'll have a problem, isn't it ?
D1 = should be 3.07.00.001 on master
D2 = should be 3.07.00.002 on master
D3 = should be 3.07.00.003 on master
except you're not supposed to push D2 patch on stable branch.
(or there's something i'm missing)

> I think that as a non-vendor, our views will always be in a tension.
> But that tension should be constructive in helping to maintain a
> proper balance in the best interest of the community.
+1


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08