On Tue, 2006-02-07 at 08:32 -0500, Frank Warmerdam wrote: > > Secondly, for it to migrate to testing, the gdal mipsel FTBFS bug > > (#351372) needs fixing (I've forwarded it upstream), and for someone > > with access to a mipsel for testing/etc it should be easy to fix. > > Cees has fixed this very promptly! Yeah, I saw! Bloody good. > > mapscript bindings: C#, Java, Ruby, TCL > > mapscript docs (source format is restructured text - python-docutils) > > I don't think these bindings are that pressing if you have Python > and PHP already (perhaps perl too?) Yep, php/perl/python are in. Perhaps these can wait until they are requested by users. As for the docs, I recon just dump em in mapserver-doc. > > Also, the mapserver source includes a bunch of tests for the different > > mapscript bindings, and something for mapserver itself. We should be > > running these during the build process to catch any portability bugs. > > I'll try to integrate these too. > > Some of the tests (well msautotest at least, maybe not sean's > python unit tests) are pretty fragile, so you likely don't want them > in the build process. But they should be at least used to validate > the produced package on handy platforms. Noted. > > What do people think our strategy wrt 4.6.2 / 4.8.1 should be? Put 4.8.1 > > into experimental (possibly going thru NEW for new bindings/packages), > > then upload to sid once 4.6.2 is in etch? Or just put 4.8.1 straight in > > sid? > > 4.8.1 straight to sid! > > Well, I don't really know the implications of this. I'm just > always for the latest and greatest and forget the rest. This far away from the etch release, I'm inclined to agree. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part