Plasma Team Communication & Development Practices [MUST READ]

[Ben Cooksley]

On Sun, Oct 8, 2017 at 9:00 PM, Martin Flöser <mgraesslin at kde.org> wrote:
> Am 2017-10-07 22:00, schrieb Ben Cooksley:
>>
>> On Sat, Oct 7, 2017 at 11:57 PM, Martin Flöser <mgraesslin at kde.org> wrote:
>>>
>>> Am 2017-10-07 11:22, schrieb Ben Cooksley:
>>>>
>>>>
>>>> *Pulls up a chair*
>>>>
>>>> We need to have a talk. The way things are proceeding currently in
>>>> regards to how you (the Plasma folks) work with the rest of us is
>>>> severely and fundamentally broken. Which means we need to fix it.
>>>>
>>>> Lets start with development practices. Over the past few weeks, there
>>>> have been at least two instances where things have been unbuildable,
>>>> for several days, and have only been fixed after i've essentially
>>>> hunted down the responsible developers. One instance is currently
>>>> outstanding.
>>>>
>>>> In one case code was introduced which depended on a new version than
>>>> was allowed. The other case was a failure to update the dependency
>>>> metadata.
>>>
>>>
>>>
>>> Having had to do it a few times, I do not think there is currently a
>>> workflow in place where one can follow it. It's not documented and if one
>>> actively asks for "what's on the CI system" one gets a reply like "it
>>> depends" up to "look through the jobs". Having done this a few times I
>>> don't
>>> think you can expect developers to get this right.
>>
>>
>> In this case I was commenting on a straight up Qt issue - where code
>> was added which used features that weren't available in Qt 5.7 (the
>> current target for Frameworks)
>>
>>>
>>> If I would have to do it right now, I would not:
>>>  * know where to find the documentation
>>>  * know where to check which dependencies are available
>>>
>>> So let's try to google: "kde developer update dependency", hmm nothing on
>>> first side, sorry.
>>>
>>> And I'm probably the one developer being most aware of it due to the mess
>>> with xkbcommon.
>>>
>>>>
>>>> Some might say these issues are minor. Apart from the fact they're in
>>>> Frameworks which means they have repercussions on everyone else who
>>>> develops software using KDE Technology. The fact they've also been
>>>> ignored for *days* is also not great either.
>>>>
>>>> Now on to communication. As above I mentioned developers were
>>>> ignoring, or otherwise failing to take action on, notices that these
>>>> breakages were present in the above. Not cool!!
>>>
>>>
>>>
>>> I hear of these issue for the first time. So where were the alarm clock
>>> raised?
>>
>>
>> The people in question were poked on IRC.
>
>
> There are two things which surprise me now:
> 1.) Why are you addressing the Plasma team, while it was a Frameworks issue?
> Shouldn't you raise this to the Frameworks team?
> 2.) Why are you addressing the whole team, while the issue was not known to
> all members due to the communication only happen on IRC?
>
> It looks to me like a failure of individual people and not of the team.

I've addressed the Plasma team because the problem only occurs in
Frameworks whose development is principally driven by Plasma
requirements. The changes in question were all made by Plasma team
members.

The whole team is being addressed because i've had to chase down
enough people (all in the Plasma team) that it's reasonable enough to
assume the problem is team wide and as such should be addressed at
that level.

>
> To the problem here, I think we are looking at it from the wrong side. We
> also make a lot of noise after things fail to compile on the CI due to
> missing dependencies (long threads on mailing lists, personal attacks on the
> people having forgotten about it, etc. etc.). Nevertheless it happens again
> and again. This is a reoccurring pattern. What I take from this, is that the
> current approach to this problem does not work in our community.
>
> If I now compare to the Qt community I observe that there the problem could
> not happen at all, because the review tool ensures the code compiles before
> it gets pushed.
>
> What about we improve our tooling to make this possible as well? CI system
> testing our changes before we push them?

Before we look into that, i'd like to see responses and proposals to
fix the communication part of the issues I raised.
Pre-commit CI was going to happen at some point anyway (even had this
thread not being started) but everything boils down to communication
so lets fix that first.

>
> Cheers
> Martin

Regards,
Ben