github, phabricator: a new threadZ

[Ben Cooksley]

On Thu, Aug 10, 2017 at 11:57 PM, Harald Sitter <sitter at kde.org> wrote:
> 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.

Please note that the anongit system does support https and can be used for this.

Due to the needs of those behind restrictive networks, such as Italian
research labs and Indian universities we have to offer SSH over port
443, so git.kde.org cannot provide HTTPS services.

When we transition to Phabricator hosting we will likely re-arrange
the setup of addresses and offer something like scm-ssh.kde.org for
those who are operating behind these crippled networks. Once that is
done, we should be able to provide https://git.kde.org/ access
(although it will likely just redirect Git clients to anongit and web
browsers to Phabricator)

As an aside, i'll note that these organisations must not be members of
Eduroam, as part of the agreement for being an Eduroam member includes
port 22 (SSH) being permitted for outbound traffic. If your research
lab or university is a member of Eduroam but is not allowing SSH
traffic please file a complaint regarding that.

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

Cheers,
Ben