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