[TYPO3-core] Moving files to a docs-subdir / .htaccess for "security" / nginx-configuration

[Markus Klein]

Hi!

> 
> Xavier Perseguers schrieb am 05.05.2014 16:36:
> 
> >> So let's first decide if we want to include nginx example config
> >> setup and "where to draw the line" (Varnish? PHP.INI settings? ...?).
> >>
> >> If yes, and if we decide that "docs" would be a good location for
> >> that, just then we can also discuss about moving other existing other
> >> files there (INSTALL.md ...).
> >
> > I'd say that we should move everything to docs.typo3.org and link to
> > it in some README file shipped with the Core. This way we may go into
> > useful detail, show screenshots or syntax highlighted
> > code/configuration samples.
> >
> > I would prefer NOT to use wiki.typo3.org which I consider some good
> > place for gathering and preparing ideas but not ideal as an official
> > source of information.
> 
> I tend to agree here. I would also think we could remove the INSTALL.md
> from typo3_src as it has pretty much redundant information with the "Install
> Guide", and maybe also streamline README.md. We have a nice
> documentation site, and we should use it for this kind of documentation.
> You are right about the markup, screenshot and hyperlinking functionalities,
> which are helpful.
> 
> ChangeLog: is this useful for anyone? It just keeps growing. Wouldn't a link to
> some GIT URL showing the exact changes be enough?
Yes!
(I never needed the changelog)

> 
> GPL.txt: must have probably
Is it required to shop a copy of the complete GPL with the product? Maybe it suffices to link it in the licence.txt

> 
> INSTALL.md: move content to docs.typo3.org
+1

> 
> LICENSE.txt: must have?
Would say we should keep that one as it tells the user that GPL applies.

> 
> NEWS.md: move information to Release Notes (online). The information is
> very redundant, and not so complete as in the release notes. This file is
> *only* helpful for the release manager to later write the complete release
> notes out of it. It is incomplete and usually very badly structured for a regular
> user. If we remove this, we need to think about some other strategy of
> getting the information back into the release notes (maybe having some
> separate Category in the tracker just for collecting release notes issues).
Indeed a good point. I'd say a dedicated tracker for release notes related information would make sense.
Requirement would then be: create a ticket there and link it to the ticket of the change. I see no need to have this ticket in the commit message too.

> 
> README.md: is already very compact and elegant, I did some work on that
> for 6.2, so it renders nicely on github. Should be the central hub of pointing to
> the right resources if we externalize more of it to the Web.
+1

> 
> _.htaccess: the "sample .htaccess". I think it's useful to have it included
> because you can simply copy it over. And this is also the reason why some
> thought it would be useful to have the nginx example config available in the
> same manner, to be able to simply copy it over on the server, without having
> to "copy&paste" from some webpage. So this is - I think - still up to discussion
> on how to deal with this use-case.
+1 for having a demo-config for nginx too.

> 
> Cheers,
> Ernesto
> 

Cheers
Markus