New software created for Ubuntu

Raphael Hertzog hertzog at
Wed Jun 2 07:55:35 BST 2010


(responding to two mails at once)

On Tue, 01 Jun 2010, Sebastien Bacher wrote:
> * you need to have a spare machine, or a spare partition and reboot to
> use it or a vm. In practice I don't want to reboot while I'm using my
> computer and my spare computer are already used to run stable and lts
> versions of Ubuntu so I fallback to use a vm there

You can also use a chroot. Many Debian developers use a sid chroot
on a lenny machine.

> * Debian unstable has quite some activity and Debian doesn't allow
> source uploads, which means you need to keep an unstable box uptodate to
> do build and uploads It might be a non issue on fast internet but it
> often means over an hour download on a slow dsl line and the latency
> issues and slowness created for other downloads during this time impact
> on the work you try to do. I tend to use non working times to update my
> ubuntu machines and delay Debian update which means I often have the
> case where I need several hours download to be able to catch up and do a
> Debian build.

The average package is not big enough to justify worries concerning upload
times, really. It's the first time I see such a remark except and kernel maintainers.

> * Some packages easily get hundred bug reports and most maintainers
> don't keep up with bugs on launchpad already, the cost of reading the
> bugs in the bts as well is far from be null

Again, this is not representative of the average package. And you get less
bug reports in the BTS than in launchpad and they are usually of better
quality in my experience.

> * If you want to do proper integration work on Debian you should also be
> reading Debian lists to be aware of coming transitions, freeze, etc.
> That's also extra informations to deal with and taking efforts.

It's one mailing list: debian-devel-announce at, it has a dozen mails a

> So while being an Ubuntu maintainer it might seems to be easy to upload
> to Debian it requires non trivial efforts. The question is also to know
> if you prefer an Ubuntu maintainer doing a Debian build in a vm, a quick
> test, upload and looking to the Debian bugs on the bts every few weeks
> or do you prefer to let the packages to be maintained by somebody using
> Debian most of the time and being wanting to maintain it correctly?

If there is someone on the Debian side, the question is moot. The problem
arise when there's nobody yet on the Debian side.

Here I'd rather see you package it in Debian (even if somewhat less tested
than if it would be your daily distribution), open a RFA (Request For
Adoption) from the start indicating your wish for someone more actively
involved in Debian to take care of it.

> So far launchpad has many features that helped us to work with debian
> & upstreams. Linking bugs across distributions, packages and upstream
> bug tracking systems has been extremely valuable when upstreams
> approches and says please push this commit there in there. Within half
> a hour we have packages build in developer-preview ppa, upstream test
> those and we push to "testing" ppa to get responses from bug
> reporters. And it's just awesome to be able to do $ bzr merge
> -rsvn:4096..4098 lp:upstream to get critical patches. We also test
> packages for RPM based distros using openSUSE build service.
> None of these features are provided by alioth. It would be great if
> alioth could at least get integration with BTS and / or to have some
> build-daemons available for test builds.

Opensuse build service has nothing to do with Launchpad. It's not fair
to mention it in that comparison.

> Please point me to at least one packaging team that uses alioth
> collaboration features. So far I've seen packaging teams use BTS,
> mailinglists and ssh code hosting. And arbitrary people cannot push
> branches to alioth without joining the team first.

People can host personal branches in their home directories (in
~/public_git/ or ~/public_bzr/) even when they are not part
of the target project (they have to be part of one project at least
however in order to have the UNIX account).

Clearly Alioth's ticket system is not used and the BTS is used, but I
don't consider that a problem. You can easily put a link to the BTS web
page (nowaday you can even add arbitrary links to the alioth project page
thanks to the extratabs plugin).

> pkg-crosswire-devel team has 15 upstream developers, 2
> debian-developers (act as sponsors) and a handful ubuntu prospective
> developers (packagers) and so far we have maintained excellent
> communications with Debian & Ubuntu and upstream communities.
> I'm sorry but alioth is not a valid platform for
> cross-distro/cross-project collaboration unless it's API will open-up
> to external services to hook into it.

We're always open to specific suggestions and contributions are welcome.

> I really want to improve Debian-Ubuntu relations but so far it looks
> like Debian doesn't want to do any work in adopting or helping to
> adopt changes back.

Huh? It's difficult to make such assertions, the situation are wildly
different from package to package depending on the maintainer and its

> Ubuntu over the years continues to improve the relationship by getting
> (redirecting) people into Debian development, but I yet to see debian
> maintainers pro actively keeping an eye on their packages in Ubuntu
> and merging the changes as they become available (and everyone does
> see the ubuntu box on their

This is just wrong. Many do.

> Majority of ubuntu developers have sid & squeeze pbuilders /
> cowbuilders. Do debian maintainers test their packages in ubuntu
> pbuilder before pushing the change.

That's not fair either, there is an upstream/downstream relationship
between Debian and Ubuntu.

And your claim of a majority of Ubuntu developers testing on Debian is
doubtful as well.

> Please give examples =) #debian-ubuntu so far has been very responsive
> and friendly platform for these discussions.

You will find the example at the very start of this thread.

Raphaël Hertzog

Like what I do? Sponsor me:
My Debian goals:

More information about the ubuntu-devel mailing list