search

awesomeWM / awesome-www

Website of AwesomeWM
https://awesomewm.org/
56 stars 34 forks source link

Need to find a new hosting service #7

Closed jd closed 7 years ago

jd commented 8 years ago

I'm slowly but surely closing hosting services that host the current awesome website. That'd mean moving out the static website, and the Mediawiki instance running.

There's no hard deadline yet, the soft deadline being 31st December 2016.

psychon commented 8 years ago

So... for the web page, github pages, just as we already use for the API docs of git/master? What would happen with the domain?

I don't have a good idea for the wiki. I don't think GitHub wikis are a good replacement (and not just for the vendor lock-in reason). A similar bad idea would be Wikia. What other options are there?

Options for the wiki:

Do we want to keep the wiki multi-language? I'm not sure how up-to-date the translations really are. Only the ru-translation seems to be semi-up-to-date. If we want to keep this:

After looking at the current wiki a bit, I came up with another version:

Edit: To-Do list:

jd commented 8 years ago

It seems to me you can map a domain to a Github pages instance. I don't have any good suggestion for the wiki yet.

psychon commented 8 years ago

(We could also use ikiwiki)

Oh, I have to remember to save a "backup" of the old issue tracker!

psychon commented 8 years ago

CC @blueyed @Elv13 Any ideas?

psychon commented 8 years ago

I'm CC'ing random people. @actionless What do you think?

actionless commented 8 years ago

I like the idea

A static ikiwiki instance. Editing the wiki would be done via pull requests to some awesome-wiki repo and perhaps we can setup some travis-magic to auto-build the wiki (hm, perhaps we should have similar magic for the awesome-www-repo?). That's one of the less nice ways to use ikiwiki, but it would at least work.

and deploy it to github pages.

but actually, if contributors will have to do PRs in order to edit the wiki anyway, mb it could make sense to have wiki inside apidocs, like this: http://awesomewm.github.io/apidoc/documentation/03-declarative-layout.md.html

Elv13 commented 8 years ago

I kind of like @actionless idea. Maybe we could use a middleground here. The GitHub wiki are not very good, but there is no vendor lock-in. They are available as git repositories. Instead of PR, we could just fetch the wiki git repo when building the doc and integrate it into the main documentation. We could then build the website around that (all/most links in the mainpage end up either on github git API doc)

blueyed commented 8 years ago

I like the ikiwiki idea (but have not used it myself much). I can imagine making it harder for contributors then to get changes into the wiki though?! OTOH that would eliminate the spam issue.. :)

jd commented 8 years ago

There's a lot of content in Mediawiki and I don't know if/how it can be migrated. Just sayin', think twice before picking a different solution. :)

Elv13 commented 8 years ago

75% of the content is outdated and doesn't work anymore. I think 3.4 is still the most used API (unless someone cleaned things recently)

While an HTML dump in a git repository could be useful for legacy versions users, I think cherry-picking the relevant content by hand wont be that bad. There is not that much to salvage.

psychon commented 8 years ago

@Elv13 Oh nice, I didn't know that (and Google confirms this: http://stackoverflow.com/questions/18759738/effortless-export-from-github-wiki ). That might even make a GitHub wiki a viable option (updated my answer above). And it supports anonymous edits! (however, no idea about the spam-issue)

My migration plan from Mediawiki to $SOMETHING_ELSE would be to add a pick note at the top that we are migrating to something else and looking for help with the useful content (Mediawiki can do that, I forgot how). Then we can see if anyone actually helps. And yeah, I agree that losing most of the wiki's content wouldn't be bad.

For legacy reasons, we could get a HTML dump of the old bug database and the wiki and put it in some awesome-legacy-www repo's gh-pages branch.

Edit: Random wiki which GitHub somewhere recommends as nice/good: https://github.com/mbostock/d3/wiki

Elv13 commented 8 years ago

Also note that markdown support inline HTML, so we can actually copy paste while pages and drop the table of content, then be "done". It will be fugly and uneditable, but it would show. That's a start.

Then again, there is like 15 relevant widgets pages, 10 "how to integrate awesome with software_name", the FAQ and the external module list.

actionless commented 8 years ago

i am agree with the point what the current wiki have lots of out-of-date info so that manual moving of only those articles which are actual should refresh the wiki a lot

psychon commented 8 years ago

I left a note at https://awesomewm.org/wiki/MediaWiki:Sitenotice directing people here. Perhaps this will get us some input with some nice ideas on where to switch to. Feel free to tell me that the notice is worded badly. :-)

cobra2 commented 8 years ago

I just saw the notice. I'd think a dokuwiki, with the mediawiki syntax plugin, readonly install under nginx managed by git. Linode is my prefered host and I'm biased towards them.

This works very well for my local wiki.

actionless commented 8 years ago

Linode

but it's a payed service while github pages are not

elemental7 commented 8 years ago

I'm new to awesome, and I have been looking at various things on the wiki to help get me started. I have found the information to be very enjoyable and educational, so I would just like to say that this aspect (new user friendliness/accessibility) should be kept in mind for whatever the replacement might be. Us noobs need this kind of resource, readily available to non-experts, to help us out. Thanks for all the efforts on awesome!

Elv13 commented 8 years ago

@elemental7 Of course, we want to improve on this, not make it worst. What I and @actionless propose is to create a single place where you can get curated information. For now, there is the API doc (terrible in 3.5, hopefully great in 3.6), the Wiki (most content is outdated and doesn't work with Awesome major versions released during this decade) and some other places like stackoverflow and reddit.

My vision for the API doc is to integrate relevant articles directly into the interface. One of the first example would be this one: http://awesomewm.github.io/apidoc/documentation/03-declarative-layout.md.html and those (hopefully coming soon) https://github.com/awesomeWM/awesome/files/185708/wibox_widget_background.pdf https://github.com/awesomeWM/awesome/files/185709/awful_placement.pdf https://github.com/awesomeWM/awesome/files/189197/tile.pdf

They have the advantages of being hooked into our continuous integration and testing framework, so the examples and content (images, code, arguments names and type) are validated by a robot. This should solve the outdated examples issues we have in the wiki.

By replacing MediaWiki by a git+markdown based wiki solution, we should be able to streamline our processes into a single pipeline and generate an unified docbook.

I think most people here suggested solutions that could make this work. The big question is if we wish to have pull request for all edits. I did not use the GitHub wiki extensively, but I guess it is possible to require accounts for edits and lock some pages to user groups. This seem like enough for me. The only exceptions would be the code examples. I would still like those to have peer-review before being posted to: avoid running random code on our build system, avoid broken code and deter anti-patterns such as blocking wget/curl calls using io.popen().

psychon commented 8 years ago

I don't think a GitHub wiki will work out. Google suggests that spammers also attack these, so we might eventually have to lock down the GitHub wiki to only a "trusted list of editors". Meh. On Dokuwiki: That's based on PHP. It would be nice to have some static HTML to be more hosting agnostic (and since it looks like we will use gh-pages as hosting).

Edit: Random web page that I found and that uses ikiwiki: http://dnstap.info/

uoltah commented 8 years ago

There is also https://readthedocs.org/, widely used by many OS communities. Compared to Github wiki, it gives some more freedom, but still not as much as a static solution like ikiwiki. Anyway, I like it since you can browse the docs by version. Just giving my two cents. :)

actionless commented 8 years ago

@SirJoose

it gives some more freedom

could you elaborate more on that?

i like versioning thing already

aajjbb commented 8 years ago

Overall, I found @actionless idea to keep the wiki somehow inside apidocs to be a great one.

Elv13 commented 8 years ago

If we don't use the GitHub Wiki, then I also cast my vote for @actionless idea.

alexander-yakushev commented 8 years ago

+1 for Github wiki, -1 for some static solution that requires going through pull requests to edit. The extra hassle would absolutely prevent a lot of useful contributions.

@psychon Github wiki doesn't allow anonymous changes, it requires users to be signed up and logged into Github. I'd argue that Github's account creation system is better than MediaWiki's, so that slightly solves the bot problem. Anyway, it seems that only some really high-profile repositories suffer wiki spam, so we might as well dodge the bullet.

psychon commented 8 years ago

Some more static web site generators (I randomly came across this): https://gohugo.io/ http://jekyllrb.com/ https://middlemanapp.com/ http://nanoc.ws/

@alexander-yakushev Sorry, but I don't see that many useful contributions in the current wiki either. The list of user contributed themes might be nice, but just count the number of them that lead to 404s or only work in awesome 3.2 or .... As for GitHub wiki spam, the google results say that it does happen and you have zero options against it when it happens. I had enough "fun" with MediaWiki spam that this scares me.

psychon commented 8 years ago

Vote this post up/down for GitHub wiki.

psychon commented 8 years ago

Vote this post up/down for some static web site solution.

virtualtam commented 8 years ago

Hi all! I'm a new awesome user, currently spending a fair amount of time in the current wiki ;-)

I don't think GitHub wikis are a good replacement (and not just for the vendor lock-in reason).

As a software developer/maintainer, I think GH wikis come with several (major) limitations:

There is also https://readthedocs.org/, widely used by many OS communities.

ReadTheDocs (RTFD) mostly consists of the hosting & Git hook parts, as the underlying documentation engine is Sphinx, using an extended set of the reStructuredText (reST) markup format.

Here's what I like about the RTFD / Sphinx / reST combination:

Versioning the documentation along the software also eases tracking changes and keeping the pages up-to-date, plus you can set Continuous Integration builds to check the syntax of incoming Pull Requests (example) :)

Elv13 commented 8 years ago

Edit: upvote this post for using an ldoc based wiki

I vote for ldoc (a static generator already used for documentation with wiki/markdown support and macro support from cmake). It has a few advantages:

[1] I had some issues with their discount extension support, table never show up, it is probably a bug

actionless commented 8 years ago

Vote this post up/down for some static web site solution.

is this implying ldoc usage?

Elv13 commented 8 years ago

is this implying ldoc usage?

It is technically a static wiki solution, so technically yes, but I changed my post to use it for ldoc votes. I guess the wiki solution would be in round 2, but I really agree with you ldoc can do just fine and give a much, much better integration and coherency.

psychon commented 8 years ago

Oh yeah, ldoc. I kind-of-forget-and-just-assumed-so about it. Things like "my first awesome" should go there. However, something like e.g. Shifty doesn't fit into the docs-shipped-with-awesome. So I guess my position is:

Elv13 commented 8 years ago

We can add an extra repository as a submodule travis wont even notice (after the 2 CMakeLists.txt line that need to be edited and the --recursive).

That way, all awesome related pages are shipped with Awesome and all others are only in the API doc website.

psychon commented 8 years ago

Hm, I actually like that idea...

avaika commented 8 years ago

I'd be more than happy to provide a hosting you. I can create a separate virtual machine with privileged access for you.

I understand that it might be not really comfortable to trust a random guy from the internet, but at least you are free to try it. I have a couple of own servers during the last 5 years with some free resources I'm able to share a bit.

psychon commented 8 years ago

So... it looks like "some static solution" won. We still have "ldoc", "ReadTheDocs" and "the ikiwiki behind awesome-www" left as candidates.

Now for something else: Which content from the wiki should be saved? What's the useful part of it?

psychon commented 8 years ago

I set up the following two new repos:

The backup is a wget --mirror of the current state of things and wget is still running. The second repo is my plan for the future of the web page. It still has many broken links and I want to integrate this with travis to auto-update the page on changes in the awesome-www repo.

I hope this is ok with everyone.

bew commented 8 years ago

Great news!

ghost commented 8 years ago

Might be helpful.

https://github.com/webplatform/mediawiki-conversion

blueyed commented 8 years ago

I've setup CloudFlare for awesomewm.org, which is required to serve awesomeWM.github.io through SSL.

What is supposed to happen with http://awesome.naquadah.org/wiki/? Is it supposed to go away? Currently it redirects to https://awesomewm.org/wiki/Vicious, where it is not available with the new site? I've reverted serving awesomeWM.github.io on the awesomewm.org domain for now.

psychon commented 8 years ago

I think Elv13's plan with the wiki is "move to ldoc". However, explaining something like Vicious in the docs that come shipped with awesome feels weird since it makes Vicious kind-of-official and it means that users get the wiki from long ago. Dunno where a separate repo for "wiki ldoc" could live and I'm unsure how much of a good idea it is to write a wiki in an API documentation tool. My suggestions would be to move that into the ikiwiki webpage since we already have that anyway for the "not wiki" part of the website.

martingabelmann commented 8 years ago

independent of the underlying software i also think there might be two different solutions to distinguish between (kind of) "official" docs and "community shares".

The second one could have wiki character containing all the useful tiny code snippets, widgets, themes etc... while the official is something like luadoc which is edited by pull requests only.

Then, there should be a workflow/framework between the two repositories that merges very popular/confident content from the community repo to the official docs and ensures that there is not too much redundance between them. Also cross references should be handeled by this (to get sure to not have broken links).

Maybe i`d join the discussion to late but i also want to throw in my two bits to the "outdated" content: Even if some of the old articles are outdated they still can be useful (at least for me) e.g. to just get the idea. I like the idea to have an "archive" of the wiki which is just a html dump of everything. It might be stimulating others to renew/improve contents from there and put them again to the new docs. This would also make the question "which articles should be abdopted?" obsolete, because its up to the community... (of course the very important/obvious articles, that would directly come into ldoc can be adopted before).
One should include a header on each page (like the actual one), with additional information (that the content might be outdated and where to find the new docs).

gutierri commented 8 years ago

I tried to use the dump tool (https://github.com/WikiTeam/wikiteam), but could not because he has a "request limit"(on server wiki awesome) then generates an error 500. Then extracts the list of all pages and made an export (https://awesomewm.org/wiki/Special:Export) XML then converted(with https://github.com/philipashlock/mediawiki-to-markdown) to markdown.

I put these things here => https://github.com/gutierri/awesomewm-wiki-dump

But it seems to be pretty messy, I do not know how we can arrange it for use in a static generator.

We could go moving the content gradually, thus clearing which is no longer valid and organizing information. I do not know the best way, because of a lot of work manually, there is over 500 pages.

jd commented 8 years ago

I can provide a PostgreSQL database dump if ever needed.

psychon commented 8 years ago

@jd A dump of the state right before the web page is shut down would be nice, but it could contain private data (mail addresses, password hashes, ...). I don't know what to do about that.

gutierri commented 8 years ago

@jd wikimedia has a few tricks to dump only pages (at least I think). It would be nice to have a dump it.

But before we start to work we need to define where we will put the new wiki? It seems that many people vote in some static technology.

My proposal for this is the sphinx, for a few reasons:

And with travis-CI you can automate deploys

Incognito4nonymous commented 8 years ago

I do not recommend wikia as an option, I won't expain this since it is already well done here : http://awa.shoutwiki.com/wiki/Anti-Wikia_Alliance

smonff commented 8 years ago

Why keeping a Mediawiki instance don't seem to be considered as an option?

pierreozoux commented 8 years ago

Hey, I can offer MediaWiki hosting if necessary (and whatever hosting the community would need). Just let me know. (For your information, I run the following service: https://indiehosters.net )

fjfalcon commented 7 years ago

If you need hosting service i can purchase hetzner hosting for you and pay for it.