Some of what ebn is doing in terms of linting c/c++ code would be better moved to clazy/clang-tidy plugins. The current scan for functions such open false positives for strings and comments. This is just open example of the limits imposed by not having a compilers eye view of the code. I personally don't care for having an extra place to check for errors. Clazy can run automatically on each build so warnings show up in your ide not just on some website.
On Sat, Nov 9, 2019, 10:28 AM Elvis Angelaccio <elvis.angelac...@kde.org> wrote: > > > On 09/11/19 01:33, Ben Cooksley wrote: > > Hi all, > > Hi Ben > > > > > 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? > > > > > Regards, > > Ben > > Cheers, > Elvis > >