CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-13 13:21, schrieb Eike Hein:
> Ok, here we go. My draft of a formal policy for dep changes and the CI:
> 
> https://community.kde.org/Policies/Dependency_Changes_and_CI
> 
> Compared to my earlier email, this draft contains some hard deadlines
> and an attempt to specify failure modes if the deadlines are not met.
> 
> Please chime in with suggestions for how the text needs to be refined
> and expanded to meet your and our needs. Updated versions of specific
> paragraphs are the preferred format for doing so: The thread so far
> has shown that free-form conversation is prone to mudslinging, so
> let's try to keep to the lingo fo a formal, dry document.

Thanks for stepping up to write this!

A few notes from my side:

* "Subscribing the sysadmin team to these code reviews is mandatory." - 
How? What are the team names one has to add as reviewers?

* This drastically changes the way KDE works. It requires mandatory code 
review and gives kind of veto power to sysadmins. It's something the 
larger KDE community might need to discuss as it removes one of the core 
principles of KDE that anybody can commit to anything and code review is 
only optional.

* Related to this: a month blocking on formal process is too long. If a 
maintainer doesn't respond in two weeks but another team member accepted 
the patch, it should also go in.

* I would like to see a link to where developers can check whether a 
dependency is available. Reasoning: I want to check whether it's a 
no-brainer to not have to add sysadmins if it's already available. E.g. 
if I add a new dep in KWin, which is already used by Krita I wouldn't 
know that and ask sysadmins. That would be a waste of sysadmin's time.

* I would like to add another exception: last minute dependency requests 
prior to a feature freeze should be allowed under certain conditions 
even if sysadmins had not two weeks to respond. Reasoning: shit happens 
;-)

Cheers
Martin