https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271
--- Comment #286 from Victor Grousset/tuxayo <[email protected]> --- The problem is not to test the concept of delete flagging. The patches on this ticket well demonstrated that. Even without that already done, not sure that was ever a question. The difficulty is that biblio, biblioitems, biblio_metadata, and items (and their counterpart) are used in a lot of places in Koha. Even taken individually that is still **a lot** of places to change, **test** and review. Really a lot of workflows to check for regression. Automated test coverage doesn't seem enough. Not sure there is any way to be sure enough to not miss many usages of biblio, biblioitems, biblio_metadata, and items. And thus avoid shipping a few regressions in edge cases. That needs to be weighted against the benefits of this refactoring. (In reply to Katrin Fischer from comment #281) > Securing funding is one part, but the other part is to come to a decision as > community about these change and ensure that there will be enough > time/committment to see it through, if it's decided to do this. [...] > I am not fully persuaded on benefits vs. work/risk yet, but would be open to > be persuaded. +1 , money can buy a provider to have someone do the painful task of changing a lot of the table usage everywhere. But it still needs other people in the community to test and review it. And the benefits that refactoring need to be weighted against the huge cost in testing and QA. Given the current huge bottleneck on signoff (141 waiting tickets (25 bugfixes)) and QA (168 tickets, (26 bugfixes)) including other refactorings, the benefits of this one need to be big also. In the long run, which alternate timeline Koha **can be expected** to have the less bugs, cleaner code, most features? That depends on the benefits of the refactoring here. Even finding a way to do that incrementally (something with DB views maybe?) to avoid the need of pulling out of massive effort spike won't make the problem of overall testing and review effort go away. A way to make the question way easier is to get literally a dozen or more **weekly active** librarians and Koha sysadmins to do some patch testing. Making the bottleneck mostly go away. Librarians, rise up! (and library executives: let the workers improve their tools!) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://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/
