CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 2017-01-14 21:14, schrieb Ben Cooksley:
> On Sat, Jan 14, 2017 at 5:23 AM, Martin Gräßlin <mgraesslin at kde.org> 
> wrote:
>> 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.
> 
> That's what this thread is -> no further comment required.

We had perhaps 10 devs participate in this thread. Yes, we do need a 
discussion
about that on the community mailing list.

Otherwise we run in the same problem as with the previous thread on this 
topic.
You just cannot expect every dev to follow such a discussion. Especially 
like
this one where non-Plasma devs might think that the whole thread does 
not affect
them.

> 
>> 
>> * 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.
> 
> For Linux at least, a search on the front page of build.kde.org for
> the phrase "create_" will show you the jobs which manufacture the
> Docker Images in which the builds are conducted.
> Maintaining a listing elsewhere is prone to being out of date.

Then please add this explanation to the wiki page.

> 
>> 
>> * 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 ;-)
> 
> Sorry, but a carve out like that is bound to leave us in the situation
> we're currently in, where the CI maintainers have to sort things out
> after the damage has been done.
> That's exactly what this policy is supposed to prevent.
> 
> I'm in total opposition to this exception request.

I'm sorry, but we need exceptions. Shit happens, sometimes not 
everything is working as flawless as we want. If the quality of our 
product is in danger, it doesn't matter anymore what policies are. The 
patches to fix it will be pushed. No matter whether the process was kept 
or not.

So let's better think ahead of the possible exceptions and clearly write 
down what would allow for an exception instead of then when it happens 
to have nasty discussion.

Cheers
Martin