On Wednesday, March 01, 2017 12:06:59 AM Florent Daigniere wrote: > On Tue, 2017-02-28 at 19:04 +0100, x...@freenetproject.org wrote: > > On Tuesday, February 28, 2017 09:03:07 AM Florent Daigniere wrote: > > > If you want to be useful, compile a list of *all* the requirements; > > > that's what we need. > > > > - SSL for the website + downloads. > > SSL from where to where? Which URLs do we want to keep? Right now the > downloads come from github!
Well if we need a CDN we will likely have to redirect the https connections from us to different https connections to the CDN I suppose? As long as non of the handovers involves a non-SSL connection I'm fine. With regards to URLs: How about we only keep URLs to documentation the same? > > - SSL must be compatible with the SSL stuff fred uses for downloading > > plugins > > (and updates?). Same for update.sh / update.cmd / what we provide for > > MacOS. > > Clarify what you mean by "compatible"; The current certificate will > expire soon... Even if I find a drop-in replacement it will eventually > break. It must at most require only a small amount of work to adapt our existing code to the new certs. And uhm, it must be a simple enough job that we actually have someone willing and capable to do it; given that I suppose you don't want to be bothered with this? > > - Dan's implementation of the new site design must actually work on > > it. > > - automatic language detection & redirect to the translation. Sounds > > simple > > but IIRC GitHub has issues with it. AFAIK Dan has used a framework > > which is > > suitable for this, so it's may only be a matter of choosing a hoster > > which > > allows that framework. Re-doing the site in another framework would > > take too > > long as our SSL cert expires soon. > > I am not sure what you are alluding to; We can always do it with > javascript. I'm merely repeating what someone had once said on IRC - that hosting on GitHub wouldn't work with translations, or require manual language selection at least - don't remember the precise details. Also don't remember who said it, though I actually feel it was you :| > > - the devl and support mailing lists must keep working. The others are > > dead. > > Again; what does "keep working" mean? We are moving away from mailman, > do we need them to have the same addresses? I would say I don't care whether they have the same address - we can just send a final mail to all existing subscribers telling them where they should send mails to from now on. BUT: Besides the mailing lists I'd consider it as crucial to keep the developer mail address forwards working - so if we already have mail forwards, it should be possible to keep devl having the same address by just forwarding it to the new location? It would be very good if we could import the set of existing subscribers, otherwise we may lose many lurkers. The new service should allow new users to sign up by mail or web interface without us having to do anything, we got enough maintenance tasks already. That may be an issue with Amazon WorkMail? http://docs.aws.amazon.com/workmail/latest/userguide/create_distribution_list.html I'm not sure whether that is the only mailing list feature they have, I've never seen their web interface so I can only google blindly. > Do we need the moderation features? We don't have enough traffic to require someone to cherry-pick individual mails to reduce traffic, so no. It's enough if: - non-subscribers cannot mail the list (to avoid spam) - we can ban subscribers if they start to offend. > > - bonus, not requirement: subdomains + htaccess redirects or HTML > > redirects. > > Yes, HTML redirs would be ugly but can have the useful effect of > > showing the > > visitor a text before the redirect happens, e.g. "Redirecting you to a > > read- > > only copy of our old Wiki. Our new writable Wiki is located at GitHub > > here:". > > I don't understand what you mean by subdomains. If we want to keep old links working, we need to be able to keep "wiki.freenetproject.org" etc. working and put something there to redirect traffic. > There's no way we can fit the above requirements with a single product; > For the websites we are heading for: > route53, KMS, ACM, cloudfront, S3 and maybe API-gateway+lambda Thanks for looking all those up. Is there anything of the above requirements which you think they cannot fulfill? I suppose given they contain a special DNS service (route53) *and* the ability to run code (lambda) we can do redirects as we please to keep old URLs working, so the only remaining complex issue is perhaps the mail/mailing list stuff? > For "email" the requirements aren't clear enough; probably > SES + WorkMail What needs clarification? > But we need something else if we keep the mailing lists... which right > now I am not convinced we should. Could you be convinced if someone else offered to take over moderation and/or administration?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
