[haiku-inc] Re: Contract proposal: website & R1B1 work
- From: Augustin Cavalier <waddlesplash@xxxxxxxxx>
- To: haiku-inc@xxxxxxxxxxxxx
- Date: Sun, 3 May 2015 18:20:52 -0400
On Sun, May 3, 2015 at 4:48 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
While working on that would be much appreciated, I think it's actually
still too early for the migration to Drupal 8. First of all, it hasn't been
released yet, and second of all, this version is supposed to offer a
migration path from earlier releases.
Until that becomes available, I wouldn't waste any time on it. Who knows,
it might actually work :-)
Yes, Drupal 8 provides a migration path, but it's for *content only*.
Modules, themes, etc. can't be automatically migrated, so we have to
manually convert our themes (or replace them) and then remove / replace
modules (some of which we no longer use, hence the 'remove' bit.)
Instead of migrating already, I would rather like to see an analysis of
1) where our current problems are,
Page load times in southeast Asia are really, really slow (~12s from enter
key -> page loaded, on average), for example.
2) what we should try to change,
The frontpage hitting PHP 100% of the time is really annoying, but that's
due to Google Analytics apparently so not much we can do with that. But if
we switch to CloudFlare, we can let them handle the GA injection, and thus
hit the Boost cache more often.
Other than that, not much we can do, as even static content load speeds are
really slow to that region (and others, that one is just the worst.)
and finally,
3) how would the migration work, and would it entail, what changes would
be caused to the current infrastructure.
The only change would be to (a) remove Drupal modules that CloudFlare can
handle (GA, etc.) and (b) change our nameserver to CloudFlare's. That's it.
4) what are the costs?
We can pay $25 / month for improved speed & DDoS protection over the free
plan if we like the free plan.
While this would all be welcome, too, it's also mostly stuff that doesn't
really get us much further to the actual release. I would rather like to
see someone working on solving the infrastructure that prevents us from
releasing than mostly cosmetic changes.
I'm willing to do that. The current Ruby-based client for Alex's package
build server is a bit flaky, so I'm not sure if we can use a Ruby client...
I'm working on porting IOjs, which is significantly less reliant on POSIX
threading extensions, so it should be more stable.
-Augustin
Other related posts:
