[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Thursday, 4. June 2009 14:58:35 Matthew Toseland wrote:
> Can you elaborate on this? Are you saying that the only way to take
> donations with sourceforge is through sourceforge's donations system? That
> could cost us a significant amount of money...

That's what I read in their docs: 

-- -- -- -- -- -- 
Project web may not be used for revenue generation. We pay for the bandwidth 
and servers for project web, then provide that service to you for free, so 
it's unfair for you to try to make money using our project web resources. 
-- -- -- -- -- -- 
-> http://apps.sourceforge.net/trac/sourceforge/wiki/Project web

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 14:06:16 Matthew Toseland wrote:
> Nextgens has suggested Google Web Apps more than once. This is a paid service 
> but with a generous free quota. The free quota will become rather less 
> generous on June 22nd. Hopefully we will get the release out before then, but 
> we will definitely have to pay to release 0.8. Details:
> - 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
> - 46 CPU hours/day free at the moment, 6.5/day after June 22nd.
> 
> The issue with CPU time is SSL: at the moment, https://checksums redirects to 
> an HTTP download, ideally we'd like to serve the installer over SSL, 
> especially since we don't have a code signing cert, but it is not clear how 
> much CPU time this would cost. Anyway, if we do it as now, we would just 
> serve the .sha1's etc directly, and redirect to HTTP for the bulk downloads. 
> In which case we only need to worry about the bandwidth. The cost of 
> bandwidth is reasonable: 12 cents per gig outgoing, 10 cents per gig 
> incoming, so $96 for a respectable slashdotting of 100,000 downloads (8MB 
> each). And in the months when we are not slashdotted, it should cost nothing, 
> even with billing enabled.
> 
> The default quota only allows 56MB/min, which is only 7 downloads, so may not 
> be enough for a slashdot to work well, but if we enable billing it increases 
> to 740MB/min, which is 92 downloads per minute, which is probably sufficient.
> 
> What services could this provide for us? It could certainly provide:
> - Hosting static web content over HTTP.
> - Any dynamic java-based content we want to add in future.
> 
> I am not sure whether it could provide hosting of large files. Servlets are 
> required to return within 30 seconds, presumably the output is buffered, but 
> thousands of 8MB downloads may not be what they intended to buffer. One 
> serious issue is that we cannot run HTTPS on our own domain name:
> 
> "All secure traffic with Google App Engine must be served from your 
> appspot.com domain (https://your-app-id.appspot.com). If you are serving your 
> app off of a Google Apps domain, you must direct all secure traffic through 
> your app's appspot domain."
> 
> Hence we would not be able to keep https://checksums.freenetproject.org/ even 
> as a redirect. That eliminates much of the appeal for me, as it breaks 
> update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
> applications, which is not what we are building.
> 
> What does it not provide?
> - MANTIS.
> - Mailing lists.
> - A wiki.
> - Probably doesn't provide email redirects.
> 
> Wiki and mailing lists we could probably get from Berlios.
> 

Wrong.

We would be serving big files from the Google Release System. The web app could 
point to the latest release, via https://freenet.appspot.com/ . update.cmd and 
update.sh would need to be updated to point to the webapp, but the great thing 
is it has a valid SSL cert.

Google Apps could provide email redirects - each email address 
@freenetproject.org could then be redirected via Gmail.

We would still need to get mailing lists from berlios.

We would definitely want to use berlios for the existing French wiki.

We could either use berlios or google sites for the english wiki. This would 
have to be recreated from scratch or migrated via a script. Both are 
problematic.

And we still need somewhere to host MANTIS - probably on some developer's 
system with spare bandwidth (not mine!).


That's probably the best free solution. If we pay for something, we get:
- File hosting including HTTPS.
- Website hosting.
- Managed wiki hosting for MediaWiki for the French wiki.
- Managed wiki hosting for MediaWiki for a new English wiki which we would have 
to migrate to, OR
- Manual maintenance of the existing Wakka wiki.
- Email redirects and on some providers IMAP.
- Probably manual maintenance of MANTIS, although Godaddy do managed MANTIS; 
the question is whether we would be able to import our existing data. If we go 
for a different bug tracker (jira, trac etc), we have importing issues but it 
might be managed.

We would still use berlios for mailing lists.
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

Nextgens has suggested Google Web Apps more than once. This is a paid service 
but with a generous free quota. The free quota will become rather less generous 
on June 22nd. Hopefully we will get the release out before then, but we will 
definitely have to pay to release 0.8. Details:
- 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
- 46 CPU hours/day free at the moment, 6.5/day after June 22nd.

The issue with CPU time is SSL: at the moment, https://checksums redirects to 
an HTTP download, ideally we'd like to serve the installer over SSL, especially 
since we don't have a code signing cert, but it is not clear how much CPU time 
this would cost. Anyway, if we do it as now, we would just serve the .sha1's 
etc directly, and redirect to HTTP for the bulk downloads. In which case we 
only need to worry about the bandwidth. The cost of bandwidth is reasonable: 12 
cents per gig outgoing, 10 cents per gig incoming, so $96 for a respectable 
slashdotting of 100,000 downloads (8MB each). And in the months when we are not 
slashdotted, it should cost nothing, even with billing enabled.

The default quota only allows 56MB/min, which is only 7 downloads, so may not 
be enough for a slashdot to work well, but if we enable billing it increases to 
740MB/min, which is 92 downloads per minute, which is probably sufficient.

What services could this provide for us? It could certainly provide:
- Hosting static web content over HTTP.
- Any dynamic java-based content we want to add in future.

I am not sure whether it could provide hosting of large files. Servlets are 
required to return within 30 seconds, presumably the output is buffered, but 
thousands of 8MB downloads may not be what they intended to buffer. One serious 
issue is that we cannot run HTTPS on our own domain name:

"All secure traffic with Google App Engine must be served from your appspot.com 
domain (https://your-app-id.appspot.com). If you are serving your app off of a 
Google Apps domain, you must direct all secure traffic through your app's 
appspot domain."

Hence we would not be able to keep https://checksums.freenetproject.org/ even 
as a redirect. That eliminates much of the appeal for me, as it breaks 
update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
applications, which is not what we are building.

What does it not provide?
- MANTIS.
- Mailing lists.
- A wiki.
- Probably doesn't provide email redirects.

Wiki and mailing lists we could probably get from Berlios.
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 12:36:31 bbackde at googlemail.com wrote:
> If you really consider sf.net, someone should analyse what they
> provide. And you should clearly
> state what you need. The whole discussion is based on assumptions and stuff.
> 
> Fyi: sf.net has an own donation system, but you don't have to use it.
> The Frost project directly
> links to paypal on its (sf.net hosted) homepage.

And this does not seem to be contrary to their AUP. I don't think the following 
would apply to us sending an announce mail soliciting donations via paypal?:

"Using contact information obtained from SourceForge.net to solicit donations 
outside of the SourceForge.net Donation System is not permitted. If you have 
been impermissibly solicited for a donation outside of the SourceForge.net 
Donation System, please report the solicitation to us by sending a copy of 
solicitation, and if by email, include the full header in order for us to trace 
the pathway of the email. "
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Wednesday 03 June 2009 20:21:46 Arne Babenhauserheide wrote:
> On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
> > Web hosting (of static files). Sourceforge provide this, and it should
> > perform well. If there is no dynamic code there should be no administrative
> > overhead.
> 
> They don't allow generating money from the webhosting, so SF can't solve 
> static websites. But that can easily be found elsewhere, too. 

Can you elaborate on this? Are you saying that the only way to take donations 
with sourceforge is through sourceforge's donations system? That could cost us 
a significant amount of money...
-- 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: 

[freenet-dev] Getting rid of emu: an option

[bbac...@googlemail.com]

If you really consider sf.net, someone should analyse what they
provide. And you should clearly
state what you need. The whole discussion is based on assumptions and stuff.

Fyi: sf.net has an own donation system, but you don't have to use it.
The Frost project directly
links to paypal on its (sf.net hosted) homepage.

On Thu, Jun 4, 2009 at 13:21, Matthew Toseland
 wrote:
> On Thursday 04 June 2009 01:31:46 Daniel Cheng wrote:
>> On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide  
>> wrote:
>> > On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
>> >> Web hosting (of static files). Sourceforge provide this, and it should
>> >> perform well. If there is no dynamic code there should be no 
>> >> administrative
>> >> overhead.
>> >
>> > They don't allow generating money from the webhosting, so SF can't solve
>> > static websites. But that can easily be found elsewhere, too.
>>
>> They do allow "selling support" via "MarketPlace"
>> (http://sourceforge.net/services/buy/index.php).
>
> They also have their own donations system ... but if they insist on us using 
> it and therefore them taking a percentage on top of our paypal fees, clearly 
> that is a significant cost and a major factor against them.
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>



-- 
__
GnuPG key:   (0x48DBFA8A)
Keyserver:   pgpkeys.pca.dfn.de
Fingerprint:
477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
__

[freenet-dev] Getting rid of emu: an option

[Juiceman]

On Thu, Jun 4, 2009 at 9:06 AM, Matthew Toseland
 wrote:
> Nextgens has suggested Google Web Apps more than once. This is a paid service 
> but with a generous free quota. The free quota will become rather less 
> generous on June 22nd. Hopefully we will get the release out before then, but 
> we will definitely have to pay to release 0.8. Details:
> - 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
> - 46 CPU hours/day free at the moment, 6.5/day after June 22nd.
>
> The issue with CPU time is SSL: at the moment, https://checksums redirects to 
> an HTTP download, ideally we'd like to serve the installer over SSL, 
> especially since we don't have a code signing cert, but it is not clear how 
> much CPU time this would cost. Anyway, if we do it as now, we would just 
> serve the .sha1's etc directly, and redirect to HTTP for the bulk downloads. 
> In which case we only need to worry about the bandwidth. The cost of 
> bandwidth is reasonable: 12 cents per gig outgoing, 10 cents per gig 
> incoming, so $96 for a respectable slashdotting of 100,000 downloads (8MB 
> each). And in the months when we are not slashdotted, it should cost nothing, 
> even with billing enabled.
>
> The default quota only allows 56MB/min, which is only 7 downloads, so may not 
> be enough for a slashdot to work well, but if we enable billing it increases 
> to 740MB/min, which is 92 downloads per minute, which is probably sufficient.
>
> What services could this provide for us? It could certainly provide:
> - Hosting static web content over HTTP.
> - Any dynamic java-based content we want to add in future.
>
> I am not sure whether it could provide hosting of large files. Servlets are 
> required to return within 30 seconds, presumably the output is buffered, but 
> thousands of 8MB downloads may not be what they intended to buffer. One 
> serious issue is that we cannot run HTTPS on our own domain name:
>
> "All secure traffic with Google App Engine must be served from your 
> appspot.com domain (https://your-app-id.appspot.com). If you are serving your 
> app off of a Google Apps domain, you must direct all secure traffic through 
> your app's appspot domain."
>
> Hence we would not be able to keep https://checksums.freenetproject.org/ even 
> as a redirect. That eliminates much of the appeal for me, as it breaks 
> update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
> applications, which is not what we are building.

If we can keep some sort of hosting for
https://checksums.freenetproject.org up (even some basic free host) or
heck even a developer's home server to serve a redirect or an updated
version of the update scripts, then backwards compatibility would not
be a problem.  We would just need this for 6-12 months.

Another option would be to have the node write a new version of the
update script in the node directory.  That should cover 99.9% of
cases.

>
> What does it not provide?
> - MANTIS.
> - Mailing lists.
> - A wiki.
> - Probably doesn't provide email redirects.
>
> Wiki and mailing lists we could probably get from Berlios.
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>



-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 01:31:46 Daniel Cheng wrote:
> On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide  
> wrote:
> > On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
> >> Web hosting (of static files). Sourceforge provide this, and it should
> >> perform well. If there is no dynamic code there should be no administrative
> >> overhead.
> >
> > They don't allow generating money from the webhosting, so SF can't solve
> > static websites. But that can easily be found elsewhere, too.
> 
> They do allow "selling support" via "MarketPlace"
> (http://sourceforge.net/services/buy/index.php).

They also have their own donations system ... but if they insist on us using it 
and therefore them taking a percentage on top of our paypal fees, clearly that 
is a significant cost and a major factor against them.
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide  
wrote:
> On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
>> Web hosting (of static files). Sourceforge provide this, and it should
>> perform well. If there is no dynamic code there should be no administrative
>> overhead.
>
> They don't allow generating money from the webhosting, so SF can't solve
> static websites. But that can easily be found elsewhere, too.

They do allow "selling support" via "MarketPlace"
(http://sourceforge.net/services/buy/index.php).

> Best wishes,
> Arne

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 01:31:46 Daniel Cheng wrote:
 On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide arne_...@web.de wrote:
  On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
  Web hosting (of static files). Sourceforge provide this, and it should
  perform well. If there is no dynamic code there should be no administrative
  overhead.
 
  They don't allow generating money from the webhosting, so SF can't solve
  static websites. But that can easily be found elsewhere, too.
 
 They do allow selling support via MarketPlace
 (http://sourceforge.net/services/buy/index.php).

They also have their own donations system ... but if they insist on us using it 
and therefore them taking a percentage on top of our paypal fees, clearly that 
is a significant cost and a major factor against them.


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

Re: [freenet-dev] Getting rid of emu: an option

[bbackde]

If you really consider sf.net, someone should analyse what they
provide. And you should clearly
state what you need. The whole discussion is based on assumptions and stuff.

Fyi: sf.net has an own donation system, but you don't have to use it.
The Frost project directly
links to paypal on its (sf.net hosted) homepage.

On Thu, Jun 4, 2009 at 13:21, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Thursday 04 June 2009 01:31:46 Daniel Cheng wrote:
 On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide arne_...@web.de 
 wrote:
  On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
  Web hosting (of static files). Sourceforge provide this, and it should
  perform well. If there is no dynamic code there should be no 
  administrative
  overhead.
 
  They don't allow generating money from the webhosting, so SF can't solve
  static websites. But that can easily be found elsewhere, too.

 They do allow selling support via MarketPlace
 (http://sourceforge.net/services/buy/index.php).

 They also have their own donations system ... but if they insist on us using 
 it and therefore them taking a percentage on top of our paypal fees, clearly 
 that is a significant cost and a major factor against them.

 ___
 Devl mailing list
 Devl@freenetproject.org
 http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl




-- 
__
GnuPG key:   (0x48DBFA8A)
Keyserver:   pgpkeys.pca.dfn.de
Fingerprint:
477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
__
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Wednesday 03 June 2009 20:21:46 Arne Babenhauserheide wrote:
 On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
  Web hosting (of static files). Sourceforge provide this, and it should
  perform well. If there is no dynamic code there should be no administrative
  overhead.
 
 They don't allow generating money from the webhosting, so SF can't solve 
 static websites. But that can easily be found elsewhere, too. 

Can you elaborate on this? Are you saying that the only way to take donations 
with sourceforge is through sourceforge's donations system? That could cost us 
a significant amount of money...


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 12:36:31 bbac...@googlemail.com wrote:
 If you really consider sf.net, someone should analyse what they
 provide. And you should clearly
 state what you need. The whole discussion is based on assumptions and stuff.
 
 Fyi: sf.net has an own donation system, but you don't have to use it.
 The Frost project directly
 links to paypal on its (sf.net hosted) homepage.

And this does not seem to be contrary to their AUP. I don't think the following 
would apply to us sending an announce mail soliciting donations via paypal?:

Using contact information obtained from SourceForge.net to solicit donations 
outside of the SourceForge.net Donation System is not permitted. If you have 
been impermissibly solicited for a donation outside of the SourceForge.net 
Donation System, please report the solicitation to us by sending a copy of 
solicitation, and if by email, include the full header in order for us to trace 
the pathway of the email. 


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

Nextgens has suggested Google Web Apps more than once. This is a paid service 
but with a generous free quota. The free quota will become rather less generous 
on June 22nd. Hopefully we will get the release out before then, but we will 
definitely have to pay to release 0.8. Details:
- 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
- 46 CPU hours/day free at the moment, 6.5/day after June 22nd.

The issue with CPU time is SSL: at the moment, https://checksums redirects to 
an HTTP download, ideally we'd like to serve the installer over SSL, especially 
since we don't have a code signing cert, but it is not clear how much CPU time 
this would cost. Anyway, if we do it as now, we would just serve the .sha1's 
etc directly, and redirect to HTTP for the bulk downloads. In which case we 
only need to worry about the bandwidth. The cost of bandwidth is reasonable: 12 
cents per gig outgoing, 10 cents per gig incoming, so $96 for a respectable 
slashdotting of 100,000 downloads (8MB each). And in the months when we are not 
slashdotted, it should cost nothing, even with billing enabled.

The default quota only allows 56MB/min, which is only 7 downloads, so may not 
be enough for a slashdot to work well, but if we enable billing it increases to 
740MB/min, which is 92 downloads per minute, which is probably sufficient.

What services could this provide for us? It could certainly provide:
- Hosting static web content over HTTP.
- Any dynamic java-based content we want to add in future.

I am not sure whether it could provide hosting of large files. Servlets are 
required to return within 30 seconds, presumably the output is buffered, but 
thousands of 8MB downloads may not be what they intended to buffer. One serious 
issue is that we cannot run HTTPS on our own domain name:

All secure traffic with Google App Engine must be served from your appspot.com 
domain (https://your-app-id.appspot.com). If you are serving your app off of a 
Google Apps domain, you must direct all secure traffic through your app's 
appspot domain.

Hence we would not be able to keep https://checksums.freenetproject.org/ even 
as a redirect. That eliminates much of the appeal for me, as it breaks 
update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
applications, which is not what we are building.

What does it not provide?
- MANTIS.
- Mailing lists.
- A wiki.
- Probably doesn't provide email redirects.

Wiki and mailing lists we could probably get from Berlios.


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Thursday 04 June 2009 14:06:16 Matthew Toseland wrote:
 Nextgens has suggested Google Web Apps more than once. This is a paid service 
 but with a generous free quota. The free quota will become rather less 
 generous on June 22nd. Hopefully we will get the release out before then, but 
 we will definitely have to pay to release 0.8. Details:
 - 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
 - 46 CPU hours/day free at the moment, 6.5/day after June 22nd.
 
 The issue with CPU time is SSL: at the moment, https://checksums redirects to 
 an HTTP download, ideally we'd like to serve the installer over SSL, 
 especially since we don't have a code signing cert, but it is not clear how 
 much CPU time this would cost. Anyway, if we do it as now, we would just 
 serve the .sha1's etc directly, and redirect to HTTP for the bulk downloads. 
 In which case we only need to worry about the bandwidth. The cost of 
 bandwidth is reasonable: 12 cents per gig outgoing, 10 cents per gig 
 incoming, so $96 for a respectable slashdotting of 100,000 downloads (8MB 
 each). And in the months when we are not slashdotted, it should cost nothing, 
 even with billing enabled.
 
 The default quota only allows 56MB/min, which is only 7 downloads, so may not 
 be enough for a slashdot to work well, but if we enable billing it increases 
 to 740MB/min, which is 92 downloads per minute, which is probably sufficient.
 
 What services could this provide for us? It could certainly provide:
 - Hosting static web content over HTTP.
 - Any dynamic java-based content we want to add in future.
 
 I am not sure whether it could provide hosting of large files. Servlets are 
 required to return within 30 seconds, presumably the output is buffered, but 
 thousands of 8MB downloads may not be what they intended to buffer. One 
 serious issue is that we cannot run HTTPS on our own domain name:
 
 All secure traffic with Google App Engine must be served from your 
 appspot.com domain (https://your-app-id.appspot.com). If you are serving your 
 app off of a Google Apps domain, you must direct all secure traffic through 
 your app's appspot domain.
 
 Hence we would not be able to keep https://checksums.freenetproject.org/ even 
 as a redirect. That eliminates much of the appeal for me, as it breaks 
 update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
 applications, which is not what we are building.
 
 What does it not provide?
 - MANTIS.
 - Mailing lists.
 - A wiki.
 - Probably doesn't provide email redirects.
 
 Wiki and mailing lists we could probably get from Berlios.
 

Wrong.

We would be serving big files from the Google Release System. The web app could 
point to the latest release, via https://freenet.appspot.com/ . update.cmd and 
update.sh would need to be updated to point to the webapp, but the great thing 
is it has a valid SSL cert.

Google Apps could provide email redirects - each email address 
@freenetproject.org could then be redirected via Gmail.

We would still need to get mailing lists from berlios.

We would definitely want to use berlios for the existing French wiki.

We could either use berlios or google sites for the english wiki. This would 
have to be recreated from scratch or migrated via a script. Both are 
problematic.

And we still need somewhere to host MANTIS - probably on some developer's 
system with spare bandwidth (not mine!).


That's probably the best free solution. If we pay for something, we get:
- File hosting including HTTPS.
- Website hosting.
- Managed wiki hosting for MediaWiki for the French wiki.
- Managed wiki hosting for MediaWiki for a new English wiki which we would have 
to migrate to, OR
- Manual maintenance of the existing Wakka wiki.
- Email redirects and on some providers IMAP.
- Probably manual maintenance of MANTIS, although Godaddy do managed MANTIS; 
the question is whether we would be able to import our existing data. If we go 
for a different bug tracker (jira, trac etc), we have importing issues but it 
might be managed.

We would still use berlios for mailing lists.


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

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Thursday, 4. June 2009 14:58:35 Matthew Toseland wrote:
 Can you elaborate on this? Are you saying that the only way to take
 donations with sourceforge is through sourceforge's donations system? That
 could cost us a significant amount of money...

That's what I read in their docs: 

-- -- -- -- -- -- 
Project web may not be used for revenue generation. We pay for the bandwidth 
and servers for project web, then provide that service to you for free, so 
it's unfair for you to try to make money using our project web resources. 
-- -- -- -- -- -- 
- http://apps.sourceforge.net/trac/sourceforge/wiki/Project web

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Getting rid of emu: an option

[Juiceman]

On Thu, Jun 4, 2009 at 9:06 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 Nextgens has suggested Google Web Apps more than once. This is a paid service 
 but with a generous free quota. The free quota will become rather less 
 generous on June 22nd. Hopefully we will get the release out before then, but 
 we will definitely have to pay to release 0.8. Details:
 - 10GB/day free transfer each way at the moment, 1GB/day after June 22nd.
 - 46 CPU hours/day free at the moment, 6.5/day after June 22nd.

 The issue with CPU time is SSL: at the moment, https://checksums redirects to 
 an HTTP download, ideally we'd like to serve the installer over SSL, 
 especially since we don't have a code signing cert, but it is not clear how 
 much CPU time this would cost. Anyway, if we do it as now, we would just 
 serve the .sha1's etc directly, and redirect to HTTP for the bulk downloads. 
 In which case we only need to worry about the bandwidth. The cost of 
 bandwidth is reasonable: 12 cents per gig outgoing, 10 cents per gig 
 incoming, so $96 for a respectable slashdotting of 100,000 downloads (8MB 
 each). And in the months when we are not slashdotted, it should cost nothing, 
 even with billing enabled.

 The default quota only allows 56MB/min, which is only 7 downloads, so may not 
 be enough for a slashdot to work well, but if we enable billing it increases 
 to 740MB/min, which is 92 downloads per minute, which is probably sufficient.

 What services could this provide for us? It could certainly provide:
 - Hosting static web content over HTTP.
 - Any dynamic java-based content we want to add in future.

 I am not sure whether it could provide hosting of large files. Servlets are 
 required to return within 30 seconds, presumably the output is buffered, but 
 thousands of 8MB downloads may not be what they intended to buffer. One 
 serious issue is that we cannot run HTTPS on our own domain name:

 All secure traffic with Google App Engine must be served from your 
 appspot.com domain (https://your-app-id.appspot.com). If you are serving your 
 app off of a Google Apps domain, you must direct all secure traffic through 
 your app's appspot domain.

 Hence we would not be able to keep https://checksums.freenetproject.org/ even 
 as a redirect. That eliminates much of the appeal for me, as it breaks 
 update.cmd / update.sh. Really Google Web Apps is designed for dynamic web 
 applications, which is not what we are building.

If we can keep some sort of hosting for
https://checksums.freenetproject.org up (even some basic free host) or
heck even a developer's home server to serve a redirect or an updated
version of the update scripts, then backwards compatibility would not
be a problem.  We would just need this for 6-12 months.

Another option would be to have the node write a new version of the
update script in the node directory.  That should cover 99.9% of
cases.


 What does it not provide?
 - MANTIS.
 - Mailing lists.
 - A wiki.
 - Probably doesn't provide email redirects.

 Wiki and mailing lists we could probably get from Berlios.

 ___
 Devl mailing list
 Devl@freenetproject.org
 http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl




-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
> Mantis: We could run this ourselves using php+mysql on sourceforge servers,
> but we would have to admin it ourselves. Their hosted apps service does not
> currently support importing data, so we would not be able to use that to
> host our existing bug tracker. Having to upgrade it manually would be a
> major pain, from what nextgens has said...

We could file a support request for that. Maybe they can update it themselves. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
> Web hosting (of static files). Sourceforge provide this, and it should
> perform well. If there is no dynamic code there should be no administrative
> overhead.

They don't allow generating money from the webhosting, so SF can't solve 
static websites. But that can easily be found elsewhere, too. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

Sourceforge could solve some of these problems:

Web hosting (of static files). Sourceforge provide this, and it should perform 
well. If there is no dynamic code there should be no administrative overhead.

Mantis: We could run this ourselves using php+mysql on sourceforge servers, but 
we would have to admin it ourselves. Their hosted apps service does not 
currently support importing data, so we would not be able to use that to host 
our existing bug tracker. Having to upgrade it manually would be a *major* 
pain, from what nextgens has said...

Wiki: Sourceforge can provide hosted MediaWiki, which will immediately solve 
the problem of our french wiki. However, our english wiki is using Wikka, which 
is nonstandard. We probably want to migrate it to MediaWiki at some point...

Other stuff:

Mailing lists: Past experience suggests we don't want to use sourceforge's 
mailing list services, so we will need to find somewhere else.

https://checksums.freenetproject.org : We need SSL with redirects, so that the 
update scripts continue to work; and architecturally it's the Right Thing...

Mailing list archives: We could rely entirely on third parties, quite a few 
providers archive our lists. Anywhere we get mailman from will probably provide 
basic non-searchable pipermail archiving.


Some paid providers do free installation and upgrades of mantis, mediawiki etc. 
For example, godaddy hosting connection, which is included with their $6.99/mo 
150GB space / 1500GB transfer deal; whether we would be able to import our 
existing data is not immediately clear. IMHO this would solve most of the above 
problems:
- Web hosting.
- https://checksums
- Mantis. *Possibly* hosted (if we can import data), if not we could admin 
ourselves.
- MediaWiki.
- File hosting. (If it's over 1500GB for a release, then we use CoralCache that 
month).

However, it doesn't solve the mailing lists issue. Neither does Sourceforge or 
Google in a satisfactory way.

On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
> We need to get rid of emu. It costs us a significant amount of money and we 
> don't seem able to cost-effecitvely administer it.
> 
> Basically what we need:
> - PHP scripts. The website is built with PHP.
> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
> - SSL. We need to serve checksums and signatures through SSL, although big 
> files will generally be served through HTTP. It would be nice to serve the 
> installer through SSL if we have a huge traffic limit, since code signing 
> certs are expensive, on the other hand if we get cheaper hosting we can 
> probably afford to buy a code signing cert with a fraction of the money 
> saved...
> - IMAP accounts ideally, but at least aliases.
> 
> What we do NOT need:
> - Auto-build. This is difficult to secure, and not really compatible with a 
> secure git-based workflow.
> 
> Anything I've missed?
> 
> One option:
> 
> http://www.uk2.net/web-hosting/
> 
> Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
> bytemark, even if we qualified for the 50% discount for the main distributor 
> of free software), domain hosting, and a (very basic) uptime SLA, for ?13.95 
> to ?19.95/mo depending on how long we buy it for (2 years down to 1 month).
> 
> Thoughts?
-- 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: 

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

Sourceforge could solve some of these problems:

Web hosting (of static files). Sourceforge provide this, and it should perform 
well. If there is no dynamic code there should be no administrative overhead.

Mantis: We could run this ourselves using php+mysql on sourceforge servers, but 
we would have to admin it ourselves. Their hosted apps service does not 
currently support importing data, so we would not be able to use that to host 
our existing bug tracker. Having to upgrade it manually would be a *major* 
pain, from what nextgens has said...

Wiki: Sourceforge can provide hosted MediaWiki, which will immediately solve 
the problem of our french wiki. However, our english wiki is using Wikka, which 
is nonstandard. We probably want to migrate it to MediaWiki at some point...

Other stuff:

Mailing lists: Past experience suggests we don't want to use sourceforge's 
mailing list services, so we will need to find somewhere else.

https://checksums.freenetproject.org : We need SSL with redirects, so that the 
update scripts continue to work; and architecturally it's the Right Thing...

Mailing list archives: We could rely entirely on third parties, quite a few 
providers archive our lists. Anywhere we get mailman from will probably provide 
basic non-searchable pipermail archiving.


Some paid providers do free installation and upgrades of mantis, mediawiki etc. 
For example, godaddy hosting connection, which is included with their $6.99/mo 
150GB space / 1500GB transfer deal; whether we would be able to import our 
existing data is not immediately clear. IMHO this would solve most of the above 
problems:
- Web hosting.
- https://checksums
- Mantis. *Possibly* hosted (if we can import data), if not we could admin 
ourselves.
- MediaWiki.
- File hosting. (If it's over 1500GB for a release, then we use CoralCache that 
month).

However, it doesn't solve the mailing lists issue. Neither does Sourceforge or 
Google in a satisfactory way.

On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
 We need to get rid of emu. It costs us a significant amount of money and we 
 don't seem able to cost-effecitvely administer it.
 
 Basically what we need:
 - PHP scripts. The website is built with PHP.
 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
 - SSL. We need to serve checksums and signatures through SSL, although big 
 files will generally be served through HTTP. It would be nice to serve the 
 installer through SSL if we have a huge traffic limit, since code signing 
 certs are expensive, on the other hand if we get cheaper hosting we can 
 probably afford to buy a code signing cert with a fraction of the money 
 saved...
 - IMAP accounts ideally, but at least aliases.
 
 What we do NOT need:
 - Auto-build. This is difficult to secure, and not really compatible with a 
 secure git-based workflow.
 
 Anything I've missed?
 
 One option:
 
 http://www.uk2.net/web-hosting/
 
 Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
 bytemark, even if we qualified for the 50% discount for the main distributor 
 of free software), domain hosting, and a (very basic) uptime SLA, for £13.95 
 to £19.95/mo depending on how long we buy it for (2 years down to 1 month).
 
 Thoughts?


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

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
 Web hosting (of static files). Sourceforge provide this, and it should
 perform well. If there is no dynamic code there should be no administrative
 overhead.

They don't allow generating money from the webhosting, so SF can't solve 
static websites. But that can easily be found elsewhere, too. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
 Mantis: We could run this ourselves using php+mysql on sourceforge servers,
 but we would have to admin it ourselves. Their hosted apps service does not
 currently support importing data, so we would not be able to use that to
 host our existing bug tracker. Having to upgrade it manually would be a
 major pain, from what nextgens has said...

We could file a support request for that. Maybe they can update it themselves. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide arne_...@web.de wrote:
 On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote:
 Web hosting (of static files). Sourceforge provide this, and it should
 perform well. If there is no dynamic code there should be no administrative
 overhead.

 They don't allow generating money from the webhosting, so SF can't solve
 static websites. But that can easily be found elsewhere, too.

They do allow selling support via MarketPlace
(http://sourceforge.net/services/buy/index.php).

 Best wishes,
 Arne
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
 wrote:
> Arne Babenhauserheide wrote:
>> On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
>>> Having said that, we might need somewhere to put mantis, if we decide to
>>> keep it (although everyone else seems to want to get rid of it). We don't
>>> have any other need for php afaik, although we need SSL redirects.
>>
>> How about hosting mantis on sourceforge?
>>
>> They have it now.
>>
>> - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
>>
>> Best wishes,
>> Arne
>>
>
> I like that option; We already have a SF project!
>
> NextGen$

I have had some very bad experience with SF's servers around year 2001.
It was slow and buggy. Is that fixed now?

SF's git support  rejects fast forward updates by default..
hm..

Daniel

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Tuesday, 2. June 2009 13:53:37 Daniel Cheng wrote:
> I have had some very bad experience with SF's servers around year 2001.
> It was slow and buggy. Is that fixed now?

They did some nice updates - I didn't have bad experiences with it for years, 
now. 

- Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Tuesday 02 June 2009 14:27:10 Florent Daigniere wrote:
> Daniel Cheng wrote:
> > On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
> >  wrote:
> >> Arne Babenhauserheide wrote:
> >>> On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
>  Having said that, we might need somewhere to put mantis, if we decide to
>  keep it (although everyone else seems to want to get rid of it). We don't
>  have any other need for php afaik, although we need SSL redirects.
> >>> How about hosting mantis on sourceforge?
> >>>
> >>> They have it now.
> >>>
> >>> - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
> >>>
> >>> Best wishes,
> >>> Arne
> >>>
> >> I like that option; We already have a SF project!
> >>
> >> NextGen$
> > 
> > I have had some very bad experience with SF's servers around year 2001.
> > It was slow and buggy. Is that fixed now?
> > 
> 
> Dunno but I think it's worth checking it out if we want to keep mantis 
> (which I'm clearly not in favor of).

They are not going to go out of their way to let us migrate our existing data, 
surely?
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Florent Daigniere]

Daniel Cheng wrote:
> On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
>  wrote:
>> Arne Babenhauserheide wrote:
>>> On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
 Having said that, we might need somewhere to put mantis, if we decide to
 keep it (although everyone else seems to want to get rid of it). We don't
 have any other need for php afaik, although we need SSL redirects.
>>> How about hosting mantis on sourceforge?
>>>
>>> They have it now.
>>>
>>> - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
>>>
>>> Best wishes,
>>> Arne
>>>
>> I like that option; We already have a SF project!
>>
>> NextGen$
> 
> I have had some very bad experience with SF's servers around year 2001.
> It was slow and buggy. Is that fixed now?
> 

Dunno but I think it's worth checking it out if we want to keep mantis 
(which I'm clearly not in favor of).

NextGen$

[freenet-dev] Getting rid of emu: an option

[Florent Daigniere]

Arne Babenhauserheide wrote:
> On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
>> Having said that, we might need somewhere to put mantis, if we decide to
>> keep it (although everyone else seems to want to get rid of it). We don't
>> have any other need for php afaik, although we need SSL redirects.
> 
> How about hosting mantis on sourceforge? 
> 
> They have it now. 
> 
> - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
> 
> Best wishes, 
> Arne
> 

I like that option; We already have a SF project!

NextGen$

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Monday, 1. June 2009 13:55:29 sashee wrote:
> We had a policy where I worked for some time, that if a bug is
> inactive for some time, and cannot be reproduced by the developer,
> will be force closed.

I know that from many other projects. 

IIRC Gentoo uses "NEEDINFO" for that. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
> Having said that, we might need somewhere to put mantis, if we decide to
> keep it (although everyone else seems to want to get rid of it). We don't
> have any other need for php afaik, although we need SSL redirects.

How about hosting mantis on sourceforge? 

They have it now. 

- http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Monday 01 June 2009 12:22:07 Daniel Cheng wrote:
> On Mon, Jun 1, 2009 at 7:15 PM, xor  wrote:
> > On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
> >>
> >> I like this idea. ?I think it is clear that there is a lot of cruft in
> >> Mantis, open bugs that are no-longer relevant etc. ?Cleaning house
> >> would be useful.
> >>
> >> Ian.
> >
> > I am strongly against getting rid of the bugtracker contents if that is what
> > you guys mean.
> >
> > If we were supposed to rate our development process in terms of "best
> > practices", deleting the bugtracker content would probably be the WORST
> > practice which anyone can think of, besides deleting all documentation.
> >
> > I think we should do the following:
> > 1. (FIRST!) clean up mantis
> > 2. migrate to a different bug tracker.
> >
> > As for cleaning up: Resolving about 10 obsolete issues per day should be
> > enough to get mantis quite empty soon, I've suggested that some days ago on
> > devl.
> 
> I guess you may have awared: Lots of the open bugs are undecidable by you or 
> me.
> 
> For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
> keep asking if this is fixed, yet no reply.

It should be, and the original poster doesn't respond, and there are no dupes 
pointing at it, so mark it as resolved.
-- 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: 

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
 Having said that, we might need somewhere to put mantis, if we decide to
 keep it (although everyone else seems to want to get rid of it). We don't
 have any other need for php afaik, although we need SSL redirects.

How about hosting mantis on sourceforge? 

They have it now. 

- http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Monday, 1. June 2009 13:55:29 sashee wrote:
 We had a policy where I worked for some time, that if a bug is
 inactive for some time, and cannot be reproduced by the developer,
 will be force closed.

I know that from many other projects. 

IIRC Gentoo uses NEEDINFO for that. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Getting rid of emu: an option

[Florent Daigniere]

Arne Babenhauserheide wrote:
 On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
 Having said that, we might need somewhere to put mantis, if we decide to
 keep it (although everyone else seems to want to get rid of it). We don't
 have any other need for php afaik, although we need SSL redirects.
 
 How about hosting mantis on sourceforge? 
 
 They have it now. 
 
 - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
 
 Best wishes, 
 Arne
 

I like that option; We already have a SF project!

NextGen$
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
nextg...@freenetproject.org wrote:
 Arne Babenhauserheide wrote:
 On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
 Having said that, we might need somewhere to put mantis, if we decide to
 keep it (although everyone else seems to want to get rid of it). We don't
 have any other need for php afaik, although we need SSL redirects.

 How about hosting mantis on sourceforge?

 They have it now.

 - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps

 Best wishes,
 Arne


 I like that option; We already have a SF project!

 NextGen$

I have had some very bad experience with SF's servers around year 2001.
It was slow and buggy. Is that fixed now?

SF's git support  rejects fast forward updates by default..
hm..

Daniel
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Florent Daigniere]

Daniel Cheng wrote:
 On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
 nextg...@freenetproject.org wrote:
 Arne Babenhauserheide wrote:
 On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
 Having said that, we might need somewhere to put mantis, if we decide to
 keep it (although everyone else seems to want to get rid of it). We don't
 have any other need for php afaik, although we need SSL redirects.
 How about hosting mantis on sourceforge?

 They have it now.

 - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps

 Best wishes,
 Arne

 I like that option; We already have a SF project!

 NextGen$
 
 I have had some very bad experience with SF's servers around year 2001.
 It was slow and buggy. Is that fixed now?
 

Dunno but I think it's worth checking it out if we want to keep mantis 
(which I'm clearly not in favor of).

NextGen$
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Tuesday 02 June 2009 14:27:10 Florent Daigniere wrote:
 Daniel Cheng wrote:
  On Tue, Jun 2, 2009 at 6:06 PM, Florent Daigniere
  nextg...@freenetproject.org wrote:
  Arne Babenhauserheide wrote:
  On Monday, 1. June 2009 11:39:13 Matthew Toseland wrote:
  Having said that, we might need somewhere to put mantis, if we decide to
  keep it (although everyone else seems to want to get rid of it). We don't
  have any other need for php afaik, although we need SSL redirects.
  How about hosting mantis on sourceforge?
 
  They have it now.
 
  - http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted Apps
 
  Best wishes,
  Arne
 
  I like that option; We already have a SF project!
 
  NextGen$
  
  I have had some very bad experience with SF's servers around year 2001.
  It was slow and buggy. Is that fixed now?
  
 
 Dunno but I think it's worth checking it out if we want to keep mantis 
 (which I'm clearly not in favor of).

They are not going to go out of their way to let us migrate our existing data, 
surely?


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

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Tuesday, 2. June 2009 13:53:37 Daniel Cheng wrote:
 I have had some very bad experience with SF's servers around year 2001.
 It was slow and buggy. Is that fixed now?

They did some nice updates - I didn't have bad experiences with it for years, 
now. 

- Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

[freenet-dev] Getting rid of emu: an option

[Zero3]

xor skrev:
> On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
>> I like this idea.  I think it is clear that there is a lot of cruft in
>> Mantis, open bugs that are no-longer relevant etc.  Cleaning house
>> would be useful.
>>
>> Ian.
> 
> I am strongly against getting rid of the bugtracker contents if that is what 
> you guys mean.
> 
> If we were supposed to rate our development process in terms of "best 
> practices", deleting the bugtracker content would probably be the WORST 
> practice which anyone can think of, besides deleting all documentation.
> 
> I think we should do the following:
> 1. (FIRST!) clean up mantis
> 2. migrate to a different bug tracker.
> 
> As for cleaning up: Resolving about 10 obsolete issues per day should be 
> enough to get mantis quite empty soon, I've suggested that some days ago on 
> devl.
> 
> Personally, I use mantis for having a overview of all WoT/Freetalk tasks 
> which 
> need to be finished before the next release, it IS very useful to me.
> 
> xor

I have to more or less completely agree with xor. Removing all the old 
bugs seems like "running away from all the problems" (literally, kind of).

As xor also mentions, we really should focus on keeping the data on 
mantis UP-TO-DATE instead by making sure that bugs are 
assigned/closed/updated etc. instead of simply submitting & forgetting. 
I've been closing a bunch of bugs related to the (now deprecated) 
FireFox profile and the old Windows installer, but I have far from 
enough knowledge about all the technical Freenet stuff to deal with that 
kind of bugs.

- Zero3

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Mon, Jun 1, 2009 at 7:15 PM, xor  wrote:
> On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
>>
>> I like this idea. ?I think it is clear that there is a lot of cruft in
>> Mantis, open bugs that are no-longer relevant etc. ?Cleaning house
>> would be useful.
>>
>> Ian.
>
> I am strongly against getting rid of the bugtracker contents if that is what
> you guys mean.
>
> If we were supposed to rate our development process in terms of "best
> practices", deleting the bugtracker content would probably be the WORST
> practice which anyone can think of, besides deleting all documentation.
>
> I think we should do the following:
> 1. (FIRST!) clean up mantis
> 2. migrate to a different bug tracker.
>
> As for cleaning up: Resolving about 10 obsolete issues per day should be
> enough to get mantis quite empty soon, I've suggested that some days ago on
> devl.

I guess you may have awared: Lots of the open bugs are undecidable by you or me.

For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
keep asking if this is fixed, yet no reply.

Closing 10 issues per day is too optimistic.


>
> Personally, I use mantis for having a overview of all WoT/Freetalk tasks which
> need to be finished before the next release, it IS very useful to me.
>
> xor
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

[freenet-dev] Getting rid of emu: an option

[sashee]

We had a policy where I worked for some time, that if a bug is
inactive for some time, and cannot be reproduced by the developer,
will be force closed.
This would be applicable to freenet, because if a problem still
exists, users will open a ticket, you cannot expect that users will
search for an open ticket before opening a new one.

sashee

On Mon, Jun 1, 2009 at 1:22 PM, Daniel Cheng  
wrote:
> On Mon, Jun 1, 2009 at 7:15 PM, xor  wrote:
>> On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
>>>
>>> I like this idea. ?I think it is clear that there is a lot of cruft in
>>> Mantis, open bugs that are no-longer relevant etc. ?Cleaning house
>>> would be useful.
>>>
>>> Ian.
>>
>> I am strongly against getting rid of the bugtracker contents if that is what
>> you guys mean.
>>
>> If we were supposed to rate our development process in terms of "best
>> practices", deleting the bugtracker content would probably be the WORST
>> practice which anyone can think of, besides deleting all documentation.
>>
>> I think we should do the following:
>> 1. (FIRST!) clean up mantis
>> 2. migrate to a different bug tracker.
>>
>> As for cleaning up: Resolving about 10 obsolete issues per day should be
>> enough to get mantis quite empty soon, I've suggested that some days ago on
>> devl.
>
> I guess you may have awared: Lots of the open bugs are undecidable by you or 
> me.
>
> For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
> keep asking if this is fixed, yet no reply.
>
> Closing 10 issues per day is too optimistic.
>
>
>>
>> Personally, I use mantis for having a overview of all WoT/Freetalk tasks 
>> which
>> need to be finished before the next release, it IS very useful to me.
>>
>> xor
>>
>>
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>

[freenet-dev] Getting rid of emu: an option

[xor]

On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
>
> I like this idea.  I think it is clear that there is a lot of cruft in
> Mantis, open bugs that are no-longer relevant etc.  Cleaning house
> would be useful.
>
> Ian.

I am strongly against getting rid of the bugtracker contents if that is what 
you guys mean.

If we were supposed to rate our development process in terms of "best 
practices", deleting the bugtracker content would probably be the WORST 
practice which anyone can think of, besides deleting all documentation.

I think we should do the following:
1. (FIRST!) clean up mantis
2. migrate to a different bug tracker.

As for cleaning up: Resolving about 10 obsolete issues per day should be 
enough to get mantis quite empty soon, I've suggested that some days ago on 
devl.

Personally, I use mantis for having a overview of all WoT/Freetalk tasks which 
need to be finished before the next release, it IS very useful to me.

xor

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Sunday 31 May 2009 05:26:33 Juiceman wrote:
> On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
>  wrote:
> > On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
> >> We need to get rid of emu. It costs us a significant amount of money and 
> >> we don't seem able to cost-effecitvely administer it.
> >>
> >> Basically what we need:
> >> - PHP scripts. The website is built with PHP.
> >
> > But it could easily be all static.
> >
> >> - Database-backed PHP for MANTIS. I don't think we should get rid of 
> >> MANTIS.
> >
> > The consensus is we should get a whole new bug tracker and dump all the old 
> > issues, maybe run a copy on a developer's machine for checking old bugs. 
> > IMHO getting rid of the bug database would be a bad thing and lead to 
> > significant work in migration, but ian, nextgens and sdiz think otherwise.
> >
> >> - SSL. We need to serve checksums and signatures through SSL, although big 
> >> files will generally be served through HTTP. It would be nice to serve the 
> >> installer through SSL if we have a huge traffic limit, since code signing 
> >> certs are expensive, on the other hand if we get cheaper hosting we can 
> >> probably afford to buy a code signing cert with a fraction of the money 
> >> saved...
> >> - IMAP accounts ideally, but at least aliases.
> >
> > - Wiki. We need a wiki. There are free wiki providers. Migrating our 
> > existing english language wikka wiki will be some work, migrating the 
> > french mediawiki wiki will be less work.
> >
> > - Mailing lists. Berlios does this, there are also free mailman sites such 
> > as:
> > http://www.glowhost.com/mailman.php
> >
> 
> I don't know what you are paying now, and I have not used them
> personally for hosting but Godaddy.com has hosting with unlimited
> transfers and has PHP and Mantis, wiki software and email accounts for
> $15/month or less and comes with a free SSL cert.

Unlimited transfers = they throttle you down drastically when you get 
slashdotted, no?

Having said that, we might need somewhere to put mantis, if we decide to keep 
it (although everyone else seems to want to get rid of it). We don't have any 
other need for php afaik, although we need SSL redirects.
> 
> https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details
-- 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: 

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Sunday 31 May 2009 05:26:33 Juiceman wrote:
 On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
  We need to get rid of emu. It costs us a significant amount of money and 
  we don't seem able to cost-effecitvely administer it.
 
  Basically what we need:
  - PHP scripts. The website is built with PHP.
 
  But it could easily be all static.
 
  - Database-backed PHP for MANTIS. I don't think we should get rid of 
  MANTIS.
 
  The consensus is we should get a whole new bug tracker and dump all the old 
  issues, maybe run a copy on a developer's machine for checking old bugs. 
  IMHO getting rid of the bug database would be a bad thing and lead to 
  significant work in migration, but ian, nextgens and sdiz think otherwise.
 
  - SSL. We need to serve checksums and signatures through SSL, although big 
  files will generally be served through HTTP. It would be nice to serve the 
  installer through SSL if we have a huge traffic limit, since code signing 
  certs are expensive, on the other hand if we get cheaper hosting we can 
  probably afford to buy a code signing cert with a fraction of the money 
  saved...
  - IMAP accounts ideally, but at least aliases.
 
  - Wiki. We need a wiki. There are free wiki providers. Migrating our 
  existing english language wikka wiki will be some work, migrating the 
  french mediawiki wiki will be less work.
 
  - Mailing lists. Berlios does this, there are also free mailman sites such 
  as:
  http://www.glowhost.com/mailman.php
 
 
 I don't know what you are paying now, and I have not used them
 personally for hosting but Godaddy.com has hosting with unlimited
 transfers and has PHP and Mantis, wiki software and email accounts for
 $15/month or less and comes with a free SSL cert.

Unlimited transfers = they throttle you down drastically when you get 
slashdotted, no?

Having said that, we might need somewhere to put mantis, if we decide to keep 
it (although everyone else seems to want to get rid of it). We don't have any 
other need for php afaik, although we need SSL redirects.
 
 https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details


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

Re: [freenet-dev] Getting rid of emu: an option

[xor]

On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:

 I like this idea.  I think it is clear that there is a lot of cruft in
 Mantis, open bugs that are no-longer relevant etc.  Cleaning house
 would be useful.

 Ian.

I am strongly against getting rid of the bugtracker contents if that is what 
you guys mean.

If we were supposed to rate our development process in terms of best 
practices, deleting the bugtracker content would probably be the WORST 
practice which anyone can think of, besides deleting all documentation.

I think we should do the following:
1. (FIRST!) clean up mantis
2. migrate to a different bug tracker.

As for cleaning up: Resolving about 10 obsolete issues per day should be 
enough to get mantis quite empty soon, I've suggested that some days ago on 
devl.

Personally, I use mantis for having a overview of all WoT/Freetalk tasks which 
need to be finished before the next release, it IS very useful to me.

xor



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

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Mon, Jun 1, 2009 at 7:15 PM, xor x...@gmx.li wrote:
 On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:

 I like this idea.  I think it is clear that there is a lot of cruft in
 Mantis, open bugs that are no-longer relevant etc.  Cleaning house
 would be useful.

 Ian.

 I am strongly against getting rid of the bugtracker contents if that is what
 you guys mean.

 If we were supposed to rate our development process in terms of best
 practices, deleting the bugtracker content would probably be the WORST
 practice which anyone can think of, besides deleting all documentation.

 I think we should do the following:
 1. (FIRST!) clean up mantis
 2. migrate to a different bug tracker.

 As for cleaning up: Resolving about 10 obsolete issues per day should be
 enough to get mantis quite empty soon, I've suggested that some days ago on
 devl.

I guess you may have awared: Lots of the open bugs are undecidable by you or me.

For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
keep asking if this is fixed, yet no reply.

Closing 10 issues per day is too optimistic.



 Personally, I use mantis for having a overview of all WoT/Freetalk tasks which
 need to be finished before the next release, it IS very useful to me.

 xor


 ___
 Devl mailing list
 Devl@freenetproject.org
 http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[sashee]

We had a policy where I worked for some time, that if a bug is
inactive for some time, and cannot be reproduced by the developer,
will be force closed.
This would be applicable to freenet, because if a problem still
exists, users will open a ticket, you cannot expect that users will
search for an open ticket before opening a new one.

sashee

On Mon, Jun 1, 2009 at 1:22 PM, Daniel Cheng j16sdiz+free...@gmail.com wrote:
 On Mon, Jun 1, 2009 at 7:15 PM, xor x...@gmx.li wrote:
 On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:

 I like this idea.  I think it is clear that there is a lot of cruft in
 Mantis, open bugs that are no-longer relevant etc.  Cleaning house
 would be useful.

 Ian.

 I am strongly against getting rid of the bugtracker contents if that is what
 you guys mean.

 If we were supposed to rate our development process in terms of best
 practices, deleting the bugtracker content would probably be the WORST
 practice which anyone can think of, besides deleting all documentation.

 I think we should do the following:
 1. (FIRST!) clean up mantis
 2. migrate to a different bug tracker.

 As for cleaning up: Resolving about 10 obsolete issues per day should be
 enough to get mantis quite empty soon, I've suggested that some days ago on
 devl.

 I guess you may have awared: Lots of the open bugs are undecidable by you or 
 me.

 For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
 keep asking if this is fixed, yet no reply.

 Closing 10 issues per day is too optimistic.



 Personally, I use mantis for having a overview of all WoT/Freetalk tasks 
 which
 need to be finished before the next release, it IS very useful to me.

 xor


 ___
 Devl mailing list
 Devl@freenetproject.org
 http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

 ___
 Devl mailing list
 Devl@freenetproject.org
 http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Zero3]

xor skrev:
 On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
 I like this idea.  I think it is clear that there is a lot of cruft in
 Mantis, open bugs that are no-longer relevant etc.  Cleaning house
 would be useful.

 Ian.
 
 I am strongly against getting rid of the bugtracker contents if that is what 
 you guys mean.
 
 If we were supposed to rate our development process in terms of best 
 practices, deleting the bugtracker content would probably be the WORST 
 practice which anyone can think of, besides deleting all documentation.
 
 I think we should do the following:
 1. (FIRST!) clean up mantis
 2. migrate to a different bug tracker.
 
 As for cleaning up: Resolving about 10 obsolete issues per day should be 
 enough to get mantis quite empty soon, I've suggested that some days ago on 
 devl.
 
 Personally, I use mantis for having a overview of all WoT/Freetalk tasks 
 which 
 need to be finished before the next release, it IS very useful to me.
 
 xor

I have to more or less completely agree with xor. Removing all the old 
bugs seems like running away from all the problems (literally, kind of).

As xor also mentions, we really should focus on keeping the data on 
mantis UP-TO-DATE instead by making sure that bugs are 
assigned/closed/updated etc. instead of simply submitting  forgetting. 
I've been closing a bunch of bugs related to the (now deprecated) 
FireFox profile and the old Windows installer, but I have far from 
enough knowledge about all the technical Freenet stuff to deal with that 
kind of bugs.

- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Monday 01 June 2009 12:22:07 Daniel Cheng wrote:
 On Mon, Jun 1, 2009 at 7:15 PM, xor x...@gmx.li wrote:
  On Saturday 30 May 2009 16:37:15 Ian Clarke wrote:
 
  I like this idea.  I think it is clear that there is a lot of cruft in
  Mantis, open bugs that are no-longer relevant etc.  Cleaning house
  would be useful.
 
  Ian.
 
  I am strongly against getting rid of the bugtracker contents if that is what
  you guys mean.
 
  If we were supposed to rate our development process in terms of best
  practices, deleting the bugtracker content would probably be the WORST
  practice which anyone can think of, besides deleting all documentation.
 
  I think we should do the following:
  1. (FIRST!) clean up mantis
  2. migrate to a different bug tracker.
 
  As for cleaning up: Resolving about 10 obsolete issues per day should be
  enough to get mantis quite empty soon, I've suggested that some days ago on
  devl.
 
 I guess you may have awared: Lots of the open bugs are undecidable by you or 
 me.
 
 For example, https://bugs.freenetproject.org/view.php?id=2669#c5091
 keep asking if this is fixed, yet no reply.

It should be, and the original poster doesn't respond, and there are no dupes 
pointing at it, so mark it as resolved.


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

[freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Saturday, 30. May 2009 19:41:24 Matthew Toseland wrote:
> Emu is constantly segfaulting in php-cgi, this is one reason to want to
> move. It would be partly solved by making it all static.

What exactly is needed? 

I have some 2GiB diskspace and unknown bandwidth laying unused (I grabbed a 
special offer a few years ago :) ). 

The bandwidth max I experienced till now were 130 GiB, normal are about 13 
GiB. Stats of my main page: 
- http://draketo.de/usage/index.html

There's one important question, though: I live in Germany; can I get into 
legal trouble for hosting the website? 

Apart from that, the only issue could be performance - a static site should be 
no problem, though. Dynamic sites are a bit slow. 

If you want to check, if it suffices, I can setup a subaccount. 

The sf.net website service sadly disallows revenue generation - otherwise it 
would be perfect :)

Best wishes, 
Arne

PS: And I wanted to spend the hour playing starcraft. I shouldn't "just check 
my mail" before that ;) 

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sun, May 31, 2009 at 12:26 PM, Juiceman  wrote:
> On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
>  wrote:
>> On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
>>> We need to get rid of emu. It costs us a significant amount of money and we 
>>> don't seem able to cost-effecitvely administer it.
>>>
>>> Basically what we need:
>>> - PHP scripts. The website is built with PHP.
>>
>> But it could easily be all static.
>>
>>> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
>>
>> The consensus is we should get a whole new bug tracker and dump all the old 
>> issues, maybe run a copy on a developer's machine for checking old bugs. 
>> IMHO getting rid of the bug database would be a bad thing and lead to 
>> significant work in migration, but ian, nextgens and sdiz think otherwise.
>>
>>> - SSL. We need to serve checksums and signatures through SSL, although big 
>>> files will generally be served through HTTP. It would be nice to serve the 
>>> installer through SSL if we have a huge traffic limit, since code signing 
>>> certs are expensive, on the other hand if we get cheaper hosting we can 
>>> probably afford to buy a code signing cert with a fraction of the money 
>>> saved...
>>> - IMAP accounts ideally, but at least aliases.
>>
>> - Wiki. We need a wiki. There are free wiki providers. Migrating our 
>> existing english language wikka wiki will be some work, migrating the french 
>> mediawiki wiki will be less work.
>>
>> - Mailing lists. Berlios does this, there are also free mailman sites such 
>> as:
>> http://www.glowhost.com/mailman.php
>>
>
> I don't know what you are paying now, and I have not used them
> personally for hosting but Godaddy.com has hosting with unlimited
> transfers and has PHP and Mantis, wiki software and email accounts for
> $15/month or less and comes with a free SSL cert.
>
> https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details

GoDaddy have the practice of blocking IPs or suspending accounts for
some non-sense "reason".

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sun, May 31, 2009 at 1:43 AM, Matthew Toseland
 wrote:
> On Saturday 30 May 2009 16:11:42 Daniel Cheng wrote:
>> On Sat, May 30, 2009 at 10:09 PM, Florent Daigni?re
>>  wrote:
>> > * Matthew Toseland  [2009-05-30 11:55:17]:
>> []
>> >> - Database-backed PHP for MANTIS. I don't think we should get rid of 
>> >> MANTIS.
>> >
>> > I do think we should; three main reasons:
>> > ? ? ? ?- mantis is just not adapted to our usage anymore (We don't have
>> > ? ? ? ? ?one single tree anymore)
>> > ? ? ? ?- most reported bugs don't apply
>> > ? ? ? ?- It's really a high-maintenance cost application...
>> > ? ? ? ? ?Administrating mantis, patching it, keeping it up to date is a
>> > PITA
>> >
>> > What about using github's issue tracking thingy instead?
>> >
>>
>> GitHub's issue tracking thingy don't even handle dependency of bugs,
>> no real categories (just tags), no milestone thing, no release
>> management... --- this is even worse then what MANTIS has.
>>
>> Most of the github users use LightHouse (http://lighthouseapp.com/),
>> but I have not used it either...
>>
>> Anybody have experience with hosted bug trackers?
>
> Isn't there a lock-in problem? The business model being much the same as 
> Microsoft, they own your data, even if you can download it it's in ?a 
> nonstandard format and can't be taken elsewhere if they suck? So it would be 
> better to get free (or paid) hosting for a standard open source bug tracker, 
> such as MANTIS or Trac?
>

Lighthouse have "export to csv" function. Seriously, I haven't use it
for any real project, so i am not very strong on this.

If you want github integration, the options are:
   - GitHub Issue (very primitive)
   - LightHouse (used by most github user)
   - Trac
   - BaseCamp
   - FogBugz

Of course you can do your own hook for other tracker. but this is what
github currently support.

[freenet-dev] Getting rid of emu: an option

[sich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland a ?crit :
> IMHO the (debatable) fact that the web site sucks is an independant question. 
> Right now we could make it all static and this would improve performance 
> during a slashdotting, make it much easier to find cheap or free hosting, and 
> generally would make a lot of sense. We can worry about changing it later on. 
> The parts that should be dynamic server-side can be, such as forums, but 
> right now we don't have them.
> 
> Emu is constantly segfaulting in php-cgi, this is one reason to want to move. 
> It would be partly solved by making it all static.
> 
> So can we agree on making the web site static content? What is involved in 
> making language auto-selection work in apache for static content?
> 
> PS updating the paypal balance is trivial - fetching the balance happens on a 
> cron job anyway, so we can just substitute it every so often.
> 
> The next task is the bug tracker; other mails will deal with this...

I think that using a static site is a good thing...
There is nothing on the actual site that need to be dynamic, and static
site consume less ressources.

sich
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKIjxaAAoJEELek5QwRDhplasP/iLZSAxzCawnFKasWBGKQw4C
ZbekeEcRvIf/HOOhVwN+lPQuuUj8ss5+oeo/3j11aUAvRXa1kuek7k3ms0HImoPl
KJ0uGkhVpTofw+KTPnVJgSODUV6UbnuIok/ebQwvK5k3/wJu/1PYKGJimjPGg2E3
Fhuuh0plINBGiNPFKgQVaATNxnd/J3vuexiPQMWEODRvQD2JG3UCQTzRLhjN7ebv
6kQG9QNnUv6BJewh3U+eFbS6SfdT7y2XA+cVZT2cEFIVLaXuAOBwjzfWH1/BjoZy
zEFlrFNiVfwASCu4VurPRd2fq93tzCN/fB6mphXjJgaW3mmTWcTSgODUiKW9bATJ
seIitSMsQrPPqkq21bJ/HneK+8wEznA/k5DXjZ8y+lDOf90yxrHyci4kSX0GLZnt
aoh/ov/myBY/S3fd+Z9bJr1w5gcUAgNmhcgQ9cRS8Fqaj7NegQN7ecZZnvF1vO1b
pJSQ19pBKH6hEp4q+kEznRmGtVadmmgLFjv5tzxeoXJn+gMBk05xMs/HQbCVrsei
1HbcWp8ChXa9io8jeCrOk4JbtJC6YSEHFTK9EJYYjt+Ervo+A5KKMyyOj7rJ+LRN
t7vuIbQ0EOrS3GrcDXXIATRCTrofn1vbqIi80vgmnsSQl7FdkagLwudJ0rDohRHJ
iH43xxm1twDvWSxjqh6v
=nzUH
-END PGP SIGNATURE-

[freenet-dev] Getting rid of emu: an option

[Juiceman]

On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
 wrote:
> On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
>> We need to get rid of emu. It costs us a significant amount of money and we 
>> don't seem able to cost-effecitvely administer it.
>>
>> Basically what we need:
>> - PHP scripts. The website is built with PHP.
>
> But it could easily be all static.
>
>> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
>
> The consensus is we should get a whole new bug tracker and dump all the old 
> issues, maybe run a copy on a developer's machine for checking old bugs. IMHO 
> getting rid of the bug database would be a bad thing and lead to significant 
> work in migration, but ian, nextgens and sdiz think otherwise.
>
>> - SSL. We need to serve checksums and signatures through SSL, although big 
>> files will generally be served through HTTP. It would be nice to serve the 
>> installer through SSL if we have a huge traffic limit, since code signing 
>> certs are expensive, on the other hand if we get cheaper hosting we can 
>> probably afford to buy a code signing cert with a fraction of the money 
>> saved...
>> - IMAP accounts ideally, but at least aliases.
>
> - Wiki. We need a wiki. There are free wiki providers. Migrating our existing 
> english language wikka wiki will be some work, migrating the french mediawiki 
> wiki will be less work.
>
> - Mailing lists. Berlios does this, there are also free mailman sites such as:
> http://www.glowhost.com/mailman.php
>

I don't know what you are paying now, and I have not used them
personally for hosting but Godaddy.com has hosting with unlimited
transfers and has PHP and Mantis, wiki software and email accounts for
$15/month or less and comes with a free SSL cert.

https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details

[freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sat, May 30, 2009 at 10:09 PM, Florent Daigni?re
 wrote:
> * Matthew Toseland  [2009-05-30 11:55:17]:
[]
>> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
>
> I do think we should; three main reasons:
> ? ? ? ?- mantis is just not adapted to our usage anymore (We don't have
> ? ? ? ? ?one single tree anymore)
> ? ? ? ?- most reported bugs don't apply
> ? ? ? ?- It's really a high-maintenance cost application...
> ? ? ? ? ?Administrating mantis, patching it, keeping it up to date is a
> PITA
>
> What about using github's issue tracking thingy instead?
>

GitHub's issue tracking thingy don't even handle dependency of bugs,
no real categories (just tags), no milestone thing, no release
management... --- this is even worse then what MANTIS has.

Most of the github users use LightHouse (http://lighthouseapp.com/),
but I have not used it either...

Anybody have experience with hosted bug trackers?

Re: [freenet-dev] Getting rid of emu: an option

[sich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Toseland a écrit :
 IMHO the (debatable) fact that the web site sucks is an independant question. 
 Right now we could make it all static and this would improve performance 
 during a slashdotting, make it much easier to find cheap or free hosting, and 
 generally would make a lot of sense. We can worry about changing it later on. 
 The parts that should be dynamic server-side can be, such as forums, but 
 right now we don't have them.
 
 Emu is constantly segfaulting in php-cgi, this is one reason to want to move. 
 It would be partly solved by making it all static.
 
 So can we agree on making the web site static content? What is involved in 
 making language auto-selection work in apache for static content?
 
 PS updating the paypal balance is trivial - fetching the balance happens on a 
 cron job anyway, so we can just substitute it every so often.
 
 The next task is the bug tracker; other mails will deal with this...

I think that using a static site is a good thing...
There is nothing on the actual site that need to be dynamic, and static
site consume less ressources.

sich
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKIjxaAAoJEELek5QwRDhplasP/iLZSAxzCawnFKasWBGKQw4C
ZbekeEcRvIf/HOOhVwN+lPQuuUj8ss5+oeo/3j11aUAvRXa1kuek7k3ms0HImoPl
KJ0uGkhVpTofw+KTPnVJgSODUV6UbnuIok/ebQwvK5k3/wJu/1PYKGJimjPGg2E3
Fhuuh0plINBGiNPFKgQVaATNxnd/J3vuexiPQMWEODRvQD2JG3UCQTzRLhjN7ebv
6kQG9QNnUv6BJewh3U+eFbS6SfdT7y2XA+cVZT2cEFIVLaXuAOBwjzfWH1/BjoZy
zEFlrFNiVfwASCu4VurPRd2fq93tzCN/fB6mphXjJgaW3mmTWcTSgODUiKW9bATJ
seIitSMsQrPPqkq21bJ/HneK+8wEznA/k5DXjZ8y+lDOf90yxrHyci4kSX0GLZnt
aoh/ov/myBY/S3fd+Z9bJr1w5gcUAgNmhcgQ9cRS8Fqaj7NegQN7ecZZnvF1vO1b
pJSQ19pBKH6hEp4q+kEznRmGtVadmmgLFjv5tzxeoXJn+gMBk05xMs/HQbCVrsei
1HbcWp8ChXa9io8jeCrOk4JbtJC6YSEHFTK9EJYYjt+Ervo+A5KKMyyOj7rJ+LRN
t7vuIbQ0EOrS3GrcDXXIATRCTrofn1vbqIi80vgmnsSQl7FdkagLwudJ0rDohRHJ
iH43xxm1twDvWSxjqh6v
=nzUH
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sun, May 31, 2009 at 1:43 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Saturday 30 May 2009 16:11:42 Daniel Cheng wrote:
 On Sat, May 30, 2009 at 10:09 PM, Florent Daignière
 nextg...@freenetproject.org wrote:
  * Matthew Toseland t...@amphibian.dyndns.org [2009-05-30 11:55:17]:
 []
  - Database-backed PHP for MANTIS. I don't think we should get rid of 
  MANTIS.
 
  I do think we should; three main reasons:
         - mantis is just not adapted to our usage anymore (We don't have
           one single tree anymore)
         - most reported bugs don't apply
         - It's really a high-maintenance cost application...
           Administrating mantis, patching it, keeping it up to date is a
  PITA
 
  What about using github's issue tracking thingy instead?
 

 GitHub's issue tracking thingy don't even handle dependency of bugs,
 no real categories (just tags), no milestone thing, no release
 management... --- this is even worse then what MANTIS has.

 Most of the github users use LightHouse (http://lighthouseapp.com/),
 but I have not used it either...

 Anybody have experience with hosted bug trackers?

 Isn't there a lock-in problem? The business model being much the same as 
 Microsoft, they own your data, even if you can download it it's in  a 
 nonstandard format and can't be taken elsewhere if they suck? So it would be 
 better to get free (or paid) hosting for a standard open source bug tracker, 
 such as MANTIS or Trac?


Lighthouse have export to csv function. Seriously, I haven't use it
for any real project, so i am not very strong on this.

If you want github integration, the options are:
   - GitHub Issue (very primitive)
   - LightHouse (used by most github user)
   - Trac
   - BaseCamp
   - FogBugz

Of course you can do your own hook for other tracker. but this is what
github currently support.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sun, May 31, 2009 at 12:26 PM, Juiceman juicema...@gmail.com wrote:
 On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
 On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
 We need to get rid of emu. It costs us a significant amount of money and we 
 don't seem able to cost-effecitvely administer it.

 Basically what we need:
 - PHP scripts. The website is built with PHP.

 But it could easily be all static.

 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

 The consensus is we should get a whole new bug tracker and dump all the old 
 issues, maybe run a copy on a developer's machine for checking old bugs. 
 IMHO getting rid of the bug database would be a bad thing and lead to 
 significant work in migration, but ian, nextgens and sdiz think otherwise.

 - SSL. We need to serve checksums and signatures through SSL, although big 
 files will generally be served through HTTP. It would be nice to serve the 
 installer through SSL if we have a huge traffic limit, since code signing 
 certs are expensive, on the other hand if we get cheaper hosting we can 
 probably afford to buy a code signing cert with a fraction of the money 
 saved...
 - IMAP accounts ideally, but at least aliases.

 - Wiki. We need a wiki. There are free wiki providers. Migrating our 
 existing english language wikka wiki will be some work, migrating the french 
 mediawiki wiki will be less work.

 - Mailing lists. Berlios does this, there are also free mailman sites such 
 as:
 http://www.glowhost.com/mailman.php


 I don't know what you are paying now, and I have not used them
 personally for hosting but Godaddy.com has hosting with unlimited
 transfers and has PHP and Mantis, wiki software and email accounts for
 $15/month or less and comes with a free SSL cert.

 https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details

GoDaddy have the practice of blocking IPs or suspending accounts for
some non-sense reason.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Arne Babenhauserheide]

On Saturday, 30. May 2009 19:41:24 Matthew Toseland wrote:
 Emu is constantly segfaulting in php-cgi, this is one reason to want to
 move. It would be partly solved by making it all static.

What exactly is needed? 

I have some 2GiB diskspace and unknown bandwidth laying unused (I grabbed a 
special offer a few years ago :) ). 

The bandwidth max I experienced till now were 130 GiB, normal are about 13 
GiB. Stats of my main page: 
- http://draketo.de/usage/index.html

There's one important question, though: I live in Germany; can I get into 
legal trouble for hosting the website? 

Apart from that, the only issue could be performance - a static site should be 
no problem, though. Dynamic sites are a bit slow. 

If you want to check, if it suffices, I can setup a subaccount. 

The sf.net website service sadly disallows revenue generation - otherwise it 
would be perfect :)

Best wishes, 
Arne

PS: And I wanted to spend the hour playing starcraft. I shouldn't just check 
my mail before that ;) 

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
> We need to get rid of emu. It costs us a significant amount of money and we 
> don't seem able to cost-effecitvely administer it.
> 
> Basically what we need:
> - PHP scripts. The website is built with PHP.

But it could easily be all static.

> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

The consensus is we should get a whole new bug tracker and dump all the old 
issues, maybe run a copy on a developer's machine for checking old bugs. IMHO 
getting rid of the bug database would be a bad thing and lead to significant 
work in migration, but ian, nextgens and sdiz think otherwise.

> - SSL. We need to serve checksums and signatures through SSL, although big 
> files will generally be served through HTTP. It would be nice to serve the 
> installer through SSL if we have a huge traffic limit, since code signing 
> certs are expensive, on the other hand if we get cheaper hosting we can 
> probably afford to buy a code signing cert with a fraction of the money 
> saved...
> - IMAP accounts ideally, but at least aliases.

- Wiki. We need a wiki. There are free wiki providers. Migrating our existing 
english language wikka wiki will be some work, migrating the french mediawiki 
wiki will be less work.

- Mailing lists. Berlios does this, there are also free mailman sites such as:
http://www.glowhost.com/mailman.php
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 15:37:15 Ian Clarke wrote:
> On Sat, May 30, 2009 at 9:09 AM, Florent Daigni?re
>  wrote:
> > Well, the website is all about its content; not the engine... I do think
> > that google's website thingy (http://sites.google.com) is more than
> > enough for our purpose.
> 
> I like this idea, provided that it is sufficient to meet our needs.
> For example, it would be hard to do things like dynamic updating of
> our account balance - which seems to have a very positive effect on
> donations.  I guess we could run some code elsewhere that periodically
> updates this (does Google Pages have an API?).
> 
> Can you have your own domain name with Google Pages?

Google Sites is a dynamic thingy, basically all we need is static web hosting 
for pages and a few big files. The few big files will be served through 
coralcache unless we have a huge monthly transfer limit.
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 15:09:51 Florent Daigni?re wrote:
> * Matthew Toseland  [2009-05-30 11:55:17]:
> > Anything I've missed?
> > 
> > One option:
> > 
> > http://www.uk2.net/web-hosting/
> > 
> > Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
> > bytemark, even if we qualified for the 50% discount for the main 
> > distributor of free software), domain hosting, and a (very basic) uptime 
> > SLA, for ?13.95 to ?19.95/mo depending on how long we buy it for (2 years 
> > down to 1 month).
> > 
> > Thoughts?
> 
> I don't like your option, their SLA is a joke and we can probably get
> the same thing for free from google/sourceforge/...
> 
> 30sec of googleing returned me that link:
> http://www.ibiblio.org/fosphost/exhost.htm

AFAICS only Berlios is suitable. Asynchrony don't seem to do free project 
hosting any more, we've tried sourceforge, savannah is currently unreachable 
for me.

Berlios has mantis, but I doubt we'll be able to import existing mantis data.

Google App Engine is total overkill, and has been quite slow for this year's 
summer of code stuff, but really we should do fine with $5/month basic hosting 
and Coral Cache...
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 16:11:42 Daniel Cheng wrote:
> On Sat, May 30, 2009 at 10:09 PM, Florent Daigni?re
>  wrote:
> > * Matthew Toseland  [2009-05-30 11:55:17]:
> []
> >> - Database-backed PHP for MANTIS. I don't think we should get rid of 
> >> MANTIS.
> >
> > I do think we should; three main reasons:
> > ? ? ? ?- mantis is just not adapted to our usage anymore (We don't have
> > ? ? ? ? ?one single tree anymore)
> > ? ? ? ?- most reported bugs don't apply
> > ? ? ? ?- It's really a high-maintenance cost application...
> > ? ? ? ? ?Administrating mantis, patching it, keeping it up to date is a
> > PITA
> >
> > What about using github's issue tracking thingy instead?
> >
> 
> GitHub's issue tracking thingy don't even handle dependency of bugs,
> no real categories (just tags), no milestone thing, no release
> management... --- this is even worse then what MANTIS has.
> 
> Most of the github users use LightHouse (http://lighthouseapp.com/),
> but I have not used it either...
> 
> Anybody have experience with hosted bug trackers?

Isn't there a lock-in problem? The business model being much the same as 
Microsoft, they own your data, even if you can download it it's in  a 
nonstandard format and can't be taken elsewhere if they suck? So it would be 
better to get free (or paid) hosting for a standard open source bug tracker, 
such as MANTIS or Trac?
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 17:01:25 Ian Clarke wrote:
> On Sat, May 30, 2009 at 9:41 AM, Florent Daigni?re
>  wrote:
> > Tools won't help the fact that we don't have good web-designers :)
> 
> If you can't do it yourself, copy someone that can.  That is the
> beauty of open source.
> 
> There are plenty of open source css and html files we could use as a
> starting point.  Does anyone care to find some examples?
> 
> To get us started Mozilla has some:
> 
>   http://www.mozilla.com/en-US/firefox/personal.html?from=getfirefox
> 
>   http://www.mozillamessaging.com/en-US/thunderbird/
> 
>   http://getsongbird.com/
> 
> Ian.

IMHO the (debatable) fact that the web site sucks is an independant question. 
Right now we could make it all static and this would improve performance during 
a slashdotting, make it much easier to find cheap or free hosting, and 
generally would make a lot of sense. We can worry about changing it later on. 
The parts that should be dynamic server-side can be, such as forums, but right 
now we don't have them.

Emu is constantly segfaulting in php-cgi, this is one reason to want to move. 
It would be partly solved by making it all static.

So can we agree on making the web site static content? What is involved in 
making language auto-selection work in apache for static content?

PS updating the paypal balance is trivial - fetching the balance happens on a 
cron job anyway, so we can just substitute it every so often.

The next task is the bug tracker; other mails will deal with this...
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Florent Daignière]

* Ian Clarke  [2009-05-30 09:37:15]:

> On Sat, May 30, 2009 at 9:09 AM, Florent Daigni?re
>  wrote:
> > Well, the website is all about its content; not the engine... I do think
> > that google's website thingy (http://sites.google.com) is more than
> > enough for our purpose.
> 
> I like this idea, provided that it is sufficient to meet our needs.
> For example, it would be hard to do things like dynamic updating of
> our account balance - which seems to have a very positive effect on
> donations.  I guess we could run some code elsewhere that periodically
> updates this (does Google Pages have an API?).
> 
> Can you have your own domain name with Google Pages?
> 

Probably, through google-apps; We use that at work.

> Google App Engine would afford the most flexibility (but also the most
> rope to hang ourselves), and it now supports Java.  If we do migrate
> the website we *must* endeavor to make it look good, people have much
> higher expectations about a website's appearance today than they did 9
> years ago.  Ideally we should grab some open source web code to use as
> a basis (perhaps something from Mozilla).
> 

Tools won't help the fact that we don't have good web-designers :)

NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 

[freenet-dev] Getting rid of emu: an option

[Florent Daignière]

* Matthew Toseland  [2009-05-30 11:55:17]:

> We need to get rid of emu. It costs us a significant amount of money and we 
> don't seem able to cost-effecitvely administer it.
> 
> Basically what we need:
> - PHP scripts. The website is built with PHP.

Well, the website is all about its content; not the engine... I do think
that google's website thingy (http://sites.google.com) is more than
enough for our purpose.

We use to have our own engine and to maintain it in svn on the basis
that only devs are contributing to it; Let's face it: even devs don't.
The PHP engine we are using is home-grown, high-maintenance cost and
its security is debatable (We had many flaws in the past and I bet they
are still many others).

That's typically one of the things we should delegate...

> - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

I do think we should; three main reasons:
- mantis is just not adapted to our usage anymore (We don't have
  one single tree anymore)
- most reported bugs don't apply
- It's really a high-maintenance cost application...
  Administrating mantis, patching it, keeping it up to date is a
PITA

What about using github's issue tracking thingy instead?

> - SSL. We need to serve checksums and signatures through SSL, although big 
> files will generally be served through HTTP. It would be nice to serve the 
> installer through SSL if we have a huge traffic limit, since code signing 
> certs are expensive, on the other hand if we get cheaper hosting we can 
> probably afford to buy a code signing cert with a fraction of the money 
> saved...

We can use sourceforge's/google's distribution infrastructure there too.
I'm not sure they do SSL but our current setup doesn't either.

> - IMAP accounts ideally, but at least aliases.
> 

For that one I can't think about any alternative right away...
http://wiki.list.org/display/COM/Mailman+hosting+services
but I'm sure we can find someone doing it there.

> What we do NOT need:
> - Auto-build. This is difficult to secure, and not really compatible with a 
> secure git-based workflow.
> 
> Anything I've missed?
> 
> One option:
> 
> http://www.uk2.net/web-hosting/
> 
> Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
> bytemark, even if we qualified for the 50% discount for the main distributor 
> of free software), domain hosting, and a (very basic) uptime SLA, for ?13.95 
> to ?19.95/mo depending on how long we buy it for (2 years down to 1 month).
> 
> Thoughts?

I don't like your option, their SLA is a joke and we can probably get
the same thing for free from google/sourceforge/...

30sec of googleing returned me that link:
http://www.ibiblio.org/fosphost/exhost.htm

My $0.02
NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

We need to get rid of emu. It costs us a significant amount of money and we 
don't seem able to cost-effecitvely administer it.

Basically what we need:
- PHP scripts. The website is built with PHP.
- Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
- SSL. We need to serve checksums and signatures through SSL, although big 
files will generally be served through HTTP. It would be nice to serve the 
installer through SSL if we have a huge traffic limit, since code signing certs 
are expensive, on the other hand if we get cheaper hosting we can probably 
afford to buy a code signing cert with a fraction of the money saved...
- IMAP accounts ideally, but at least aliases.

What we do NOT need:
- Auto-build. This is difficult to secure, and not really compatible with a 
secure git-based workflow.

Anything I've missed?

One option:

http://www.uk2.net/web-hosting/

Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
bytemark, even if we qualified for the 50% discount for the main distributor of 
free software), domain hosting, and a (very basic) uptime SLA, for ?13.95 to 
?19.95/mo depending on how long we buy it for (2 years down to 1 month).

Thoughts?
-- 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: 

[freenet-dev] Getting rid of emu: an option

[Ian Clarke]

On Sat, May 30, 2009 at 9:41 AM, Florent Daigni?re
 wrote:
> Tools won't help the fact that we don't have good web-designers :)

If you can't do it yourself, copy someone that can.  That is the
beauty of open source.

There are plenty of open source css and html files we could use as a
starting point.  Does anyone care to find some examples?

To get us started Mozilla has some:

  http://www.mozilla.com/en-US/firefox/personal.html?from=getfirefox

  http://www.mozillamessaging.com/en-US/thunderbird/

  http://getsongbird.com/

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

[freenet-dev] Getting rid of emu: an option

[Ian Clarke]

On Sat, May 30, 2009 at 9:09 AM, Florent Daigni?re
 wrote:
> Well, the website is all about its content; not the engine... I do think
> that google's website thingy (http://sites.google.com) is more than
> enough for our purpose.

I like this idea, provided that it is sufficient to meet our needs.
For example, it would be hard to do things like dynamic updating of
our account balance - which seems to have a very positive effect on
donations.  I guess we could run some code elsewhere that periodically
updates this (does Google Pages have an API?).

Can you have your own domain name with Google Pages?

Google App Engine would afford the most flexibility (but also the most
rope to hang ourselves), and it now supports Java.  If we do migrate
the website we *must* endeavor to make it look good, people have much
higher expectations about a website's appearance today than they did 9
years ago.  Ideally we should grab some open source web code to use as
a basis (perhaps something from Mozilla).

> What about using github's issue tracking thingy instead?

I like this idea.  I think it is clear that there is a lot of cruft in
Mantis, open bugs that are no-longer relevant etc.  Cleaning house
would be useful.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

[freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

We need to get rid of emu. It costs us a significant amount of money and we 
don't seem able to cost-effecitvely administer it.

Basically what we need:
- PHP scripts. The website is built with PHP.
- Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.
- SSL. We need to serve checksums and signatures through SSL, although big 
files will generally be served through HTTP. It would be nice to serve the 
installer through SSL if we have a huge traffic limit, since code signing certs 
are expensive, on the other hand if we get cheaper hosting we can probably 
afford to buy a code signing cert with a fraction of the money saved...
- IMAP accounts ideally, but at least aliases.

What we do NOT need:
- Auto-build. This is difficult to secure, and not really compatible with a 
secure git-based workflow.

Anything I've missed?

One option:

http://www.uk2.net/web-hosting/

Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
bytemark, even if we qualified for the 50% discount for the main distributor of 
free software), domain hosting, and a (very basic) uptime SLA, for £13.95 to 
£19.95/mo depending on how long we buy it for (2 years down to 1 month).

Thoughts?


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

Re: [freenet-dev] Getting rid of emu: an option

[Florent Daignière]

* Matthew Toseland t...@amphibian.dyndns.org [2009-05-30 11:55:17]:

 We need to get rid of emu. It costs us a significant amount of money and we 
 don't seem able to cost-effecitvely administer it.
 
 Basically what we need:
 - PHP scripts. The website is built with PHP.

Well, the website is all about its content; not the engine... I do think
that google's website thingy (http://sites.google.com) is more than
enough for our purpose.

We use to have our own engine and to maintain it in svn on the basis
that only devs are contributing to it; Let's face it: even devs don't.
The PHP engine we are using is home-grown, high-maintenance cost and
its security is debatable (We had many flaws in the past and I bet they
are still many others).

That's typically one of the things we should delegate...

 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

I do think we should; three main reasons:
- mantis is just not adapted to our usage anymore (We don't have
  one single tree anymore)
- most reported bugs don't apply
- It's really a high-maintenance cost application...
  Administrating mantis, patching it, keeping it up to date is a
PITA

What about using github's issue tracking thingy instead?

 - SSL. We need to serve checksums and signatures through SSL, although big 
 files will generally be served through HTTP. It would be nice to serve the 
 installer through SSL if we have a huge traffic limit, since code signing 
 certs are expensive, on the other hand if we get cheaper hosting we can 
 probably afford to buy a code signing cert with a fraction of the money 
 saved...

We can use sourceforge's/google's distribution infrastructure there too.
I'm not sure they do SSL but our current setup doesn't either.

 - IMAP accounts ideally, but at least aliases.
 

For that one I can't think about any alternative right away...
http://wiki.list.org/display/COM/Mailman+hosting+services
but I'm sure we can find someone doing it there.

 What we do NOT need:
 - Auto-build. This is difficult to secure, and not really compatible with a 
 secure git-based workflow.
 
 Anything I've missed?
 
 One option:
 
 http://www.uk2.net/web-hosting/
 
 Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
 bytemark, even if we qualified for the 50% discount for the main distributor 
 of free software), domain hosting, and a (very basic) uptime SLA, for £13.95 
 to £19.95/mo depending on how long we buy it for (2 years down to 1 month).
 
 Thoughts?

I don't like your option, their SLA is a joke and we can probably get
the same thing for free from google/sourceforge/...

30sec of googleing returned me that link:
http://www.ibiblio.org/fosphost/exhost.htm

My $0.02
NextGen$


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Ian Clarke]

On Sat, May 30, 2009 at 9:09 AM, Florent Daignière
nextg...@freenetproject.org wrote:
 Well, the website is all about its content; not the engine... I do think
 that google's website thingy (http://sites.google.com) is more than
 enough for our purpose.

I like this idea, provided that it is sufficient to meet our needs.
For example, it would be hard to do things like dynamic updating of
our account balance - which seems to have a very positive effect on
donations.  I guess we could run some code elsewhere that periodically
updates this (does Google Pages have an API?).

Can you have your own domain name with Google Pages?

Google App Engine would afford the most flexibility (but also the most
rope to hang ourselves), and it now supports Java.  If we do migrate
the website we *must* endeavor to make it look good, people have much
higher expectations about a website's appearance today than they did 9
years ago.  Ideally we should grab some open source web code to use as
a basis (perhaps something from Mozilla).

 What about using github's issue tracking thingy instead?

I like this idea.  I think it is clear that there is a lot of cruft in
Mantis, open bugs that are no-longer relevant etc.  Cleaning house
would be useful.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Florent Daignière]

* Ian Clarke i...@locut.us [2009-05-30 09:37:15]:

 On Sat, May 30, 2009 at 9:09 AM, Florent Daignière
 nextg...@freenetproject.org wrote:
  Well, the website is all about its content; not the engine... I do think
  that google's website thingy (http://sites.google.com) is more than
  enough for our purpose.
 
 I like this idea, provided that it is sufficient to meet our needs.
 For example, it would be hard to do things like dynamic updating of
 our account balance - which seems to have a very positive effect on
 donations.  I guess we could run some code elsewhere that periodically
 updates this (does Google Pages have an API?).
 
 Can you have your own domain name with Google Pages?
 

Probably, through google-apps; We use that at work.

 Google App Engine would afford the most flexibility (but also the most
 rope to hang ourselves), and it now supports Java.  If we do migrate
 the website we *must* endeavor to make it look good, people have much
 higher expectations about a website's appearance today than they did 9
 years ago.  Ideally we should grab some open source web code to use as
 a basis (perhaps something from Mozilla).
 

Tools won't help the fact that we don't have good web-designers :)

NextGen$


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Daniel Cheng]

On Sat, May 30, 2009 at 10:09 PM, Florent Daignière
nextg...@freenetproject.org wrote:
 * Matthew Toseland t...@amphibian.dyndns.org [2009-05-30 11:55:17]:
[]
 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

 I do think we should; three main reasons:
        - mantis is just not adapted to our usage anymore (We don't have
          one single tree anymore)
        - most reported bugs don't apply
        - It's really a high-maintenance cost application...
          Administrating mantis, patching it, keeping it up to date is a
 PITA

 What about using github's issue tracking thingy instead?


GitHub's issue tracking thingy don't even handle dependency of bugs,
no real categories (just tags), no milestone thing, no release
management... --- this is even worse then what MANTIS has.

Most of the github users use LightHouse (http://lighthouseapp.com/),
but I have not used it either...

Anybody have experience with hosted bug trackers?
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Ian Clarke]

On Sat, May 30, 2009 at 9:41 AM, Florent Daignière
nextg...@freenetproject.org wrote:
 Tools won't help the fact that we don't have good web-designers :)

If you can't do it yourself, copy someone that can.  That is the
beauty of open source.

There are plenty of open source css and html files we could use as a
starting point.  Does anyone care to find some examples?

To get us started Mozilla has some:

  http://www.mozilla.com/en-US/firefox/personal.html?from=getfirefox

  http://www.mozillamessaging.com/en-US/thunderbird/

  http://getsongbird.com/

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 17:01:25 Ian Clarke wrote:
 On Sat, May 30, 2009 at 9:41 AM, Florent Daignière
 nextg...@freenetproject.org wrote:
  Tools won't help the fact that we don't have good web-designers :)
 
 If you can't do it yourself, copy someone that can.  That is the
 beauty of open source.
 
 There are plenty of open source css and html files we could use as a
 starting point.  Does anyone care to find some examples?
 
 To get us started Mozilla has some:
 
   http://www.mozilla.com/en-US/firefox/personal.html?from=getfirefox
 
   http://www.mozillamessaging.com/en-US/thunderbird/
 
   http://getsongbird.com/
 
 Ian.

IMHO the (debatable) fact that the web site sucks is an independant question. 
Right now we could make it all static and this would improve performance during 
a slashdotting, make it much easier to find cheap or free hosting, and 
generally would make a lot of sense. We can worry about changing it later on. 
The parts that should be dynamic server-side can be, such as forums, but right 
now we don't have them.

Emu is constantly segfaulting in php-cgi, this is one reason to want to move. 
It would be partly solved by making it all static.

So can we agree on making the web site static content? What is involved in 
making language auto-selection work in apache for static content?

PS updating the paypal balance is trivial - fetching the balance happens on a 
cron job anyway, so we can just substitute it every so often.

The next task is the bug tracker; other mails will deal with this...


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 16:11:42 Daniel Cheng wrote:
 On Sat, May 30, 2009 at 10:09 PM, Florent Daignière
 nextg...@freenetproject.org wrote:
  * Matthew Toseland t...@amphibian.dyndns.org [2009-05-30 11:55:17]:
 []
  - Database-backed PHP for MANTIS. I don't think we should get rid of 
  MANTIS.
 
  I do think we should; three main reasons:
         - mantis is just not adapted to our usage anymore (We don't have
           one single tree anymore)
         - most reported bugs don't apply
         - It's really a high-maintenance cost application...
           Administrating mantis, patching it, keeping it up to date is a
  PITA
 
  What about using github's issue tracking thingy instead?
 
 
 GitHub's issue tracking thingy don't even handle dependency of bugs,
 no real categories (just tags), no milestone thing, no release
 management... --- this is even worse then what MANTIS has.
 
 Most of the github users use LightHouse (http://lighthouseapp.com/),
 but I have not used it either...
 
 Anybody have experience with hosted bug trackers?

Isn't there a lock-in problem? The business model being much the same as 
Microsoft, they own your data, even if you can download it it's in  a 
nonstandard format and can't be taken elsewhere if they suck? So it would be 
better to get free (or paid) hosting for a standard open source bug tracker, 
such as MANTIS or Trac?


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 15:09:51 Florent Daignière wrote:
 * Matthew Toseland t...@amphibian.dyndns.org [2009-05-30 11:55:17]:
  Anything I've missed?
  
  One option:
  
  http://www.uk2.net/web-hosting/
  
  Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with 
  bytemark, even if we qualified for the 50% discount for the main 
  distributor of free software), domain hosting, and a (very basic) uptime 
  SLA, for £13.95 to £19.95/mo depending on how long we buy it for (2 years 
  down to 1 month).
  
  Thoughts?
 
 I don't like your option, their SLA is a joke and we can probably get
 the same thing for free from google/sourceforge/...
 
 30sec of googleing returned me that link:
 http://www.ibiblio.org/fosphost/exhost.htm

AFAICS only Berlios is suitable. Asynchrony don't seem to do free project 
hosting any more, we've tried sourceforge, savannah is currently unreachable 
for me.

Berlios has mantis, but I doubt we'll be able to import existing mantis data.

Google App Engine is total overkill, and has been quite slow for this year's 
summer of code stuff, but really we should do fine with $5/month basic hosting 
and Coral Cache...


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 15:37:15 Ian Clarke wrote:
 On Sat, May 30, 2009 at 9:09 AM, Florent Daignière
 nextg...@freenetproject.org wrote:
  Well, the website is all about its content; not the engine... I do think
  that google's website thingy (http://sites.google.com) is more than
  enough for our purpose.
 
 I like this idea, provided that it is sufficient to meet our needs.
 For example, it would be hard to do things like dynamic updating of
 our account balance - which seems to have a very positive effect on
 donations.  I guess we could run some code elsewhere that periodically
 updates this (does Google Pages have an API?).
 
 Can you have your own domain name with Google Pages?

Google Sites is a dynamic thingy, basically all we need is static web hosting 
for pages and a few big files. The few big files will be served through 
coralcache unless we have a huge monthly transfer limit.


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

Re: [freenet-dev] Getting rid of emu: an option

[Matthew Toseland]

On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
 We need to get rid of emu. It costs us a significant amount of money and we 
 don't seem able to cost-effecitvely administer it.
 
 Basically what we need:
 - PHP scripts. The website is built with PHP.

But it could easily be all static.

 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

The consensus is we should get a whole new bug tracker and dump all the old 
issues, maybe run a copy on a developer's machine for checking old bugs. IMHO 
getting rid of the bug database would be a bad thing and lead to significant 
work in migration, but ian, nextgens and sdiz think otherwise.

 - SSL. We need to serve checksums and signatures through SSL, although big 
 files will generally be served through HTTP. It would be nice to serve the 
 installer through SSL if we have a huge traffic limit, since code signing 
 certs are expensive, on the other hand if we get cheaper hosting we can 
 probably afford to buy a code signing cert with a fraction of the money 
 saved...
 - IMAP accounts ideally, but at least aliases.

- Wiki. We need a wiki. There are free wiki providers. Migrating our existing 
english language wikka wiki will be some work, migrating the french mediawiki 
wiki will be less work.

- Mailing lists. Berlios does this, there are also free mailman sites such as:
http://www.glowhost.com/mailman.php


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

Re: [freenet-dev] Getting rid of emu: an option

[Juiceman]

On Sat, May 30, 2009 at 3:24 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote:
 We need to get rid of emu. It costs us a significant amount of money and we 
 don't seem able to cost-effecitvely administer it.

 Basically what we need:
 - PHP scripts. The website is built with PHP.

 But it could easily be all static.

 - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS.

 The consensus is we should get a whole new bug tracker and dump all the old 
 issues, maybe run a copy on a developer's machine for checking old bugs. IMHO 
 getting rid of the bug database would be a bad thing and lead to significant 
 work in migration, but ian, nextgens and sdiz think otherwise.

 - SSL. We need to serve checksums and signatures through SSL, although big 
 files will generally be served through HTTP. It would be nice to serve the 
 installer through SSL if we have a huge traffic limit, since code signing 
 certs are expensive, on the other hand if we get cheaper hosting we can 
 probably afford to buy a code signing cert with a fraction of the money 
 saved...
 - IMAP accounts ideally, but at least aliases.

 - Wiki. We need a wiki. There are free wiki providers. Migrating our existing 
 english language wikka wiki will be some work, migrating the french mediawiki 
 wiki will be less work.

 - Mailing lists. Berlios does this, there are also free mailman sites such as:
 http://www.glowhost.com/mailman.php


I don't know what you are paying now, and I have not used them
personally for hosting but Godaddy.com has hosting with unlimited
transfers and has PHP and Mantis, wiki software and email accounts for
$15/month or less and comes with a free SSL cert.

https://www.godaddy.com/Hosting/shared.aspx?app_hdr=#details
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl