CI Requirements - Lessons Not Learnt?

[Friedrich W. H. Kossebau]

Hi Eike,

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 
first.

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 :)

Cheers
Friedrich