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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
