github, phabricator: a new threadZ

[Harald Sitter]

On Thu, Aug 10, 2017 at 11:06 AM, Adriaan de Groot <groot at kde.org> wrote:
> Perhaps we should ask sitter what kinds of scratch repo's those were, and
> whether he would have created them on KDE infra, if there was a similarly
> simple one-click way to create scratch repo's.

- experimental snap build tooling for neon's jenkins
- experimental os-autoinst (openqa) tooling
- experimental jenkins plugins (later migrated to git.kde for rollout)
- experimental api.projects.kde.org (later migrated to git.kde for rollout)
- experimental appstream health to junit converter
- experimental filelight-ming32 build using only cmake
- experimental plasmoid to track packagekit activity (later migtated to git.kde)
- experimental dbus traffic recording and playback system for mocking
services on a dbus level
- various rbot plugins (later migrated to git.kde)
- assistive service for logind session cleanup for racnoss (later
migrated to git.kde)
- sftp-to-http bridging service for neon's jenkins to get access to
pre-release tarballs
- experimental snap bundle running an entire plasma desktop
- experimental apache config example for transparent fallback from
drupal to a static set of pages on 404
- migration script for kanboard to phabricator (which was used to
migrate KDE todos)
- some other experimental helpers mostly to assist with one of the
aforementioned things

Everything denoted experimental was created not knowing if this is
production viable or even worth seeing through to production quality.
Barring a minor problem with git.kde not being able to support https
clones with `go get` I'd probably have created them all as
"throw-away" repos on KDE infrastructure since there is no immediate
benefit to these things being on github.

For good measure in the same time period I've forked or worked on
forks of the following on github:

- aptly (repo server used by neon)
- appstream & appstream-generator
- various jenkins plugins
- the bot service which closes PRs against KDE's github mirror repos
- repology (distro-package-version-tracking website)
- various ruby gems
- snapd & snapcraft
- packagekit

On that note: anecdotal evidence suggests that a lot of jenkins
plugins suffer from the "dead repo" problem often mentioned. 3/3
plugins I submitted PRs against have not gotten a review or only after
months sitting there. They are all under the shared community
jenkinsci organization though.

And on a further note since I write a lot of ruby: I'd have to think
twice or trice about putting "vast/complex/more than a bunch of lines"
ruby software on KDE infrastructure, even if the software was very
related to a KDE project. I'd miss out on easy access to the vast ruby
ecosystem centered around github. That's not necessarily an
infrastructure fault on our side, but I thought I'd mention it. Food
for thought: maybe KDE infra should feel similarly like a want-have
when writing qt software.

HS