[Koha-bugs] [Bug 20271] Merge deleted biblio, biblioitems, biblio_metadata, and items tables

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271

--- Comment #286 from Victor Grousset/tuxayo <victor at tuxayo.net> ---
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.