The hottest day of the summer so far was drawing to a close and a drowsy silence lay over SourceForge...
... when Koha 2.0.0pre1 was released. RELEASE NOTES ============= This release add many bugfixes, and some improvment in z3950 and repetable fields management. It has been placed in the "unstable tree" because there are still some bugs. But it's fully usable, and should not be modified a lot until a stable version is released. PACKAGE NEEDED : --------- Nothing new. Note MARC::Record has new releases, but older one (1.26) works fine. DB modifications : --------- * added field in aqbudget, primary key : aqbudgetid tinyint(4) NOT NULL auto_increment PRIMARY KEY (aqbudgetid) * added field in systempref : options text * bibliothesaurus field father changed to char(80) (was bigint) added full text index : FULLTEXT KEY category_2 (category,freelib) z3950 : --------- * works on biblio adding & modifying * works on ISBN, author, title, the 1st found being the one used. various : ---------- * added subject and subtitle to MARC subfields mapped to Koha old-DB. * reordered bookfunds/budget admin tools. languages/languages : ------------- DEFAULT template : * english works. * french should work, mostly. If you experiment some problems, test with english templates, and report the problem as general or french specific NEW template : a "unido" template is in this release. It's uncomplete, and based on vanilla template. GUI reordering ------------------ * Some unused links have been dropped. * a "submenu" shows some operation below main menu. * the MARC link disappeared. It's managed by the MARC=ON/OFF systempref. (the breeding import is now in Parameters section) * acquisition and cataloguing are now separated. acquisition=simple/normal in systempref and cataloguing is MARC/nonMARC depending on MARC=ON/OFF systempref. Should be easier to understand. Bugs still open in bugs.koha.org ======================= always some, but less than in 1.9.3 (40 at this time. more than 20 of them are minor : spellcheck, image missing...) Some of them (for more details, see http://bugs.koha.org) : * 426 Reserving a book (with a reserve fee) results in a hostile message * 452 Payment due flags not showing up for children * 185 Barcode not auto-calculated when autobarcode is on * 425 Add new website feature doesn't work * 318 allow or not a book to be loan * 236 Reserve book on future date doesn't work or copy is wrong bugs not reported here are either unconfirmed, not understood, minor, or partially fixed. Feel free to ask for bugfixes and new features in bugs.koha.org. NOTE that NEW FEATURES or IMPROVEMENTS will only be for 2.0.1 unless it's a very trivial or blocking one. TODO ===== * bug fixes (everybody) * cleaning z3950 old searches (more than 1 hour/day old ?) (paul) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
paul POULAIN <paul.poulain@free.fr> wrote:
.. when Koha 2.0.0pre1 was released.
Arrrrgh, the release manager attacks without warning! Or have I been asleep? There are still 146 bugs awaiting QA and these must be closed before 2.0.0 final, IMO. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
MJ Ray wrote:
paul POULAIN <paul.poulain@free.fr> wrote:
.. when Koha 2.0.0pre1 was released.
Arrrrgh, the release manager attacks without warning!
Or have I been asleep? There are still 146 bugs awaiting QA and these must be closed before 2.0.0 final, IMO.
146 ??? I see only 45 of them. and 20 being really minor. what is your bugzilla request ? (I may have missed something) However : * this release is still in the UNSTABLE tree. * the release notes warns about this. * the "2.0.0pre1" number means "really feature freeze", only bugfixes to go. Note it's not a RC1 (RC = Release Candidate) * the release has been decided by the management team, with "release soon, release often" method. * in a message on friday ("repetable fields on CVS") I wrote : "What about a 2.0.0pre1 release today or monday ?". so you were warned (even if i agree it was a very small warning :-) ) The goal being to attract more and more people before the true 2.0.0. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
paul POULAIN <paul.poulain@free.fr> wrote:
Or have I been asleep? There are still 146 bugs awaiting QA and these must be closed before 2.0.0 final, IMO. 146 ??? I see only 45 of them. and 20 being really minor. what is your=20 bugzilla request ? (I may have missed something)
Bugs against 1.9.x releases marked RESOLVED. There are now 155. QA helpers (and *not* the coders) need to try to reproduce the bug and mark as VERIFIED if the resolution is correct, then invite reporter to CLOSED it. If reporter doesn't, then QA should close after some time (a week? During a 2.0 pre-release meeting?). That's my understanding of how it should be handled, to try to avoid bugs that were reported getting into a release for sure. Ideally, QA would be coding tests, but I think that's really too much for us just now. If people are OK about it, I will start doing this for non-installer stuff once I get some time again and a non-development installation :-( [...]
The goal being to attract more and more people before the true 2.0.0.
Sure. Let's get some QA people too. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
MJ Ray wrote:
paul POULAIN <paul.poulain@free.fr> wrote:
Or have I been asleep? There are still 146 bugs awaiting QA and these must be closed before 2.0.0 final, IMO.
146 ??? I see only 45 of them. and 20 being really minor. what is your=20 bugzilla request ? (I may have missed something)
Bugs against 1.9.x releases marked RESOLVED. There are now 155. QA helpers (and *not* the coders) need to try to reproduce the bug and mark as VERIFIED if the resolution is correct, then invite reporter to CLOSED it. If reporter doesn't, then QA should close after some time (a week? During a 2.0 pre-release meeting?).
That's my understanding of how it should be handled, to try to avoid bugs that were reported getting into a release for sure. Ideally, QA would be coding tests, but I think that's really too much for us just now.
If people are OK about it, I will start doing this for non-installer stuff once I get some time again and a non-development installation :-(
[...]
That's my understanding too. That was expected with our QA manager, who dismissed. We're still waiting for a new candidate. Seems we have found a good one :-D . . . . . . . . . . Do you want this responsability ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
paul POULAIN <paul.poulain@free.fr> wrote:
Do you want this responsability ?
I am reluctant, as I am very short of time for a few weeks yet, as my progress through the installer bugs shows. If no-one with more time steps forwards, I would do this. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
participants (2)
-
MJ Ray -
paul POULAIN