Am 2017-10-08 10:22, schrieb Ben Cooksley:
On Sun, Oct 8, 2017 at 9:00 PM, Martin Flöser <mgraess...@kde.org>
wrote:
Am 2017-10-07 22:00, schrieb Ben Cooksley:
On Sat, Oct 7, 2017 at 11:57 PM, Martin Flöser <mgraess...@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
