> -----Original Message-----
> From: Andrea Pescetti [mailto:[email protected]]
> Sent: Thursday, 8 December 2011 10:01 PM
> To: [email protected]
> Subject: Re: Extensions and templates
>
> Gavin McDonald wrote:
> >> From: Andrea Pescetti
> >> On 29/11/2011 Rob Weir wrote:
> >>> ==Option 1: Remain at OSUOSL==
> >>> We could remain with OSUOSL hosting. However, the existing site is
> >>> very unstable.
> >> This would be best both for short and long term. ...
> > Sorry, OSUOSL don’t want anything to do with these any longer
>
> As I wrote, Options 1 and 3 (i.e., staying with OSUOSL or cloning to another
> host) are fundamentally equivalent to me. My point is that the best first step
> is starting from the current websites or a clone of them.
>
> > The hosts themselves cannot cope with all the memory and cpu these are
> > consuming all the time, let alone the bandwidth.
>
> Then someone should explain why they were absolutely stable in 2010, with
> a traffic that can be safely assumed to be similar to the one they are
> receiving
> in 2011. Something broke, and since the Drupal code hasn't changed I still
> think that the malfunctioning components are somewhere else (or, if in
> Drupal, not in the site itself but in the interface to caching engines).
No clue, I wasn’t involved at that time.
>
> > I've had a look around
> > the drupal sites and it is not optimal to say the least.
>
> It would be helpful to know what level of access you obtained to make this
> assessment. Could you read the site code, or did you receive administrator
> credentials for the website, or did you get shell access to the machine?
Shell access to the machine, it is the code/files I'm talking about, rather
than
the usage /admin of the site itself (at this stage).
>
> That the sites are not optimal is fairly obvious, especially considering that
> Extensions is a Drupal 5 site and thus creates sessions even for anonymous
> users; Drupal 7 is much better in this respect and offers more scalability out
> of the box and better integration with caching engines, so it seems a natural
> candidate for medium-term and long-term improvements ("Option 5").
Agree.
>
> >>> ==Option 2: Move Critical extensions to stable host==
> >> Indeed, as you write, this would be an extreme option.
> > More extreme would be to do nothing, as you'll end up with nothing.
>
> Of course. What I meant to say was: cherry-picking "important"
> extensions and creating a repository for them from scratch is more or less
> the same work of Option 1 or 3 (i.e., fix the current site or a clone of it)
> for a
> much less interesting result.
>
> >>> ==Option 3: Clone OSUOSL repositories to another host==
> >> This is not significantly different from Option 1; i.e., if there are
> >> other hosting options available the mere cloning of the site would
> >> not take long, but again the problem is not with the site but with caching.
> > Do not blame caches for poor performance. the caches are improving a
> > bad situation
>
> OK, no matter what we think about the root cause for the current bad
> performance it seems that we both agree that cloning the site will give us the
> possibility to tweak it (or the environment) and improve performance. Since
> I've seen it working perfectly in 2010, I'm confident this is achievable.
cool
>
> >>> ==Option 4: Host repositories elsewhere, using new UI==
> >> As I used to say, everybody who thinks that the Extensions or
> >> Templates sites can be replaced easily has never tried submitting a
> template!
> >> Thorsten did a lot of customization work on the two sites; any
> >> replacement would provide a largely inferior user experience.
> > I think you don’t think very highly of other peoples abilities, a poor
> > outlook.
>
> That was just a warning: people should know (and they would know, if they
> had ever uploaded a template...) that the sites extract and use a lot of
> information specific to OpenOffice.org and ODF files. This is often overlooked
> when people see these sites as "some form of file repositories" and propose
> to rely on different solutions: they should be aware that, to provide an
> optimal user experience for our use case, a significant amount of custom
> code must be added.
>
> >>> ==Option 5: Re-architect the Repositories== This is the option I
> >>> personally favor for long term. ...
>
> OK, it seems we have agreement, at least at broad scope, that the long-term
> solution will be along the lines of Option 5 (i.e., encourage or enforce
> external hosting; allow for a scenario involving several different
> repositories).
>
> > here is the route I intend to take:
> > 1. Move the services to a newer more modern host at the ASF
> > (temporary) 2. BandAid the installation to stabilise it for the short
> > term (this is still more work than it sounds)
>
> So it seems we agree on these steps, and it's great (for planning Step
> 1) that you have access to information that is not available to me.
What info would you like access to?
>
> > 3. Stick Apache TrafficServer in front (not varnish) to improve response
> times / caching.
>
> I don't have enough knowledge on Apache TrafficServer to comment on this
> specific step.
Fairly new to me to, but we do have a whole projects worth of committers willing
to help :)
>
> > 4. Go with the choice of Option 5. that is, to allow the hosting and
> downloading of the templates
> > and extensions to be with the 3rd party authors.
>
> It's already allowed; it is just not enforced. I mean, it already happens that
> some extensions form the Extensions site are downloaded from external
> sites like SourceForge.
Ok even better.
>
> > the status quo can not continue, for benefit of all.
> > Help welcomed at any step of the way.
>
> Just make sure to get permission to transfer and modify the site code from
> Oracle, or clarify that such a permission is not needed. I can't have any
> active
> involvement with this until this issue is solved, even though I completely
> share your desire to bring the sites back to normal operations as soon as
> possible.
Ok sure, not sure we need any permission at this stage but who shall we ask
anyway,
Andrew?
(The site will continue to be served from the openoffice.org domain , which is
now
ASF owned. I assume you means custom code.)
Gav...
>
> Regards,
> Andrea.
