Plasma Team Communication & Development Practices [MUST READ]

[Martin Flöser]

Am 2017-10-08 10:22, schrieb 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.

This is totally uncool. That is Sippenhaft! The Plasma team is not as a 
whole responsible for what people do! Especially not when they are part 
of the frameworks team! Please address the frameworks team if there is a 
problem in frameworks. Just because people have different roles doesn't 
mean you can just blame the one team! This is absolutely uncool.

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

Let's start with things like not blaming groups!

Sorry I'm really, really annoyed now. Being hold in Sippenhaft is 
something that really doesn't go well with me.

Cheers
Martin