Am 2017-10-08 11:38, schrieb Ben Cooksley:
On Sun, Oct 8, 2017 at 10:02 PM, Martin Flöser <mgraess...@kde.org>
wrote:
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.
I have no idea what 'Sippenhaft' is.
https://en.wikipedia.org/wiki/Sippenhaft - apparently there is no
translation for that word.
From my perspective you are all collectively responsible for the
Product you release and reminding each other of appropriate
development practices. This includes things like when freeze dates
are, what version of Qt to depend on, and making sure the dependency
metadata is kept up to date.
No the Plasma team is *NOT* responsible for this as a whole for two
reasons:
* the report was only done on IRC
* it's frameworks not Plasma
I would not have a problem with what you write, if the communication
would have gone through a mailing list. What I take offense at is that I
as a team member should be responsible for not reacting to an IRC
communication when I was not in the channel. That is absolutely not
acceptable.
As I mentioned previously, these changes were all introduced by Plasma
developers, for the benefit of Plasma. All the other Frameworks don't
have any issues. I haven't assigned blame to the wrong team.
Sorry, but that's just not the case. If I work on frameworks I have a
frameworks hat on. If I work on Plasma I have a Plasma hat on. We have
multiple roles and this was frameworks, so address frameworks and not
Plasma.
We as a community should allow mixing of the groups. What you do here is
the exact opposite. A Plasma dev is a Plasma dev is a Plasma dev. No we
are not!
Cheers
Martin
