On Wed, Nov 30, 2011 at 12:50 AM, Paul Poulain <[email protected]> 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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
