Kube & Sink docs at api.kde.org/doc still wanted/needed?

[Friedrich W. H. Kossebau]

Am Freitag, 22. Mai 2020, 13:45:23 CEST schrieb Ingo Klöcker:
> On Freitag, 22. Mai 2020 12:23:20 CEST Friedrich W. H. Kossebau wrote:
> > Hi Christian,
> > 
> > doing some housekeeping on the server behind api.kde.org it was found to
> > surprise to some that the nightly script is spending cpu, i/o & storage
> > resources each day on generating some documentation for Kube & Sink, with
> > the result available on
> > 
> >     https://api.kde.org/doc/kube
> >     https://api.kde.org/doc/sink
> > 
> > At least for Kube the official documentaion as linked from
> > kube-project.com
> > seems to be on https://kube.readthedocs.io though, not api.kde.org/doc.
> > 
> > So is that documentation generated and made available on api.kde.org/doc
> > still wanted, or could we remove it already?
> 
> I think the documentation on api.kde.org needs to stay, as long as Kube is a
> KDE project. One of the commitments of a KDE project [1] is:
> ===
> * The project stays true to established practices common to similar KDE
> projects
> ===
> 
> As far as I know, one established practice among KDE projects is hosting of
> their API documentation on api.kde.org. This ensures that contributors to
> KDE projects don't need to look for the API documentation of different KDE
> projects in different places.

Thing is that those docs are not linked from anywhere else on api.kde.org (or 
outside from what I saw), so they are not found and currently just unused 
data, wasting resources and making the server system more complex and being 
yet another documentation system (mkdocs) which the new api.kde.org system 
would need to support.

And yes, I would think that things should be KDE services first. But I gave up 
to fight for that seeing many of the new incubated projects not really 
integrating and happily living a partial live outside of KDE services, so I 
just try to deal with reality instead of pretending things are what I/we would 
like them to be.
((actually I would rather unincubate such projects, growing KDE just for the 
sake of growing runs chance to kill it in the end due to lost common grounds. 
IMHO either projects completely get kdeborgified in a given time, or they 
should leave this world again. not my call though))
So I think we should just cut pseudo usages and use the freed resources to 
work on systems/services which are so attractive that people want to use them, 
instead of having to.

Cheers
Friedrich