On Thu, Jan 5, 2012 at 9:38 PM, M.-A. Lemburg <m...@egenix.com> wrote:
> > > > 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. I don't want a login, but it seems like I should have one to access this info. I'd prefer to have WIKI_VIEW permission for anonymous that I'll automatically inherit without dedicated login. >> 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. > Is the configuration process really that complicated? What is the DNS server software? Is it in Python? > 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. > This information was open. Why it has gone closed all of the sudden? http://wiki.python.org/moin/Admin?highlight=%28CategoryPythonWebsite%29 What's the benefit of switching Trac 0.11.2.1? It doesn't support Bazaar as a repository backend out of the box, so the source browser is likely useless. For reference to MoinMoin wiki from security sensitive Trac tickets, there is always an InterWiki. >> 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. It's cool and very interesting. Why not to make the process open and cover the progress on Planet Python, and in PSF blog? Will this infrastructure include OpenStack? How much Python will be involved? What are monitoring tools? I want to participate in public discussions too. > >> 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" ? > The number of people on a project that should be hit by a bus to ruin it. Bus factor 1 means that there is a single person (with valuable know-how) without which the business will be unable to operate. The point is - the resistance to make the configuration change is caused by potential inability of current maintainer to support new setup. Thus reducing "bus factor" to 0. So, the question about "current bus factor" is really the question about how many people besides you are maintaining the setup currently, and whom to can you delegate MoinMoin maintenance tasks without dropping bus factor below some reasonable value (to say 2) by opting yourself out? > 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. > Can you estimate the "added value" and "added maintenance" in quantitative terms? I already understand that added value is 0 for you personally, but what is your estimation of a community service value? There is already at least +1 from active wiki community who is subscribed to this list, and I suspect the actual percentage is higher than 20% (and maybe even higher than 50%, but to prove that we should run a poll with MoinMoin accounts for a month). So, if the chance of doing the change is "added value/added maintenance", we may either try to increase the subjective cost of "added value" (which I am trying to do right now) or reduce "added maintenance" (which I will likely do once I get access to current config files). Or it might be possible to find somebody with higher default ratio, but we need to be sure that we won't reduce "bus factor" by ignoring maintainers, who don't care instead of persuading them. So this stuff can only be used as a last resort, but I think it is unnecessary. What's the point of being maintainer for a stuff that suxx if you're not paid for that? I've just come up with the idea that it might be the reason for motivation to keep the maintenance process closed. People don't want to hurt their reputation, because their discussions are not professional from the point of view of a seasoned admins. But that's just wrong - if you're a volunteer it is only natural to ask dumb questions, raise the problems, try to solve them and everybody should understand that. In the end - person who is trying to learn something new and improve the things will likely provide more "added value" for community than a conservative volunteer, who does a honorary and hard job (thus excluding other people from the process). Technologies move and without public discussions the interest from community will degenerate, as well as maintainer's motivation to move to these new technologies (even if newtech brings improvements to simplify the process). > 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. > I focus on Python and Jython wiki, because they are public. It would be nice if you could have a public page with description of other wikies. If I remember correctly there was some closed PSF wiki, but it must be replaced by Trac you've mentioned. And what should I take into account is not clear until I take a look at actual configs. > 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 ?! This really looks like a way to go, but without actual config files it will be hard to get this sandbox right as I am not a MoinMoin expert either. In fact - I trust Radomir's experience more than my own and would ask his opinion in this respect. P.S. We already have http://wiki.python.org/moin/TrackerDevelopment page - is there anything similar for Wiki? -- anatoly t.
_______________________________________________ pydotorg-www mailing list pydotorg-www@python.org http://mail.python.org/mailman/listinfo/pydotorg-www
