On Friday 30 October 2009 15:29:57 Matthew Toseland wrote:
> 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?
> 
Nextgens brought this back from the GSoC conference:

http://gsoc-wiki.osuosl.org/index.php/Saturday_Sessions_2009/Project_Hosting_Horrors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20091107/44856428/attachment.pgp>

Reply via email to