CI Requirements - Lessons Not Learnt?
Friedrich W. H. Kossebau
kossebau at kde.org
Wed Jan 18 18:59:46 GMT 2017
first of all, thanks for turning this into a policy creation process :)
Am Donnerstag, 19. Januar 2017, 02:29:00 CET schrieb Eike Hein:
> On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
> > But CI has a really important function: it shows us the health of the
> > sources for everything; and that's something the release team needs, and
> > the whole community can be interested in. So "opting out" of CI deprives
> > us of a good view of the state of our software products.
> Agreed. But under the proposed document, you can essentially only
> opt out by behaving so badly that sysadmin sees no choice but to
> kick you out, and it labels that as "rude". I think it also
> communicates why we care about CI (e.g. as regression catcher).
> This thread has slowed down now - there's been no strong objections
> raised to the current version of the doc. If everyone is happy with
> it, I propose we start linking it from the /Policies/ main page by
> start of February and try to live with it.
Given this is a policy affecting all of the KDE projects, please first propose
it officially in a separate own thread, with a proper subject. Perhaps even on
kde-community, as kde-core-devel might not be read by many, given it used to
be focussed on kdelibs/core apps. Even people reading kde-core-devel might
have missed it, as this thread here started to become heated and long, so most
free time contributors might not have invested time into reading more than the
Some feedback on the policy itself:
"Dependency changes for software covered by the CI system should be submitted
through code review"
-> I would propose to additionally recommend contacting sysadmin as soon as
one knows that a new dependency is coming up, not only first at the time the
official review request is made. That should give sysadmin some more time in
advance to handle the needed new dependency in CI, and perhaps also give
feedback on issues.
Ideally it might even result in the new dependency already being available at
the time of the review request, so if the review itself is done quickly, CI
does not block the merge.
IIRC this would also reflect what has been done now and then :)
More information about the kde-core-devel