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