On Thu, Aug 10, 2017 at 11:06 AM, Adriaan de Groot <gr...@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