CI system maintainability

[Volker Krause]

On Friday, 29 March 2019 20:54:54 CET Ben Cooksley wrote:
> On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
> > I fear that a mandatory reviews would add too juch strain on smaller
> > teams. If there's just one person with an intimate knowledge of the
> > code-base, plus two co-developers, then who should do the reviews?
> > 
> > How about a distinction based on importance of a project instead? I.e.
> > mandatory reviews for frameworks and any app that wants to be included in
> > KDE apps releases. Non-mandatory reviews can then also come with a
> > "price" to pay: if CI errors are not dealt with in a timely manner, you
> > should be free to disable the CI for administrative reasons...
> While this does seem like a nice solution, unfortunately for many
> repositories it isn't a case of disabling CI coverage for it, but also
> CI coverage for everything that depends on it. In the case of
> KContacts, this would also impact on parts of Extragear and Calligra
> (who depending on their exact requirements would either lose a
> dependency being available, or lose all of their CI coverage).
> 
> This is why i've not pursued this as an option in the past, because
> it's not fair on other projects that don't have anything to do with
> another project aside from being a user of it's interfaces to lose
> their coverage, simply because the project they depend on is broken.

I agree that anything on the CI level would be merely a workaround for this at 
best. I'd rather suggest we address this at the source by turning the 
externally used modules into frameworks. We did that last year already for 
KHolidays and Syndication who were used by Plasma among others. KContacts, 
KCalCore and KMime should follow that next IMHO.

The next time window to do that relatively painlessly is coming up after the 
19.04 applications release I think, and all of those have been part of the 
KDE4-era kdepimlibs module that complied with KF5-like ABI guarantees, so the 
necessary work should be limited hopefully. Extra review of the public 
interfaces would certainly help with making this happen I think.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20190330/71a1d612/attachment.sig>