Replies to Ubuntu Open Week questions, part 1

Jonathan Jesse jjesse at iserv.net
Thu Nov 30 03:44:44 GMT 2006


Christian,

Thanks for both answering a lot of questions others had that were my own and
hosting a great session.  I'm not able to attend live, but I've enjoyed
reading the logs that are put out and have learned a lot

-----Original Message-----
From: launchpad-users-bounces at lists.canonical.com
[mailto:launchpad-users-bounces at lists.canonical.com] On Behalf Of Christian
Robottom Reis
Sent: Wednesday, November 29, 2006 6:53 PM
To: Launchpad Users
Subject: Replies to Ubuntu Open Week questions, part 1


This is a list of questions that went unanswered yesterday in my Ubuntu
Open Week talk. For those of you who don't know this is going on this
week (which means that Jono didn't cross-post his announcement enough!),
I have another talk tomorrow at 21:00 UTC:

    https://wiki.ubuntu.com/UbuntuOpenWeek

On to the questions:

> <davmor2> QUESTION: is launchpad becoming a really useful tool across
> linux as a whole yet? If not when do you think it will get there?

Launchpad is on the road to become a very relevant tool across Linux and
free software in general.  Already we have a large number of upstream
projects registered (538 of them with bugs, and 427 with translations,
as of today). We have a very important distribution, Ubuntu, using it as
its official bug tracking, community support and translation tool, and
the cross-project benefits stemming from there are great [*]. Projects
can also migrate to Launchpad in steps -- they don't need to take up
Launchpad all at once, and we worked to ensure that Launchpad
interoperates well with projects that have chosen to stick to their own
bug tracker, translation process and version control system.

As for 'are we there yet', it depends on how you define 'there'. Already
Launchpad is a daily staple for a large community of developers,
contributors and users, and this community will grow as we get more
upstreams involved with Launchpad. Next year will be a very important
year for Launchpad -- the one where I think we will cross into the
territory where we offer enough benefits to be seen as a madly
compelling place to do work.

[*] Ubuntu is a big driver in Launchpad 'marketing' partly because bugs
filed in Ubuntu are often upstream, and these bugs need to be forwarded
to upstream projects. Read on for more on this..

> <lotusleaf> QUESTION: The other day I confirmed a bug for kdar, and
> thought I made a mistake by also creating
> https://launchpad.net/products/kdar , but I was informed in #launchpad
> that this action was correct, is there a particular need for people to
> fill in more items in /products/ so they are listed for upstream? I've
> noticed a lot is seems to be missing.

Yes, that's definitely something we want. Let me cover this in more
detail since it's a great benefit to everybody if we manage to get a
process for this done right.

Ubuntu packages a lot of upstream products. Many of these upstream
products already have their own bug tracker, and all of them already
have their own communities, but Launchpad doesn't know about any of that
until somebody comes in and registers it for us. In that sense Launchpad
is a bit like Freshmeat -- a global registry of products.

However, Launchpad makes full advantage of that registry to ease
processes in its applications. For instance, you can specify that 
upstream project Web Foo uses a Bugzilla instance at
http://bugzilla.web.foo/.  When bugs filed against Ubuntu are then
identified as being Web Foo issues, you can easily link to Web Foo's
Bugzilla bugs. This is a simple thing that saves Ubuntu triagers and
developers a lot of time!

Knowing about the community is important as well. It's essential to be
able to contact upstream about a new bug in Ubuntu that hasn't been
filed in their bug tracker yet; without this information it is much more
work to actually push the bug upstream.

> <lunitik> QUESTION: If "a number of launchpads popped up", surely it'd
> suite everyone if all of these were linked? Then have launchpad.net be
> the centralized Launchpad... wouldn't this widen the use of Launchpad?
> Would it even be possible to ensure all Launchpads are linked?

Participating in a federated system is usually voluntary, and it's
technically hard to ensure that every hypothetical mini-Launchpad out
there would connect to us. The issue with having a federated system is
that it is a /lot/ harder than theoretically construed. We've been
taking ideas from the more general idea of decentralization and using
then where possible: the idea for bug watches, for instance, is a
reflection of that. Where there are ways to operate in a distributed
fashion without impacting Launchpad further, we will want to explore
them -- so let us know if you have one.

> <antihec> QUESTION: I remember plans of making a "dot-ubuntu" service
> for users similar to dotmac of some kind. would that integrate into
> launchpad? what is the status of that?

I'm not sure about this one! I suggest asking Mark or Matt directly; if
it does become a reality I'm pretty sure Launchpad will be involved.

> <macluvjay> QUESTION: will you be charging DISTROS to use LP?

We may, though there is no decision on this yet. There is some agreement
that selected community distributions should have access to Launchpad
features, but for the package management side of things in particular
there may be a commercial fee charged. I'd like to hear educated
opinions towards this, by the way.

> <lunitik> QUESTION: Does Launchpad close bugs automatically today? If
> not, how are bugs treated when Ubuntu re-syncs with Debian?

Launchpad doesn't close bugs automatically via commits or package
uploads, but it is something we will be working on in the next cycle --
IOW, in the first three months of 2007. I'm not sure how that ties into
re-syncs, though -- bugs that were present in the old packages still
need to be manually closed (though bug watches can at least let people
know when the Debian bug was fixed) and bugs present in the new packages
need to be manually opened.

I can see here two potential improvements that would save time, which
have already been discussed in the past:

    - Closing Ubuntu bugs that have been closed upstream when syncs come
      in. This is slightly tricky because we need a way to detect when a
      sync came in and close the Ubuntu tasks for the bugs fixed in
      Debian (which will already be marked fixed in Launchpad by virtue
      of bug watch updating).

    - Filing Ubuntu bugs for issues reported against Debian packages
      when we sync them. We can use bug watches to check whether the
      Debian bugs have already been linked to Ubuntu bugs in this
      process.

> <greguti> QUESTION: what is a "bzr" directory?

This is best asked to the Bazaar team (on the #bzr freenode channel, for
instance, or on their mailing lists) but it is essentially describing a
directory being controlled by the Bazaar version control system, the
amazing VCS started by the even more amazing Martin Pool. Read more
about Bazaar at http://bazaar-vcs.org/

> <malakhi> QUESTION:  Is there, or will there be, an API for Launchpad?

There is already a very small XML-RPC API for the bug tracker, and
Launchpad's API will definitely be growing over the next year. We want
to make Launchpad really easy and interesting to work with from your
client application, and while we have only now been getting the last of
the basics implemented (in a larger sense) we're almost at the point
where this API will become a priority.

Read more about the existing API at:

    https://help.launchpad.net/MaloneXMLRPC

> <stefg> QUESTION: What about ubuntu-specifc packages, like usplash. Are
> 'upstream' and launchpad identical in this corner-case, or is there a
> usplash team, that needs to be contacted by the launchpad team?

Upstream X and Ubuntu package X are pretty much identical in this corner
case, and for most of them the package maintainer is also the upstream
maintainer. However, most of these upstreams have their own products in
Launchpad, and they use Launchpad's bug management features to track
bugs happening across upstream and package releases. I'm not sure I
understood the question about teams -- the Usplash maintainers are
registered in Launchpad, and are directly contacted when new bugs are
filed for instance. There is no need for any manual assistance by part
of the Launchpad team in that case.

The remaining questions will be answered in part 2, soon to come!
-- 
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

-- 
launchpad-users mailing list
launchpad-users at lists.canonical.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/launchpad-users




More information about the launchpad-users mailing list