Bazaar Sprint report: Day one

Ian Clatworthy ian.clatworthy at canonical.com
Thu Nov 12 21:04:28 GMT 2009


Aaron Bentley wrote:

> I'm reporting from the Bazaar sprint in Mooloolaba, with a focus on
> ubuntu distributed development.

Thanks for such a detailed report.

> Jonathan continued discuss our strategy of making Ubuntu the best
> possible conduit between upstream and users.  Proto-grumpy would make it
> easier for users to try out the very latest version, so that upstreams
> can get better bug info, and would in turn feel good about Ubuntu.

> Ian Clatworthy spoke about how it was too hard to find PPAs, and how we
> need visibility into the things we care about.

I would like to go to the Branches page for a Launchpad project and see 
a PPA icon next to packaged branches, e.g. trunk. Clicking on that icon 
would give me instructions for getting that package via Software Centre, 
Synaptic or apt-get. Together with a streamlined 'branch => package' 
toolset, that would help:

1. Upstreams advertise their PPAs
2. Users test against trunk before reporting bugs.

> Robert noted that upstreams are discouraged from
> doing packaging, and feels that this is wrong.

Me too.

> We should upstream as much as we can, but upstreaming stops at
> packaging.  Ian suggests this hurts our ambition for "world domination".

By world domination, I mean fixing "Bug #1". We need to make it dirt 
simple for upstreams to deliver their software on Ubuntu. If upstreams 
are discouraged from learning packaging, then the packaging team becomes 
a process bottleneck. PPAs help that problem enormously IMO.

> We discussed componentizing bzr further, e.g. using testtools, splitting
> Bazaar's command stuff out.  Ian said "partitioning is the most powerful
> tool for driving quality up".

Martin also asked "where does componentisation stop?". I've been 
pondering that and here's my answer. Accordingly to Domain Driven 
Design, any sufficiently large system ought to have a layered 
architecture something like this:

* Application UI
* Application services
* Domain objects
* Infrastructure

Where you can, you should use 3rd-party stuff for the Infrastructure 
layer or make logical parts within it separate projects. It's a bad idea 
to break stuff in the higher layers into "spin-off projects we depend 
on", although it's still a good idea to partition vertically within each 
layer where you can.

The other interesting property about that 4 layer architecture is where 
casual contributors make it most impact. In my experience, they do a 
great job of extending the top and bottom layers but get lost quickly in 
the inherit complexity of the middle layers.

Ian C.



More information about the ubuntu-distributed-devel mailing list