[kde-community] Official KDE mirror on github

John Layt jlayt at kde.org
Mon Aug 17 07:48:15 UTC 2015


So some random thoughts, and I'm still on the fence.

We clearly have a problem with discoverability, partly due to our
infrastructure issues, partly due to the new generation of 'open
source' developers thinking the world revolves around Github (*). One
of those things we have the power to fix, the other we don't. For the
latter a Github mirror would seem to make sense, but it would need to
be carefully managed (by who?). For the former the SysAdmins are
working hard and I look forward to the results. If we can offer a
Github-like experience (**) while keeping our independent
infrastructure that is easy to use and discover and ranks top in
google then brilliant. But we need to think about this in terms of the
entire new developer experience, and we've been failing badly on that
for a while.

(*) Actually they're nor Free or Open Source devs, they're just devs
looking for code to use or to share their code, and don't care what
the licence is or philosophy...

(**) How much of the issue is just the poor state of FOSS hosting
solutions? We're software devs, can't we fix that?

How will having multiple mirrors affect google rankings? Will there be
a page full of repos for a confused dev to choose from? Where do we
stop, just Github, Gitlab and Bitbucket? Or more? The last thing we
want is for google to send people off to github as first choice.

What can we do to improve our own search rankings? I know the php
frontends are bad performers, can we give search engines a more direct
route that can be easily linked back to the main frontend?

I would note from reading the Gnome wiki on Github that you can't
globally turn off pull requests for an organisation, you need to do it
for each repo. It would also appear they manually deal with incoming
requests to transfer patches over? Ouch.

There's two separate groups we need to target here, devs who just want
to use our code (Frameworks mostly) and maybe offer the occasional
patch, and devs who want to get involved on KDE development. For the
former, being easy to find and build is primary. For the latter, not
so much as they'll be more motivated to jump through our dev
experience hoops, but they still need to find us in the first place
and a difficult experience drives too many away. (and no, that's not a
good thing, making it hard to get in does not guarantee you only get
get smart people, just the stubborn ones).

So, a proposal for a trial. Given how tricky it is to build KDE stuff,
and we're not sure what impact it will have on linking and google
ranking, how about we conduct an experiment. Open a kde_community
organisation and only mirror our Tier 1 Frameworks there, seeing as
they just need Qt and cmake stuff and so are easy to build and are the
thing we most want to share with outside devs. Or schoose a small
stable subset of Frameworks. Disable issues and pull requests, add
readme's pointing to TechBase for info on how to build and how to
submit patches, then sit back and see what the results are in terms of
google ranking and code submissions. Perhaps do the same for Gitlab
and Bitbucket as well.

(We should nab kdecommunity or kde_community on all the hosts asap,
regardless of what we do!)

Any volunteers, because to be blunt the SysAdmins have enough on their
plate in sorting out our own infrastructure!

Regardless, we really should work on our own new developer story, both
in tooling and documentation. I've started on the docs, but we need to
improve the tooling too to make it easier and more convenient. It's a
competition we're loosing to other projects that have better new dev
experiences. Think of it as a UX problem and lets get to solving it.

John.



More information about the kde-community mailing list