KDE Connect on Github

KDE

A month ago I created two mirrors for the KDE Connect repositories in Github, and I’m really happy  with it. Projects in Github are more discoverable than in our internal KDE repo (our GIT web interface is not even indexed by search engines!), and makes it easier for new developers to get involved and send contributions, like these pull requests. Of course, I have no plan to drop KDE’s Git repo: Github is not free software and we want to make sure our code is always accessible through our floss-based infrastructure. Also, the KDE repo is nicely integrated with our tools, like the bug tracker and review board, but I still think that having a mirror in Github is a good addition.

Other free software projects already host mirrors in Github (see Gnome), and they even have support just for that use case: Github Mirrors. I think we could greatly benefit from doing something like that KDE-wise, as we would both gain visibility and reduce some load from our servers. As of now, I’ve done it with KDE Connect and I have no regrets :)

Edit: Made clear that we will always allow access to our sources via our free infrastructure.

20 thoughts on “KDE Connect on Github”

  1. About the server load: there is already a mirror infrastructure in place for KDE git repositories. When you git clone from anongit, you are not loading the main server.

    Our main project web interface (projects.kde.org, which was not just a git web interface in the original plan) needs a replacement; alternatives are being investigated (including our test instance of phabricator).

    If it is just a mirror, does it mean you will disable issues (in addition to pull requests)?

    Reply

    1. I like having pull requests there because it’s a very accessible way for people to contribute and it’s also easy to pull these changes back into the main repo.

      Issues were enabled until now, but it’s true that it makes more sense to have them all agreggated in a single place, so I disabled them :)

      Reply

      1. I would say that the question is: what can we do to make it more accessible to contribute even with our infrastructure?

        Reply

  3. I have been interested in contributing to KDE for years, and I know that KDE’s mantra of being approachable, yet very configurable when needed, encapsulate everything I want in a desktop environment.
    That said I have not yet come to grips with the KDE infrastructure. The bug tracker for example is not managed in a consistent way, where bugs “disappear” when tagged with “need more information” etc, just because the chosen bug-tracker is not used as intended.
    The homepages for the individual applications is seldom updated, and gives an impression of being stale. Many pages for applications even leaves me wondering what the application actually is intended to do. Going to these pages I can not find links to developer discussions, latest bugs or any user thoughts or feedback.
    I understand that most things is discussed and done in mailing-lists or on IRC, this obviously work quite well for developers (as the software and thoughts coming out of it is stellar) but might not be inviting enough for people wanting to dip their toes and give their two cents.

    To date, I find that the applications that I in my limited way been able to contribute to, have been hosted on GitHub. Where both bugs, contributions , user input and development tracking is literally, in your face.

    I am currently using Plasma 5 on Arch Linux, so KDE connect is not building for me at the moment:-) Given that my girlfriend has become addicted to KDE Connect, I am eagerly locking forward to 5.4 hitting the repositories.

    Thank you for making my computing life interesting and full of hope :-)

    Reply

  4. @Kjetil I very much agree with your points. I love KDE but the surrounding infrastructure seems like a mess to newcomers from the outside. Even the main website is unsuitable to point non-nerds to let alone the various dev backends for new developers to get involved with. I’ve spoken to many KDE fence sitters and almost-ex winmac users and from their point of view the entire KDE infrastructure may as well be a black hole, it doesn’t exist for them in any meaningful way and what they do stumble across does not help them understand KDE or free software in general. The only part of the KDE backend that is in a new users face and actually meaningful is the various distro packages systems that deliver them the packaged software they use. When newbies do eventually resort to google for answers it often goes downhill quickly and in itself becomes a bad experience.

    As for wannabe developers all I can say is that Github is a excellent example of how to do it right and Launchpad is a “good” example how to get it horribly wrong.

    Reply

  5. So, we want to promote non-Free infrastructure for Free software? I use GitHub professionally because part of my work-work depends on repos hosted there, but I would not host my stuff there (and I don’t).

    “surrounding infrastructure seems like a mess to newcomers from the outside”

    There are two-three people doing sysadmin work in their spare time. More help is needed to improve the situation. Besides, as Tosky already said, there are alternatives being investigated, you can’t expect to change things from one day to the other…

    Reply

    2. I’m not using Github *instead* of our free self-maintained stack, but in addition to. We don’t rely on it, and you can contribute to KDE Connect without using Github at all, but for people who use Github, no they can.

      It’s a similar case with KDE Connect being in the Google Play Store, which is not free. We are also in F-Droid, a free store, so you are not forced to use non-free software, but if we were not in the Play Store at all a lot of users wouldn’t know we exist.

      Reply

      1. But you may want to change the wording on your blog post. Having the project hosted on KDE infrastructure is not just convenience, but it is a *hard requirement* to be called as such, as per the Manifesto.

        Reply

  6. I was considering the same thing for some of the PIM repos basically for the same reason – to try to attract more developers to the project.

    One question :how do you handle synchronization from KDE to github? Do you just push to github manually from time to time?

    I understand the points that Luca and Tosky made, but I myself don’t have a problem in including github *as one of the entry points* into contributing to KDE. Of course I would not agree with migrating our infrastructure there, or having our infrastructure rely on it. But if it’s just yet another way for people to contribute I think that’s fine. If someone has a problem with non-free service, they can always use the standard channels to contribute to KDE. I don’t however see a reason in closing such an important channel, especially in the current situation where almost every project is understaffed.

    The Phabricator that is being tested is a nice thing, but it’s not github. Until we have something where contributing is as simple as on github (hell, you can even do simple changes and commits directly from the web ui there!), well, we have to use github…

    Reply

    1. Hmm, “…we have to use github” does not really captures what I had in mind….if we want to make it simple for new/occasional contributors to contribute to KDE and as long as we cannot make it as simple as github does I believe that we should not simply reject the opportunities that github offers. At the same time we should not force it on anyone of course.

      Reply

      1. To update Github, as of now it’s something I do manually (it’s just another remote to push to from time to time), but if we use Github Mirrors it should happen automatically :)

        Reply

    2. My point is: we already have a core piece of infrastructure (OCS) relying on non-Free, unmaintained and totally closed project (the ironically named “opendesktop”). I don’t want this to become the norm.

      Reply

      1. Yes, relying on a nonfree service is bad. Supporting it, or making use of what it can offer is IMO not.

        Reply

        1. yes, it is a matter of practicality. Not being there simply loses out on a lot of potential contributions – KDE wants to create great software, not be a hosting platform or improve software hosting tools. Matter of priorities, imho.

          That is why ownCloud is on github: it lowers the barrier to contribution.

          Now I wouldn’t advocate for KDE to move over, but at the very least allowing people to contribute through the familiar github infrastructure is a smart thing to do.

          Reply

          1. Smart, provided you of course want KDE to ever get anywhere near what it once wanted – provide a free desktop experience to a lot of computer users, as opposed to just being a fun playground for an elite few which it is today.

Leave a comment