Docs.krita.org has been switched to sphinx!

[Wolthera]

>On Sun, May 27, 2018 at 8:40 PM, Raghavendra Kamath <raghu at raghukamath.com> wrote:
>I think we can have a section in the download page on the website. Also we can have a URL inside the manual to download the epub.

Here's the tricky bit, we will have epubs per language. Should the
downloads page then have a dropdown of sorts?

On Sun, May 27, 2018 at 8:48 PM, Raghavendra Kamath
<raghu at raghukamath.com> wrote:
> May 27 2018 8:13 PM, "Wolthera" <griffinvalley at gmail.com> wrote:
>
>> I was more wondering about things like, first we deprecate a page and
>> then we remove it.
>
> If our manual release is in co-ordination with our release, then I think we can have a sub-section at the end of manual with all the deprecated pages, just in case the user wants to see how it was done in previous version. In the next release we can remove it and keep anything which is deprecated in that release. Just like how we had unstable section.

So a deprecated section. That'd be a page with a glob table of
contents pointed at a 'deprecated' folder. However, say we deprecate
the fill tool for whatever reason. It is currently at
https://docs.krita.org/en/reference_manual/tools/fill.html, if we move
it to a deprecated section it'd become
https://docs.krita.org/en/deprecated/fill.html, meaning the link would
break. Might it then be better to have a page with reference links
towards the deprecated pages and that we don't move them physically in
the manual until we remove the page?

>
>
>> But if we do that, what kind of rules should we create for when a page
>> really needs to go?
>
> If a new feature is in current release the new page explaining that feature should be in the manual released with that Krita release and feature which is not there should be in deprecated section.
>
> Also I think at the start of the manual we can have a new in this release section, what do you say?
>
>
> -
> Raghukamath

We could make a changelog section starting with 4.1, I would however
like some help with keeping that up to date though(and not just from
scott), previous attempts became out of date quite quickly, partially
because there were too many rules all of the sudden with screenshots
and the like. At the very least I would like boud and dmitry(and
whoever else pushes a lot of code) to harden the krita commit messages
rules so that commits that don't consist of whitespace fixes and
random cmake manhandling can be easily discerned.

Speaking of which, should we have other kinds of 'meta' pages, such as
license, contact info or list of contributors also added somewhere?
(The latter will require a script, but is possible).

-- 
Wolthera