<div dir="ltr">This discussion seems to have gone off track.<div><br></div><div>I pointed out three things that I thought should be addressed to ease the use of contributing to the <a href="http://dlang.org" target="_blank">dlang.org</a> site (and other D-project components), and those three things were: a) lower response latency on pull requests, b) better documentation of the component "plumbings", specifically how to build the <a href="http://dlang.org" target="_blank">dlang.org</a> website and c) README files in all the D-project repos with answers to common questions outside developers might have, like "where do I report bugs?".</div>
<div><br></div><div>The discussion here goes on to debate the pros and cons of ddoc which is <i>explicitly</i> something I mentioned as "not worth fighting over". Yes, IMO it's an unfortunate choice of a markup language because to outsiders it's esoteric and unlike most other markup languages and there are far better options out there (Markdown or reStructuredText). For a project that's still looking for contributors it's just another roadblock to adoption. It's what they call an "unforced error" in tennis; something that makes it harder to succeed for no benefit or reason, and not doing it (or doing it differently) helps you get to where you want to go faster.</div>
<div><br></div><div>But again, this is beating a dead horse. This mailing list has seen plenty of discussions on the topic and the powers that be haven't been convinced to move away from ddoc so I don't think it's going to be fruitful to debate this further. Let's be practical and let it be and move onto other, more important problems. Nobody has ever said "Oh that D language is great but ddoc is so bad I've decided to use Java". That just doesn't happen. It's not that important.</div>
<div><br></div><div>Ddoc was irrelevant to the changes I wanted to make to the site anyway. The more important problems I listed were the ones preventing me from making them.<br></div><div><br></div><div>Other points:</div>
<div><br></div><div>1. Having the website inside git on github was a great idea. Walter made all the right arguments explaining why.</div><div><br></div><div>2. Makefiles are fine, but there needs to be a README saying "hey go run that posix.mak file" because there's no "Makefile" file in the site repo. And then the makefile has assumptions about its environment which are not documented anywhere. It's not obvious what needs to be done.</div>
<div><br></div><div>3. Ruby on Rails (or Django or any other web framework that dynamically builds a server response) would be a terrible choice for a static website. It would be nothing but overhead for no benefit. Nothing on <a href="http://dlang.org" target="_blank">dlang.org</a> is dynamically generated, nothing talks to a database (nor should it). The site can and should be generated from some simple markup language. The end result should be HTML, CSS, JS and image files that are then just served by the simplest of servers. For these types of sites, the industry standard is quickly becoming to serve the files directly out of Amazon S3 with a CDN (like CloudFlare) in front of it. The end result is an incredibly fast browsing experience because everything is just served directly out of the CDN edge servers without any kind of dynamic response generation. Requests come in for files and the CDN just echoes them out of memory to the network.</div>
<div><br></div><div>Of course, <a href="http://forum.dlang.org" target="_blank">forum.dlang.org</a> would be different, but (internally) that's a different site entirely.</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Jul 14, 2013 at 1:35 PM, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 7/14/2013 6:49 AM, Dicebot wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But maintaining<br>
whole stuff via git repo + makefiles is definitely cumbersome, no idea why that<br>
was chosen.<br>
</blockquote>
<br></div>
1. github is how the entire rest of D is maintained, it would be strange if the website was handled via some completely different system.<br>
<br>
2. github is of proven utility in enabling anyone to contribute to the web site via pull requests.<br>
<br>
3. github/makefiles are how everything else in dlang is done, so contributors should already be familiar with the process.<br>
<br>
<br>
As for using Ddoc,<br>
<br>
1. It relies on D being installed. Presumably, anyone interested in developing the D website already has D installed. No other tools are necessary.<br>
<br>
2. Ye Olde Dogfooding argument. Experience with the web site has driven some good improvements to Ddoc.<br>
<br>
3. HTML, PDF, Ebook, and CHM outputs are generated from Ddoc.<br>
<br>
4. Website can be built on any platform that supports D.<br>
<br>
</blockquote></div><br></div></div>