Ubuntu Wiki

This page is to discuss the merits of different possible mechanisms for the client tools to use.

There area two main questions, possibly without clear answers:

• New tools, or modifications to existing ones?
• Structured workflow or freeform.

Let's consider the questions in that order.

New tools?

• There will be a pure bzr interface to do everything, for instance "bzr branch lp:ubuntu/gcc/hardy/updates",
  • but we probably want to provide wrappers to this as well, for a couple of reasons: - Provide simple tools that you can learn ignoring all the power of bzr. - You could hide bzr, so that you don't have to know you are using it. - It may be possible to make the wrappers more "helpful"
    • - I don't know if I really mean that one, I can't come up with a situation that isn't just command line differences, which may be enough. e.g. "get-source gcc hardy-updates" for the above.
• We already have tools that do some of the steps, "debcheckout", "debcommit", "debrelease". It would be possible to make them do whatever is necessary to support the new workflow.

Advantages of using the existing tools.

• Familiar to developers. They don't have to work against muscle memory.
• It feels like we are changing things less.
• Existing documentation may still be relevant.
• We may end up with less of a process delta from Debian.

Disadvantages of using the existing tools.

• Any behaviour changes can cause problems.
• Options to get the old behaviour would probably be provided, meaning more code paths.
• We would probably carry a permanent diff to Debian.
• Some people running Ubuntu contribute to Debian as well, hampering them in that work would be bad.
• Any behaviour changes may lead to existing documentation being wrong, with no easy way for the user to detect this.
  • - A simple case would be documentation telling the user to use debcheckout, when they are on hardy and don't have the one that understands the new layout. While we can provide backports/ppa the user must enable them. It fails open. If there is a new command then it either works, or it doesn't and they need to find the new package. This fails closed.
• We must maintain this over time. We don't know how the existing tools may evolve, so while the interface may fit now, it may not always.

Problems with either approach.

• Users on old releases will need to use backports/ppas. While they are probably more than capable of this if they are after the source, it's still a pain.

The third way

• As debcheckout gets it's information from the packages files we could ensure that every package file contains the right information, so that debcheckout works seamlessly. However, there are somethings that a new tool could do, such as getting you the package from dapper-proposed without having it in your sources.list, that debcheckout can't. It would also increase the size of the Packages files quite a bit (and we would want to keep existing entries prefixed with Original- or similar to provide the compatibility mode).
• This approach is even harder for the other tools, as there are a couple of very specific things that are done for the new scheme (such as setting a particular tag when uploading) that mean code changes would be needed.

I therefore don't think this scheme is workable.

Conclusion

• The above discussion leads me to think that modifying the existing tools isn't the way to do, so new wrappers should be created to do what we want.
• We should ensure that these are available for all supported releases in a timely manner, and that the documentation is very high quality, as new tools mean learning new things.