CI system maintainability
bcooksley at kde.org
Tue Apr 2 10:48:53 BST 2019
On Sat, Mar 30, 2019 at 10:46 PM Volker Krause <vkrause at kde.org> wrote:
> 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.
This would certainly help resolve many of the issues I think, because
then the build issues should be mostly contained to one specific
Product, which makes this much easier to work with in the long term.
More information about the kde-core-devel