[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: General Infrastructure Maintainability: API and EBN
From:       Olivier Churlaud <olivier () churlaud ! com>
Date:       2019-11-10 15:17:03
Message-ID: 1643820.lC5WhDUqc7 () olinux
[Download RAW message or body]

Hi,

Le dimanche 10 novembre 2019, 00:42:10 CET Philippe Cloutier a écrit :
> On 2019-11-09 13:40, Ben Cooksley wrote:
> > On Sun, Nov 10, 2019 at 4:28 AM Elvis Angelaccio
> > <elvis.angelaccio@kde.org> wrote:
> > > 
> > > 
> > > On 09/11/19 01:33, Ben Cooksley wrote:
> > > > Hi all,
> > > Hi Ben
> > Hi Elvis,
> > 
> > > > Over the past number of years one of the tasks the Sysadmin team has
> > > > worked on has been improving the overall maintainability of our
> > > > systems, with a significant number of specialised cronjobs, exceptions
> > > > and hidden linkages being eliminated.
> > > > 
> > > > That is with one great exception: api.kde.org and ebn.kde.org.
> > > > 
> > > > Both of these are suffering from an extreme amount of digital bitrot
> > > > and special casing and in general are now in a condition where I
> > > > cannot say for certain whether it would be possible to replicate the
> > > > setup on a new system without us experiencing some degree of breakage
> > > > (some of which we may not discover until weeks/months afterwards).
> > > > 
> > > > In addition, the current setup relies on an old-fashioned overnight
> > > > reprocessing of all repositories, which is inefficient and resource
> > > > expensive. A more modern approach would have the various projects api
> > > > documentation generated on a delayed cycle from relevant branches as
> > > > part of something like a CI job (but not part of the actual CI
> > > > workflow itself).
> > > > 
> > > > For this one, i'm not certain on the best path forward at this stage,
> > > > however the current state of affairs cannot continue. We have tried
> > > > over the past few years to find people to work on a replacement for
> > > > the tooling involved, but alas we've yet to have success here.
> > > > 
> > > > Thoughts anyone?
> > > I'd say api.kde.org is too important to let it go. The EBN is less
> > > important but still useful, I still see people pushing EBN-based fixes
> > > once in a while.
> > > 
> > > Have we ever tried to use a GSoC project to modernize either of them? If
> > > not, would it make sense to try next year?
> > > 
> > My only concern there would be whether the project is large enough in
> > scope to justify the amount of time commitment a GSoC project normally
> > spans.
> > From my understanding of the problem in question it quite probably
> > does not meet those requirements.
> 
> Do you have an evaluation of the time necessary (and for a student)?
> 
> I imagine there would be lots of work on api.kde.org possible if a 
> summer is too long for just that. Do we still have a list of api.kde.org 
> issues (it seems issues moved away from bugs.kde.org and I can no longer 
> find a list)?
> 

The issues from kapidox are on bugs.kde.org as the product "frameworks-kapidox". \
There are not so many reported bugs.

other parts of api.kde.org are not really tracked it seems.

Olivier

> 
> > 
> > > > Regards,
> > > > Ben
> > > Cheers,
> > > Elvis
> > > 
> > Cheers,
> > Ben
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]