[pydotorg-www] Removing /moin/ suffix from wiki.python.org (Was: Internal Server Error while reverting spam)

[M.-A. Lemburg]

anatoly techtonik wrote:
> On Thu, Jan 5, 2012 at 2:11 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> anatoly techtonik wrote:
>>> On Wed, Dec 28, 2011 at 6:38 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>>> anatoly techtonik wrote:
>>>>> 7 days have passed since last message, so I presume there are no
>>>>> more objections to do
>>>>> required configuration changes.  Of course, it will be more obvious if
>>>>> people could directly
>>>>> say they are o.k. with it.  Should we leave this open for another 7
>> days?
>>>>
>>>> I'm still -1 on the change. It only helps people typing the URL and you
>>>> can get the same effect of saving those 5 letters by having
>>>> wiki.python.org
>>>> redirect such URLs to the /moin/ instance, without any complicated URL
>>>> redirection setup. Browsers don't really care whether the URL is long
>>>> or short and neither do mice :-)
>>>
>>>
>>> I find these -1 reasons are funny. =) I can repeat the counter-arguments
>>> that shorter URLs are better not only in address bars, but also for
>> posting
>>> links and navigating search results, but the point is:
>>>
>>> - this configuration change is a one-time, standard, common, not-a-hack
>>> solution for a traditional problem, that MoinMoin is designed to resolve,
>>> and it is a small price of admin's time to make a small group of people,
>>> who also care about Python wiki feel a little bit more happy
>>
>> I do care about the Python wikis being both an admin and user of
>> them, and I feel that the maintenance and documentation overhead
>> of your solution doesn't warrant the change.
>>
> 
> Is the current setup documented anywhere at all?
> If you point to the document, we can remove the burden of providing
> necessary instructions from you and stop talking about "overhead" in
> abstract terms by providing real diff of the changes.

The PSF systems documentation is here:

https://psf.projecthut.com/trac/psfsystems/wiki

It's far from complete, but all we have at the moment.
If you want a login, let me know.

>> Common - you don't really think that the proposed redirection setup is
>>> complicated, do you? =) If some questions are left unanswered or the
>>> answers are vague - just repeat them, so we can clarify and remove the
>>> confusion.
>>
>> If you can show that adding new wikis to this setup is easy and
>> doesn't require setting up new domains, I'll change my mind.
>>
> 
> If the real problem is in setting up new domains then we can discuss it in
> this thread or in different - as you wish. Don't you use DynDNS or
> alternative ?

No. The python.org domain DNS records are controlled by the sysadmins.

> As for showing you new setup and how to add new domains there, we need at
> least least old config available from somewhere. Do you have a link to
> repository?

See the above wiki for details. Config files are kept in a bzr
repo.

>> The way I read your proposal, it only works if you put the
>> wiki instances each under their own sub domain (with all the
>> admin and maintenance overhead that goes with it).
>>
> 
> It is hard for me to estimate the overhead you are speaking about. It will
> be more productive to start with actual config files and description of the
> current setup. If it is Apache that is hard to maintain, we can switch to
> Nginx. If the overall config is too complicated there is Puppet and plenty
> of other admin helpers. Just describe this overhead problem.

If you want to change the overall setup, please get in touch with the
infrastructure team which is currently evaluating and planning to
move the python.org systems to a whole new infrastructure.

>> If you're after better navigation, it may make more sense,
>> changing the prefix from /moin/ to /python/, so that the
>> URLs read:
>>
>> http://wiki.python.org/python/
>> http://wiki.python.org/jython/
>> http://wiki.python.org/psf/
>
> BTW, that is the current bus factor for wiki.python.org ?  If it is so hard
> to maintain, maybe you just need more people to help?

What is a "bus factor" ?

I'm not saying that the current setup is hard to maintain. I'm saying
that your proposal appears not to provide a good ratio between added
maintenance and added value.

You're only focusing on the Python wiki instance, but we have and will
have more than just one instance running on the server, so those will
need to be taken into account as well.

Perhaps there is a way to trick farmconfig into falling back to
the Python wiki in case none of the other instance URL REs match.
This may be possible according to the documentation in the standard
farmconfig.py file using a setup like this (moin appears to try the
REs top to bottom and takes the first match):

wikis = [
    ('jython', r'^.*/jython/.*$'),
    ('psf', r'^.*/psf/.*$'),
    ('pycon', r'^.*/pycon/.*$'),
    ('python', r'^.*$'),
]

Perhaps you could give this a try in a sandbox installation ?!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 05 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/