On Sun, Nov 27, 2016 at 3:54 AM, Christian Ridderström < christian.ridderst...@gmail.com> wrote:
> On 3 November 2016 at 00:46, Joel Kulesza <jkule...@gmail.com> wrote: > >> On Wed, Nov 2, 2016 at 7:25 AM, Jean-Marc Lasgouttes <lasgout...@lyx.org> >> wrote: >>> >>> If you are interested in updating this part of the wiki, we can give you >>> the necessary passwords :) Indeed everything is really out of date. The >>> graphical tour shows proudly LyX 1.3.0pre2! >> >> >> I might be interested... At the risk of raising the ire of >> traditionalists, as part of reworking some of the parts of the site that >> have aged less-than-gracefully, I'd be interested to learn more about the >> infrastructure behind LyX development and distribution to see if moving to >> more-centralized and/or remotely-hosted solutions make sense. >> > > FYI, both the lyx web site and the wiki site are run by the PmWiki wiki > engine. The content of both sites can actually be edited through a browser, > it's simply not as visible for the web site. > This is good information. The wiki would certainly need to be migrated in its current "wiki" form to that, or another, wiki engine to permit continued live editing by any personnel. Given the nature of the websites design (generally static, no elements requiring dynamic interaction / database querying) and the current state of markdown languages, I'd be somewhat inclined to migrate the web presence to inter-linked markdown files. The "README" file would then be the "main page". This will 1. tightly couple the web information/documentation with the rest of the project, 2. migrate the web information to git, 3. allow developer contributions to the web presence with equal level of permission/authentication that they have to the code (direct push, pull request, post patch, etc.). I've already tried reworking the current README to a markdown-compliant format and I think it looks better and is more serviceable (i.e., has links to other appropriate URLs and files). I think this approach is reasonable and reduced the barrier to keeping the website up to date and reliance on few select administrative personnel. It will also tag/track the website along with the various releases à la documentation. If this approach is disagreeable and a more traditional website is preferred, migrating the website to a standalone git repository seems like the preferred approach to me. Because the website is static, the HTML to control it will be rather basic and should require less wiki-customization during any future migration. The only apparent advantage to the current permission-based wiki format is ease of editing --- am I missing something? > Regarding "less-than-graceful" ageing, I'm actually surprised they still > work. And I'm happy people are still editing content on the wiki. I think > I started that work over ten years ago, so my memory is a bit vague on the > details of their configuration... > Indeed, the wiki is a nice resource which I've used and contributed to. As such, I'd like to see it live on. One attractive component to me of the Github/Gitlab services is that they have wiki engines built into projects. Thus, this is something else I'd like to investigate feasibility of migrating: existing wiki to Gitlab wiki (following migration testing for existing Trac to Gitlab issues). However, if I remember correctly, at the time both the wiki and web site > where in SVN. Right now it seems only the web site files have a > .svn/-folder. > > But these days we use git, so I don't even know if there's something > corresponding to the www-user repo in git. > See point above regarding how to migrate the website to git. > At the time it was possible to checkout the web on a different host, or at > a different location, and test it there. So when I did bigger configuration > changes, I deployed and tested locally before putting in production at > lyx.org. > This is my common practice as well. If I'm working directly on a server, I work in a ./stg (staging) subdirectory that is live but unknown (this way I can see how it performs on the actual hardware). Once migration is approved to involved parties, the live site goes to ./bak (backup) and ./stg goes to ./. In this way, the old setup is preserved for some length of time in case there are issues. In this migration, because it would (ideally) be moving to a hosted service, the hosted service site will be built up with content (which is all slowly changing except the codebase itself). Then, when the hosted service is set up and ready for migration, pointers will be made from the current URLs to it with the old site held as "backup" on the server in Bonn. This will allow a revert if there are any issues. > Do you have the login passwords? > I do not. I think there may still be some internal discussion amongst the developer-admins about what, if any, level of access to grant me to the various components of the web infrastructure. > Thanks, Joel
