On Thu, 23 Jul 2015 15:48:51 +0200 win...@genial.ms wrote: > as I'd really like to see a release soon
Its imminent. I have been happily playtesting during the outage, and only found one outright bug, now fixed. I think we are nearly ready to go. As of this morning though I could not access the website. That obviously blocks the release, but I also need to delete a few files there that Caleb cleaned up a while ago from the git master. > I did look through all these miscellaneous files we have inside the > repository: > - I fixed a few minor issues, like wrong version number in docs. > - packaging/debian and packaging/gentoo contain ancient files referring > to freecol 0.3.0 and Java 1.4. These have been changed by the packagers > meanwhile. We may want to delete them as we dont use them or update them > to have newer examples for other packagers. Go for it. > - I tried to find which version of jsmooth (the exe wrapper for Windows) > we are using and no file contained a version number. Later I found a > commit message saying we use 0.99-7 already, which is the "newest" > version. In reality this is a dead project not updated since 2007, > with no commits in CVS since 2008 (they really use CVS, but Sourceforge > did not restore their repo up until today). CVS. How quaint. > - I stumbled upon a forum post saying jsmooth does not support 64bit, > but dont know if its true. So testing the installation again would be > nice before a release (without Java installed and with only 64bit Java > installed, though remember trying it when we had the izpack problem. > Maybe a switch to something else, maybe Launch4j, might be a good > idea. Caleb was having trouble a while back (BR#2790), which may have been fixed by git.428e836. You tell me --- are we seeing successful 64-bit windows installs with 0.11.3? If so, jsmooth is presumably still operating. I do not have much useful to contribute here. You are clearly in a much better position to work on this. > - I tried building a Windows installer and even got the Freecol.pdf > to get built for the first time, after installing MiKTeX 64bit net. Cool. So we are one step closer to being able to do a release build on windows again. > There I wondered why the developer.tex is not built, should we add it > to the build.xml where it is missing? Whoever added developer.tex did not make it part of the release upload. I suspect the idea is that developers have a source tree and can run TeX on it locally. > - Building the installer failed, as there is something wrong with > the build.xml, it can not find the translation helper: > [java] Could not find net.sf.freecol.tools.InstallerTranslations. > Make sure you have it in your classpath Yes, there is text somewhere (developer.tex?) saying to ignore this. I do not know what the story is there. > Its also weird that some translations are hardcoded in build.xml, when > the helper would choose them automatically depending on how complete > they are. Is that intentional? No idea alas. Sounds like it could be improved, but I am not sure it buys us much. > - All kinds of unnecessary things get copied to the dist directory, but > not sure if they then get packaged as that did not work. We may want > to prevent this. Quite so. > - We have some asset files which are unused. Some may be deleted and some > moved to some other folder to prevent them from getting packaged. > Then I could clean up references to them in resources.properties. If they are unused feel free to delete them. We can always get them back. > - We dont use 2 of the 3 font types we bundle Which ones? I have never been in favour of bundling fonts, unless they are not readily available (which would be the case with our "header" font I assume). If we can clean these up that would be a win. > and I dont know if these > should get used again and how to make sure there are no missing glyphs > the currently used fonts Java provides have? I think it is better to use the standard Java fonts where reasonably possible, and delegate to them the responsibility of providing a rich set of glyphs. AFAICT they are pretty good ATM on linux at least. Are you aware of missing glyph problems? As usual, I would not be exercising the accented characters much, outside the national colony names. However I have been experimenting with some annotations for my tweaks to reports like trade and colony --- we currently sometimes append a "*" for colonies with a customs house, but it would be nice to be able to see other interesting features, like the stockade-type or shipyard-type buildings. So I have a patch which uses some obscure unicode symbols, and as yet I have not found anything missing in the 4-hex-digit range when using the default text font. The newer stuff in the 1XXXX range are not well supported though. > - Still need to download the jsmooth GUI helper and check all options, > as I found suspicious references to Java 1.2 and 1.4 in some config file > and am not sure it these are just for the wrapper or the game. > - Also need to check if izpack can be updated, as I remember there've > been new versions of it, which may help with the problems we had with it. IIRC that was last touched in git.428e836. > It'd be nice if you had answers for all my questions. Sorry to disappoint. Lots of this is stuff I have never worked on (or barely understand what I did do, which would be anything in build.xml), or was all in place before I joined the project, or is windows related. > PS: The SF outage made me think it may be nice to not depend on only > one website. I had found someone had uploaded most of the newest commits > in Freecol git to github, but many other things I needed were only on SF. > If something stops working you suddenly see how many projects have > their website and downloads only there. I was mostly unaffected by the outage. Any new work I found to do could be done in my local git tree. I was the lucky one who had made the last commit:-) so currency was not a problem. A minor issue is that my patch queue is now annoyingly large, but a lot of that is just due to not wanting to touch the strings pre-release. So, I think you have a slight point, perhaps we should have a nightly backup of the git tree at a secondary location. > You sure have backups of the complete SVN and bug/feature trackers? Not the SVN, I regard that as archival. I have notes and a synchronized copy of the current open BR and PFs. I also regard closed bugs as archival, and IRs are just not important enough ATM. Cheers, Mike Pope
pgpwpBzTxHEhf.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
