http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
Ian Walls <ian.wa...@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Signed Off |Failed QA --- Comment #36 from Ian Walls <ian.wa...@bywatersolutions.com> 2012-01-06 13:27:28 UTC --- I've been leery about this development for a few reasons: 1. it seems that, what we initially discussed for this is not what we got, as far as code. There was some BibLibre work that was similar, so that was used instead of implementing the idea from Mumbaï in it's entirety. 2. making changes to the way database updates are handled effects all versions of Koha. This process needs to remain stable at all costs. Thus any change must be most thoroughly tested 3. there is a rush order on this, which makes me uncomfortable. Yes, it would be nice to start the release cycle with a new method, but we're already well along the development timeframe for 3.8, and I think changing midstream is going to introduce more complications than it's worth 4. Frankly, I don't feel the need to rush this. This project offers no particular benefits to the end user. It's only really helpful to testers and developers. I'm all for making it easier to test patches, but not at the risk of breaking upgrades for any set of Koha users. I'd rather see this implemented in the next release cycle, so we have adequate time to plan and test. 5. Moving database updates into the atomic update directory is a good thing, for sure, but assigning them numbers makes them inherently linear, which we're trying to avoid. 6. I disagree with removing the Version check on every page. We're in an asynchronous web environment; the system could be upgraded while folks are mid-stream in their work (not a recommended practice, but one that we need to acknowledge as possible). If a database change significantly affects the structure of the area in which people are working, the information they are submitting/querying could become corrupted, or not work at all. The code and the database must be kept synchronous, at all times, with no need for manual action. Following is my counter-proposal for what a change to updatedatabase should look like. Marking as Failed QA for now. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/