Emu: A disk seems to be failing. Fortunately we have two in RAID1. I have taken a recent backup and should contact bytemark if we decide to keep it...
Emu costs us approx £80/month. Ian has been generously paying half of this, as it was used for his other projects (but isn't really atm), but I am not sure whether that is half of £80/month or half of £160/month. Mirrors network: The Java Web Start installer now uses Google Code (as do other downloads), so we now only use the mirror network for update.cmd/update.sh. That requires a fixed, secure URL to fetch the latest pointer and its sha1sum from, but could fetch the data from the mirrors network. That URL could be through Google App Engine or through some cheap hosting provider or possibly even sourceforge. Website: The website is currently all static. In future we will need language negotiation (which can be done statically), and possibly OS detection for the front page/download page (which can also be done statically although there may be reasons not to). Cheap/free hosting may not be fast enough when we get a slashdot, especially if we add some scripting but even if we don't (as they generally use apache so static content isn't necessarily dramatically faster). Google App Engine probably would be plenty fast, although we may need a paid account (which will probably only cost us when we are slashdotted). Wiki: We need to migrate the Wikka wiki to MediaWiki, because the latter is standard and we will be able to host it externally. E.g. sourceforge Hosted Apps allows for data import for MediaWiki. Mailing lists: There are a few free options e.g. sourceforge, berlios, also Google if we don't mind crappy I-am-not-an-Iranian click-throughs. BUG TRACKER: Basically it comes down to do we want to keep the existing bugs. As I see it, bugs fall into 5 categories: - Bugs abandoned by the end-user. These should be closed. - Out of date bugs. These should *usually* be closed, but sometimes are in fact live bugs. - Dev intelligence i.e. stuff people have said. If these are corroborated quickly they should be acted upon, else they should be closed. - Live bugs. - Feature requests, mostly by developers, often inter-linked with many other feature requests, linked to various end-user bug reports, and often with a lot of info on 1) consequences of implementation, and 2) how to implement. If we keep the bug tracker: - We need to find somewhere to host MANTIS. Probably we will have to pay for this. - We need to keep it up to date ourselves, which is somewhat involved. It may not be as bad as nextgens implies though. - Minimum immediate work. If we don't keep the bug tracker: - We can use any hosted bug tracker anywhere. E.g. Sourceforge Hosted Apps includes both Mantis and Trac. We will likely be able to avoid any fixed monthly payments. - We can use any bug tracker: Mantis, Trac, etc. See below. - We will need to do a "spring clean": Keep the current bug tracker up for a while but read-only, *manually* migrate any important bugs and issues to the new tracker. - This will be significant work. - It will involve going over the bugs, dumping those which are out of date, abandoned etc, and rewriting those bugs and feature issues that are still valid. Trac's wiki functionality may be useful for this, although it loses the ability to link bugs formally. - It may be a useful exercise in terms of prioritising and de-junking. However, we have 20 weeks left of funding, so we have to ask whether spending a week de-junking is worth it? An important related point: Relatively few end-users use the current bug tracker. It is on the Contribute menu on the website, but the main reason IMHO is it is not very newbie friendly. Uservoice is a reasonable solution for end-user feature suggestions and gauging public opinion, but because it does not force users to register their email addresses, it is worthless for solving individual reproducible bugs. It might reasonably be argued that we should have a separate issue tracker or forums system for end-user bug reports. Also, it may make sense for the developer-oriented bug tracker to be open source, whereas it matters less for the end-user tracker, because 1) end-users care less, and 2) long term stuff with detailed implementation notes is likely to be on the developer-oriented bug tracker. If this line of reasoning is correct, we need to choose an end-user-oriented issue tracker or forums system (either way ideally gratis and hosted) to complement Uservoice. Suggestions?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
