General Infrastructure Maintainability: API and EBN

[Ben Cooksley]

On Sun, Nov 10, 2019 at 4:28 AM Elvis Angelaccio
<elvis.angelaccio at 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.

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

Cheers,
Ben