Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 01/19/2016 06:59 PM, Pavel Vinogradov wrote:
> I still prefer Stelth's site. Agree on new bugzilla stuff (not keeping old
> irrelevant bugs and new structure). Just my 2 cents.

That option is still valid and possible, just awaiting setup on distro
owned hardware. It's no big deal right now to drop the mediawiki in
favor of the other, but I have no access to his hardware, nor to the
content in the site (like I can't create an account or log in, at least
to the wiki stuff, unless I missed that in an email somewhere?) And so I
cannot get that software and content onto distro-owned hardware.

Stealth did import the original bugzilla history, so we'd have to work
through the bugzilla UI to clean all that up, which is probably doable.
I do like the layout of the site that stealth setup as well, its nice
and clean and the theme-ing is nice.

--
David Kowis

> 
> On Tue, Jan 19, 2016 at 06:40:45PM -0600, David Kowis wrote:
>>
>>
>> On 01/19/2016 02:23 AM, Thomas Orgis wrote:
>>> Hi,
>>>
>>> about that new cheaper server … that kind of hardware/setup is it? I was
>>> wondering why mediawiki.sourcemage.org is that darn slow. It's also
>>> around a second after the initial loading of content that the style
>>> sheet seems to be arriving and then the whole page changes. Stealth's
>>> site is so much more snappy:-/ Wikipedia itself also is faster and I
>>> don't see the late style arrival. What's the difference? Is
>>> mediawiki.sourcemage.org under some DoS attack?
>>
>> The hardware isn't bad, although I don't know the exact specifications.
>> I am running the pgsql, mediawiki, and bugzilla all on the same server.
>> We can probably get more ram for this VM if this is the way we want to
>> run it, or we can move the database server to a different VM. There's
>> some flexibility there.
>>
>> However, as I mentioned in the previous email, our PHP spell is out of
>> date, and does not include the useful caching stuff that would make
>> mediawiki perform substantially faster. I can also improve the
>> performance of the site further with memcached, but I haven't spent the
>> time to do that yet. It is not operating at peak efficiency, I chose to
>> get something done, and out there first, as a test run to see how well
>> it worked putting some content in there.
>>
>> It's extremely fast for anonymous users, as it actually keeps around the
>> fully rendered HTML, since theres no dynamic-ness at all. It's possible
>> you're noticing that with wikipedia (unless you're logged into wikipedia
>> all the time). Also wikipedia has spent the time to fully optimize
>> mediawiki. I will do these optimizations (would appreciate some help
>> with the php spell though). I think it probably wouldn't hurt to go all
>> the way to php 7 and get that working.
>>
>>>
>>> Note: I don't have JavaScript activated. Dunno if that catches the late
>>> arrival of the CSS. The site would still be slow to respond.
>>>
>>> Hm, the bug tracker also needs its time, but I have encountered other
>>> bugzillas that also are not that responsive. So it indeed could just be
>>> the very busy machine / uplink.
>>>
>>> As David already said that he'd be glad about any progress:
>>> Stealth: Are you alive?! Couldn't you find time to move things? How's
>>> the software behind the site? I remember you writing about spells you
>>> hacked for it.
>>
>>
>> Since there hasn't been any objection to my earlier proposal, I'm going
>> to start the wheels in motion to move to the things that I've set up on
>> the distro hardware, so at the least, we don't have a "Sorry it's broke"
>> page. With regards to bugzilla and importing bugs, I'm still not fully
>> convinced that ancient, unacted on, bugs are worth keeping around, but
>> we can import them. I do not wish to keep the same bugzilla structure as
>> before, as that doesn't make any sense to do at all with the type of
>> organization we are right now.
>>
>> We'll hopefully have the DNS records updated, I'll work on getting the
>> spells updated, at least to a php5 version that includes the right
>> caching, and then get a memcached on there to further improve both
>> bugzilla and mediawiki. (I think the php caching would lead to a huge
>> improvement right off the bat, but our php spell is too old.)
>>
>> --
>> David Kowis
>>
>>>
>>>
>>> Alrighty then,
>>>
>>> Thomas
>>>
>>>
>>>
>>> _______________________________________________
>>> SM-Discuss mailing list
>>> SM-Discuss AT lists.ibiblio.org
>>> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>>>
>>
> 
> 
> 
>> _______________________________________________
>> SM-Discuss mailing list
>> SM-Discuss AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 
> 
> 
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

Attachment: signature.asc
Description: OpenPGP digital signature