http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5786
--- Comment #72 from M. de Rooy <[email protected]> --- Preliminary QA Comment: I appreciate that already a huge amount of time went in this report for development and .. testing. With a huge patch like this and a queue of 140 signed off patches, it is very likely to happen that your patch will not apply as unfortunately is the case right now.. Smaller patches under several reports will have a better chance. I saw a test plan from Melia. That is very good, but does it really cover all changes? Including 341 lines in Reserves module? Just saying this, because I realize that rebasing this is a nightmare. But testing and QAing either :) I also note that we have several developments in the queue in the same area. This morning I looked also at 8367 (maxpickupdelay). It appears that your development is older. Some communication there could prevent further duplication of work? Lots of whitespace errors. Could you cleanup when needing to rebase? CONFLICT (content): Merge conflict in opac/opac-reserve.pl CONFLICT (content): Merge conflict in koha-tmpl/opac-tmpl/prog/en/modules/opac-reserve.tt Funny conflict there: [% ELSIF ( bibitemloo.bib_available ) %] No available items. [% ELSE %] <<<<<<< HEAD [% UNLESS ( bibitemloo.bib_available ) %] <div class="bibmessage">No available items.</div> CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Looking at your updatedatabase changes, I wonder why you do not remove the pref for maxpickupdelay when adding it to issuing rules? Like you do for shelf holds and item holds. This could create confusion.. Setting to Does not apply -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] 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/
