Re: [Koha-devel] Next stable release (roadmap + question) (kados, read carefully)

[Joshua Ferraro]

Hi all,

On Fri, Jun 02, 2006 at 05:45:11PM +0200, Paul POULAIN wrote:
> I think we have almost solved the 2 main problems with rel_2_2 :
> 
> * encoding problems : joshua get rid of unicode ones & I get rid of the 
> remaining iso-8859-1 one. I made something i'm not very proud of :
> 
> Joshua introduced a TemplateEncoding system preference that can be 
> either iso8859-1 or utf8.
> If it is set to iso8859-1, there are a lot of encoding problems : 
> MARC::File::XML don't like it, as MARC::Record is supposed to work in 
> MARC8 or UNICODE.
However, Mike Rylander introduced a UNIMARC-handling feature in the latest
version of MARC::File::XML (on SF) that will not attempt to convert to/from
MARC8. I urge you to attempt this solution, as I belive the XML parsers
shouldn't have any trouble dealing with 8859 encoded data.

Also, I'm still waiting to hear back from Tumer on whether the M::F::X 
stuff, specifically libxml2 and XML::LibXML as a parser, is working on
the Windows platform when dealing with combining characters (it works
on Linux now with the proper versions of things; I detailed my findings
in an earlier email and created some tests in HEAD C4/tests/Record-test.pl
that can be used to check your system; these tests should be expanded
to include UNIMARC records and encodings, something I will try to do this
weekend if I have a chance).

> Thus, it seems that all accents are transformed in the process html => 
> xml => marc.
> Thus, i've reintroduced the html => marc behaviour if the 
> TemplateEncoding is set to iso8859-1
> (i've fixed the html2marc as joshua proposed previously, fixing a 
> remaining bug)
There were several bugs, which did you fix?:

* saves blank subfields

* subfield order is hardcoded to always start with 'a' for repeatable tags 
(because it is hardcoded in the addfield routine).

* only possible to specify one set of indicators for each set of tags (ie, one 
for all the 650s). (because they are stored in a hash with the tag as the key).

* the underlying routines don't support subfield reordering or subfield 
repeatability.

> This solution is a workaround : we will have to find a correct solution 
> for Koha 3.0, to move every Koha to UNICODE and UNICODE only. But for 
> instance, I tried some things but failed. Thust this solution, that 
> works correctly for french libraries and should change nothing for 
> unicode ones.' 'acqui.simple/addbiblio.pl' 2>&1
> 
> * MARC editor, cloneTag problem :
> when duplicating a tag, there was 2 problems :
> - the mandatory flags where no more properly affected. I solved this 
> problem by moving color change on Check to the field itself, not to 
> error$i container. Error$i container is now useless and removed. I also 
> changed active color to grey, yellow being for mandatory fields.
> - when you duplicate a field with an authority, the value is still 
> reported to the 1st field. When you duplicate the 1st authority, the 
> container name is set to index+index, so you get 2 "indexindex" containers.
> I still have to solve this problem, but that should not bee too hard I 
> think.
>
> Kados : I didn't modified NPL templates, I let you do this.
OK, let me know when you've found a solution and either Owen or
I will update NPL ... thanks!

> ROADMAP :
> ==========
> I hope I'll find some more time to work on this version next week, 
> working on translation to french, and maybe install it to one of my 
> libraries.
> 
> So, this next version should be officially released on 12th / 13th.
> 
> what could be it's name ? 2.2.6 or 2.4.0 ? That will be discussed on monday
> (note for everybody : monday is closed in France. So you won't see us on 
> chat. But i'll be here on monday 20:00GMT (10PM for French ppl)
I'm planning on turning dev-week into a 2.4 release, just as soon as
it's stable enough (chris and I are planning to do a 2.3 release sometime
this weekend or early next week). Since rel_2_2 doesn't really have any
_new features_, just bug fixes (I know we disagree on this point), I think
it should be released as 2.2.6. However, I wouldn't mind seeing a 2.2.5
version (unstable) release beforehand just to give some folks time to
find bugs and us time to fix them before the official 'stable' release.
Anyway, for what it's worth, that's my opinion. We can certainly discuss
it more on Monday.

Cheers,

-- 
Joshua Ferraro               VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS