[Koha-devel] updatedatabase (bug 7167)

[Chris Nighswonger]

On Wed, Nov 30, 2011 at 12:50 AM, Paul Poulain
<paul.poulain at biblibre.com> wrote:
> Le 24/11/2011 17:02, Chris Nighswonger a écrit :
>> On Thu, Nov 24, 2011 at 10:27 AM, Paul Poulain
>> IMHO customers who want features before master inclusion is really a
>> vendor issue, not a community issue.
> Chris_n, I disagree (strongly) with you here: according to me, anyone
> issue is important. We should not discard anything just because it's "a
> vendor issue". Well, at least when the ppl who had a problem comes with
> a patch!

I stand by my original statement. Issues which are fundamentally
vendor/client are not and should not be the
driving/motivating/controlling force behind the way the community
moves. If this were the case, chaos would ensue as we change direction
attempting to "fix" vendor/client issues, etc.

I think you my be interpreting my statement as "anti-vendor." As I
clearly stated: it is not.

We do need to make adjustments to make the life of a vendor as easy as
possible. 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.

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

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

> For example, Eliott' thread started a few hours ago is interesting:
> frankly, having pain merging the hourly loans patch is "a library issue,
> not a community ones". Well, in fact, I don't think so. Solving problems
> and making ppl happy is important. That's how we will attract more
> developers.

It is a pain. And that pain may be getting to a sufficient level to
motivate some to either test/sign-off/QA or to pay to have it done...
problem solved.

Until that pain reaches that level, it will continue to be a pain.
Whatever one's viewpoint, In a majority rules context, the majority
does not always move the direction of the individual. Under those
rules, it is incumbent upon the individual to create a majority. No
single vendor represents a majority.

The rules for acceptance of a feature into master have been well
defined at this point in our history. Sign-off, QA approval, and
you're in. I'm not sure where hourly loans is hung up in this process,
but I don't see why it has to be if someone wants to throw time or
money at it.

Kind Regards,
Chris