“But why isn’t Debian using Launchpad?”

Due to my work on Ultimate Debian Database, I’m sometimes asked why Debian isn’t using Launchpad.

First, “using Launchpad” can mean two different things.

The first possibility is using Canonical’s instance of Launchpad. That would mean creating a Debian project on launchpad.net, and using Canonical’s infrastructure. Well, that’s clearly not a good idea. We (Debian) do not want to depend on Canonical to fix bugs or make enhancements that we require to improve Debian. For example, Canonical imposes the use of the Bazaar Version Control System in Launchpad: you simply can’t use Git instead (git-bzr hacks don’t count). We want to stay in control of our infrastructure, for obvious reasons.

So the other possibility would be to setup our own instance of Launchpad, given that Launchpad is now Free Software. However, it is not clear if it is actually possible: I was told by a Launchpad developer that they didn’t know of any external (outside Canonical) installation of Launchpad.

Even if this was possible, it is not clear at all that the Ubuntu infrastructure is superior to the Debian infrastructure. The Debian infrastructure has many nice features that are missing in Launchpad, for example version-tracking in the Bug Tracking System, which allows to track (by parsing the changelog) the versions of a package where a bug has been fixed or not (example with iceweasel).

So, when switching to Launchpad, we would have to reimplement quite a lot of needed features in in, with no clear benefit: the Debian infrastructure works fine, and is actively maintained.

It’s also interesting to note that while the Ubuntu infrastructure is centered on Launchpad, there are quite a lot of external services that are not integrated in Launchpad: the Ubuntu popularity contest, merges.u.c, patches.u.c, the various services on qa.ubuntuwire.org and qa.u.c, etc. With the Debian model, it is very easy to add a new service and get it integrated with the various dashboard (Debian Developer’s Packages Overview, Packages Tracking System). Within Ubuntu, those external services are really second-class citizens. All in all, the infrastructures of the two projects reflect their organizations: bazaar model for Debian, with an emphasis on collaboration between the services, controlled by Canonical for Ubuntu.

24 thoughts on ““But why isn’t Debian using Launchpad?”

  1. Last time I checked some images in Launchpad were non-free so you have to go through a real rebranding cycle to set it up yourself. The choice was more or less deliberate to urge people to use the central Canonical-provided Launchpad instead, I was told.

  2. In my admittedly limited point of view, there would be at least some gain in Debian running its own LP instance. Even though it would miss some features initially, as Debian gets it implemented, Ubuntu could get those changes too and improve its bug tracking. Also, Ubuntu and Debian sharing some infrastructure would mean that quite a lot of work wouldn’t be duplicated.

    At a guess I would think that Canonical would only be too happy to do provide assistance in setting up an LP instance on Debian infrastructure. So even though setting up a separate instance may have some challenges, I’m sure there will be some good help available.

    PS: I don’t work for Canonical

  3. I’m confused. First you say that Ubuntu is using bazaar, and Debian would need more than than. Then you say that Debian’s model is bazaar, and Ubuntu’s is not.

    (SCNR)

  4. I am a fan of both Debian and Ubuntu and personally use Ubuntu for my system.

    While I welcome more Ubuntu Debian cooperation and harmony, I do not see how Debian using launchpad is required or significantly beneficial for this.
    Think about “Why is UBUNTU using launchpad?”
    It’s because ubuntu has its own needs which is addressed its own way.
    Now the answer to “But why isn’t Debian using Launchpad?” becomes apparent

    If reducing redundant effort is what is wanted, than the fundamental answer is more communication and effort. Mutual understanding, acceptance, and respect(not only on canonical’s part but also on the debian developers part) of each other as an separate and codependent entity is paramount.

  5. Sharing this piece of infrastructure between Debian and Ubuntu isn’t that important in the scheme of things. As I wrote in an open letter to Mark:
    ———
    The main concern I have about the current situation is this: when an Ubuntu person does some coding work and posts the diff to a website, it is now a workitem for someone else in Debian to dig into and understand. Of course, having that fix is helpful, but the time to do something is mostly the time to learn how to do it.

    If you pick up a violin, it will be clumsy to you unless you know how to play one. It is the same with a patch if you haven’t seen it before. So therefore, whenever someone learns something, they should make sure that they do their work in both Debian and Ubuntu to save someone else time.
    ——-

    Using Lauchpad doesn’t help with this issue. It isn’t a matter of “respect” and “acceptance”. It is a matter of creating a situation where two teams aren’t constantly redoing each others’ work! The frustration towards Ubuntu by Debian is because separate teams automatically makes working together much harder.

    The best way to solve it is to have volunteer developers join Debian and work with the existing people there to maintain packages together. This automatically enforces a division of labor and is efficient because patches flow downstream from Debian.

    If Ubuntu is such a great thing, they should be sending 100 new devs a year to Debian.

  6. I agree that there is no need for using Launchpad for the Debian project. Diversity is good.

  7. What does Debian use instead of Launchpad? Is it FLOSS?

    Kind Regards

  8. I don’t know if debian buildds can do this but having a debian PPA’s would be awesome. The only public buildd for debian that I know of is openSUSE build service and it doesn’t feel like a debian tool: doesn’t support testing nor sid and you can’t dput into that.

    The advantages of using launchpad imho is the team management – alioth project groups didn’t take off debian is using mailing lists, wiki & BTS for the most part and it doesn’t provide for outsiders to have upload rights and do merge proposals. Patches attached to BTS bitrot and not everyone has alioth ssh account (although it is relativly easy to get one)

    Why don’t we get gitorious on alioth? that would rock! and allow public merge requests (e.g. you can’t create new projects, just clone debian packaging repos & propose branch merges with a limit of 50MiB additional objects will be plenty for any debian patch work per user). Also we could host upstream git mirrros where it makes sence to release snapshot builds to experimental straight from gitorious.alioth.org

    And negotiate to have a ppa builder on launchpad? They recently got a private – invite only armel ppa why can’t we get debian one there. Infrastructure is there & launchpad does store a debian mirror imho this is an investment issues (canonical wants people to get hooked on ubuntu&launchpad combo). Something like ppa for members of ~debian-ppa and accepted people into that team who got at-least one package sponsored into debian already.

    Lets get youngsters to develop debian using shiny things =)))))))

  9. > Also, Ubuntu and Debian sharing some infrastructure would
    > mean that quite a lot of work wouldn’t be duplicated.

    Really. Maybe Ubuntu shouldn’t have created their own bug tracking system to begin with, or their own ‘method’ to ‘submit’ patches to Debian, or their own distro at all. Debian has it all pretty much covered.

  10. “Maybe Ubuntu shouldn’t have created their own bug tracking system to begin with”
    If Debbugs didn’t suck at usability then no one would bother to create Malone (Launchpad’s bug tracker).

  11. Azrael;

    I already responded to that point of yours on my blog. I’ll post it again for you here.

    ——-
    I do agree that it can be cheaper to build a new codebase than improve an existing one if the codebase is in really bad shape. You have to look at the codebase to decide. You present evidence that the debbugs tool is missing features, but not that it should be thrown away. Comparing debbugs to huge things like Mac OS 9 or Firefox is not appropriate. It is easier to fix chunks of a little web app like debbugs as it is not millions of lines of code.

    The point is that rather than creating everything from scratch, he could have fixed / energized the existing efforts *and people*! Now we have two groups of people doing the same thing.
    ——-

  12. Hi Lucas,

    You say that it would clearly not be a good idea to use the Canonical instance of Launchpad because “We (Debian) do not want to depend on Canonical to fix bugs or make enhancements that we require to improve Debian”. But, on the premise that Launchpad is free software and Debian could therefore submit patches and branches to fix bugs and make enhancements, I think what you are saying boils down to “We (Debian) don’t trust Canonical to merge our patches/branches”. That seems to me to be the wrong type of reason, and I don’t think there are grounds for it.

    If you think that Launchpad is inferior to Debian’s own tools for its purposes, and that those inferiorities outweigh any benefits that would be gained in terms of ease of use for users, then that’s obviously an understandable opinion. I’d look forward to a healthy debate with Launchpad developers on some of the details on that and whether such deficiencies can be remedied.

    But it strikes me as a shame if the reasoning is based on a lack of trust.

    (I also don’t work for Canonical.)

  13. The issue isn’t trust; it simply would never be a priority for LP maintainers to merge Debian-specific patches and if there was ever a conflict of interest Debian would always have to cede.

  14. Lots of interesting comments on that post. Thank you.

    @Matthew: given that Ubuntu itself is in a customer/provider relationship with Launchpad, which sometimes creates some friction, I don’t see how we could reasonably expect Debian to switch to Canonical’s instance of Launchpad, ask for some changes such as the addition of Git support, and have them integrated. I mean, I’ve been asking for Debian PPAs, and the answer was “no”.

    @Jonathan: there would probably be a little gain in Debian running its own LP instance, but the losses would be huge in comparison. We would basically spend months reimplementing the features that we have in the Debian infrastructure and that are missing in Launchpad.

    @Aoirthoir: Debian uses an aggregation of different services. All of them are free software, although Debian doesn’t make any effort to distribute the software for most of them (it’s probably going to be very difficult to set them up outside of Debian).

    @KeithCu: I agree that the issue of collaboration between Debian and Ubuntu is more social than technical at this point.

  15. Launchpad is modern development infrastructure attractive for famous FOSS project (mysql, mariadb, inkscape, drizzle, zeitgeist). In opposite Debian uses ugly FusionForge for alioth (less than 10% of features used btw), strange mbox based BTS and bunch of other home grown non integrated, used-by-nobody-but Debian services.

    Ubuntu at least uses OpenID and REST APIs at Launchpad and other services.

    Last time when i was going to report bug to Debian BTS i spent some time trying to add custom headers to my email and finally reported bug to Launchpad. I cant recommend Debian for my grandma but i really want to contribute to project that i can recommend.

    I like independence of Debian but why are You so conservative, guys? Look at main page of Debian. It feels like “Welcome to the 80s”.

    Looke there:
    http://www.debian.org/devel/website/translating#completenew
    I going to read “Debian Translations Compilator Manual” to translate some page for Debian project. So ugly way.

    > The Debian infrastructure has many nice features that are missing in Launchpad, for example version-tracking in the Bug Tracking System, which allows to track (by parsing the changelog) the versions of a package where a bug has been fixed or not (example with iceweasel).

    I think this changelog paraser can be easily integrated to any system modern system as plugin.

    This conservative trends really sucks.

  16. And one more thing:

    I suppose that usage of UDD is locked to debian servers. Can i query this ulitmate db from my server? I doubt. But with launchpad REST API i can make search queries, fetch project metadata in unified format, create and close bugs via email and REST, create new projects without asking some busy administrator. Launchpad is really much more open model for development than Debians infrastructure.

  17. Hey Lucas,

    Great post.

    I’ve got a few comments from the Launchpad side of things.

    — if Debian started using its own instance of Launchpad, and that didn’t share all of its data with Launchpad.net, we’d consider that a fail. To us, the whole point of Launchpad is to make cross-project collaboration easier, faster and more fun.

    — You are right that there are many services around Ubuntu
    development that are not a part of Launchpad. Many of us in the
    Launchpad team want to make Launchpad’s internal architecture more loosly coupled, which would make many of the external services “first-class citizens”, to use your metaphor.

    — We know Launchpad lacks features that Debian’s infrastructure has. Oh boy do we know. But we also want to fix it.

    — I’m totally happy with healthy competition. Everyone benefits that way.

    jml

  18. I don’t know if Jonathan Lange will see this, but I thought I’d respond anyway.

    The idea that Ubuntu and Debian should be competing on their bug trackers is totally silly. Do you see two groups within the Linux kernel team building competing bug trackers?

    Launchpad was a waste of time and should not have been built. I’m not saying that Launchpad hasn’t done interesting things, only that it should have not have been created as an independent entity.

    Part of Mark’s problem is that he has surrounded himself with a bunch of people who don’t really understand free software or appreciate Debian.

  19. Keith, I’m afraid I don’t find your arguments compelling.

    I don’t really know if I understand free software or not. I’d rather just get on with making it.

  20. @Jonathan Lange:

    I agree that most people, and probably you, don’t need to understand free software — they just work in the codebase that was setup for them. Whether that software is one Debian is using, or “competing” with Debian’s, is decided by other people.

    I’m not sure what specific arguments of mine you don’t find compelling. But discrediting them involves examining opportunity costs and I quite doubt you’ve done that. One of the biggest reasons why free software and Unix has never succeeded so far is because there have been so many forks. Launchpad is just one symptom of this problem that exists between Ubuntu and Debian. The creation of Ubuntu created many of these problems.

    There is a strong tendency to look at the current situation and assume that it needed to be done exactly as it was to get the results that have been achieved, but that is wrong. The key is getting a lot of good people to work together — even those who don’t understand free software.

  21. My goal is not to “poison the well”. My goal is to point out the inefficiencies in the current situation so you all can brainstorm on how to do things better.

    4 people working on 2 separate bug trackers is not as good as 4 people working on 1. That is basic math. Of course, this problem was created many years ago, and the toothpaste is well out of the tube. Extra bug trackers is not the biggest problem, although I’m sure Debian would have appreciated those resources. Ubuntu is clearly taking from Debian, but is it giving back?

Comments are closed.