The second installment of Developer News went out on Monday, and boy was it hard work. It's great to see so much going on, but it does make preparing the summary time consuming. Thanks a lot to Stefan Lesicnik for his help in preparing this one. As well as having more to report I also broadened the intended audience this month.

For the first month the intended audience was just Ubuntu developers, so I didn't include anything from ubuntu-devel-announce, as I assumed that everyone would already have seen those announcements. The first issue was picked up by both the fridge and LWN though, so it was more widely read, and showed there was an interest in having more news for external people. Therefore I wrote this edition to include those people as well.

I'm pretty sure that there was plenty more that we could have included as well, it's just I didn't know about it, or there was nothing to link to. I think we need to do a better job as a community to communicate what we are doing. My process was simply to trawl the archives looking for announcements and discussions of things, so all anyone had to do was write one email.

Therefore I think we have two problems to solve, firstly getting everything that is going on announced in the right places, and secondly making it easier to summarise all of the activity.

I hope that the first will become more a part of our culture, and the Developer News will help by getting more exposure for those who do communicate about what they are doing.

I'm not too sure how to improve the second though. We have a defined process for submitting items for the news, but to date there have been no submissions using that process, and one submission by editing the wiki page as I was preparing the second issue. Why is this? Why have you not submitted anything? Is it that you didn't know about the process? Is it too much work? Is it that you never think to use it? That you are not sure that your item counts? That you are not sure that someone else hasn't alread submitted it?

The feedback I have got about the Developer News has been both frequent and entirely positive, so I believe it is a valuable service that should be carried on, but I fear that the current way of doing it won't really scale. I don't think it would be worth a day of my time a month to complete it.

Any suggestions for improving the situation would be appreciated.

Please consider the following hypothetical situation. gnome-screensaver keeps crashing for people on Jaunty, which is pretty annoying, so it sends lots of people to Launchpad to report a bug.

It's pretty quickly established by the amazing desktop team triagers that it's actually a problem in Gtk+, so they duly reassign the bug there.

However, it's a little while before the fix is forthcoming, and it that time many users are still getting hit by the bug, so they are still heading to launchpad. As most of us aren't Gtk+ hackers we don't see that the issue is there, so we go to the obvious place to report the bug, the gnome-screensaver package, and not seeing any existing reports about the bug we file a new one.

This means that the desktop team has to spend time shovelling the bugs over to Gtk+ and duplicating them to the first one. While we have some tools to help with this sort of thing it would be great if we could try and avoid it all together.

One way this could be solved in Launchpad is to leave a task open on the gnome-screensaver package, but this isn't ideal, as the bug doesn't need to be fixed there. You could mark a gnome-screensaver bug on the package as Invalid, which would make the dupe search as you report a bug show it, but it wouldn't show up for those that just trawled the open gnome-screensaver bug reports looking for the crash.

My idea for something that would help in this case is Ghost bugs. These are bugs that are the ghosts of a bug somewhere else. In the above case a ghost bug could be created against gnome-screensaver pointing to the Gtk+ bug. It would then show up in the bug lists, but not have a status etc., and be somewhat "greyed out", hence the name ghost bug.

As the bug affects gnome-screensaver it makes sense for it to show up against that, but as it doesn't need to be fixed there it shouldn't have the rest of the information.

It doesn't just work for packages. See for example launchpad bug #174539. This is a bug that should be fixed in bzr, but it only manifests itself in bzr-builddeb. I am keeping a task against bzr-builddeb so that it shows up in my list to fix to have bzr-buiddeb work great, but I don't really need a status as nothing needs to change in bzr-builddeb for it to work.

With Launchpad having the concept of bug tasks this could be easily done by adding a new status Ghost, or perhaps Fix Elsewhere or something. This would be handled differently to the other statuses, giving behaviour such as that I described above.

Having a whole bug task may not be the right thing though. It could instead be a separate list, similar to the list of bug tasks, but just listing the things that should have ghost tasks.

Does anyone else think this would be useful? Is there prior art?

Mr LeSage, I just happened to run bzr plugins today, and noticed this:

.
.
sandwich
    (no description)
.
.

Curious as to what the hell that was, I ran the command again with -v and saw that it was installed in my ~/.bazaar/plugins/ directory. I opened the file and found this that I wrote a few months ago:

from bzrlib.commands import Command, register_command

class cmd_make_me_a_sandwich(Command):

    def run(self):
        self.outf.write("What? Make it yourself.\n")

class cmd_sudo_make_me_a_sandwich(Command):

    def run(self):
        self.outf.write("Okay.\n")

register_command(cmd_make_me_a_sandwich)
register_command(cmd_sudo_make_me_a_sandwich)

Not quite what you were after though. That would be this plugin:

class SandwichCommand(Command):

    def run(self, **kwargs):
        for name, arg in kwargs.items():
            if arg != name:
                self.outf.write(self.fail_message + "\n")
                return 1
        self.outf.write(self.success_message + "\n")
        return 1

class cmd_make(SandwichCommand):

    takes_args = ["me", "a", "sandwich"]
    fail_message = "Make you a what?"
    success_message = "What? Make it yourself."

class cmd_sudo(SandwichCommand):

    takes_args = ["make", "me", "a", "sandwich"]
    fail_message = "Of course, but what do you want me to do?"
    success_message = "Okay."

register_command(cmd_make)
register_command(cmd_sudo)

I'm still none the wiser as to why I wrote that plugin in the first place though.

I spent today hacking on bzr-builddeb for the first time in a while. The first order of business was to review and merge all of the proposed merges in launchpad. Thanks especially to Jelmer Vernooij for all his work.

After that I tackled a long-standing annoyance in bzr-builddeb. This limitation made it difficult to pass extra options to the underlying build command. For instance, when building a merge you must use the -v option to debuild. Previously this meant that you would have to run something like:

$ bzr builddeb -S --builder "debuild -S -v0.1-1"

Using the tradition of -- to end option parsing this now becomes:

$ bzr builddeb -- -S -v0.1-1

which is much better.

The -- isn't exactly obvious, but it does mean that I don't have to implement support for every option of dpkg-buildpackage.

It may be possible to add support in bzr to make this work without the --, I haven't looked yet, and the current implementation doesn't prevent us from doing that.

One other thing I did was to make the build command default to debuild, rather than dpkg-buildpackage -rfakeroot -uc -us, so that we get all the debuild goodness. The obvious change here will be that it tries to sign the package when you build. You can define your builder to be debuild -uc -us to avoid this.

One last break was to remove support for source-builder from the configuration. It now assumes that adding -S to the build command will make it build a source package.

Comments on any of this are welcome.