Plasma Team Communication & Development Practices [MUST READ]

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

>
> A few personal thoughts now: we have a few things which currently just don't
> work yet:
>  * phabricator spams one with notifications, it's impossible to follow on
> them

To my knowledge Phabricator only sends you notifications for things
you are subscribed to.
This usually means you either authored something, commented on it, or
are a member or watcher of a project which is automatically subscribed
to those notifications.

If you go to the members page of a given project you can either
unwatch it, or disable email for it, in which case you'll only receive
email via mailing lists, or for reviews which you are explicitly
subscribed.

>  * build.kde.org is way too unreliable to follow it
>
> The latter point shouldn't be a surprise to you as I have been in contact
> with you about the issues with KWin since the switch to the new CI system. I
> have a personal view with all the projects I monitor, just right now there
> are 7 projects marked as yellow and one as red (33 % of all jobs). This has
> been like that since the switch to the new CI. It became better KWin/Suse is
> no longer failing that often
>
> Don't expect any one to look at it, if it is unreliable. A CI system is
> great to find that things break, but not so much if it is unreliable.

That's fair enough. My principal concern here is the ignorance of
failures though - which is a far more severe issue.

Generally when the CI fails, something is broken. The only current
breakages for Plasma are all on FreeBSD and are specific to that
platform (Qt too old, depending on Linux features, etc). As for tests,
i've no idea on how to tell what is an actual proper failure from
something wrong with the CI setup. This is something only a developer
can really tell.

I've taken a quick look at some of the Plasma tests that are currently
failing and two of the ones I picked are appstreamtest failures.

>
>>
>> We also had an issue recently where a project which had asked to be
>> incubated nearly ended up slipping through the cracks, had I not
>> pinged a Sysadmin ticket they had opened earlier about the whole
>> thing.
>
>
> This sounds exactly like the phabricator notification issue. I currently
> have > 1400 notifications. I constantly miss reviews due to that. I could
> mark all as read and then wait a day and we are > 100 again.

The discussion took place on the Plasma mailing list I believe - it
just didn't get communicated back to Sysadmin.

>
>>
>> Given one of the things we want to improve is new contributor
>> onboarding, this isn't a good look.
>>
>> Do you have any ideas on how we might fix this?
>
>
> Personally I think it's a tooling problem. I fear the activity of Plasma is
> too large for phabricator. I'm not a phabricator expert so I don't know how
> to reduce the notifications. Especially as it's duplicated, we also get
> everything on the mailing lists.

If this is an issue then it sounds like we need to segment Plasma and
break it down into smaller chunks which are easier to handle. Once
that is done we can retag Repositories and amend the Herald rules
accordingly.

As a group you'll need to come up with those chunks though. Note that
a repository *is allowed* to belong to multiple chunks - because
membership is just a tag and everything can have multiple tags.

As for cutting down on your notifications, i'd suggest turning off
Project Mail (navigate to Project > Members > Disable Mail) as a good
start.

>
> Cheers
> Martin

Cheers,
Ben