Notes from Bazaar sprint, Tuesday

[Jonathan Lange]

0800 -- Call w/ James Westby
============================

Discussing stories about ubuntu-distributed-development.

Q. What's the top priority?

A. Mini-grumpy; branching existing packages; submitting diffs upstream.


Q. We're worried about whether this will be too simple and that people will
never graduate?

A. Not worried about graduating. Worried about two distinct communities with
no intersection. Competing communities also a worry.


[Editor's note: the question should have been:

Q. We're worried about whether the mini-grumpy / recipe stuff will be too
simple and that people will avoid recipes because they want to do "real"
packaging?]


Q. What structure is Mark thinking of: a full grumpy that we've set up or a
collection of PPAs that coalesce?

A. Would like the former, but thinks the latter is more realistic. Former
requires lots of effort & _then_ selling. Second lets it grows naturally and
gives us the most useful bits first.


Q. No, but what structure will users actually work in.

A. Lots of PPAs. PPAs that chain one from the other.

It will probably work like the DX team set up currently.


Q. Why conflate bzr-builder style recipes and build-from-branch?

A. If we do both, we provide two UIs, two features, no way to switch between
one and the other. bzr-builder can do build-from-branch easily.

Rob's wants to be sure we use buildeb's pristine tar support etc. James says,
yes, of course.

Can't fully unify the two w/out nested trees in Bazaar.


Q. Why was the 'run' command in bzr-builder?

A. Mainly for autotools case. Need to run 'make dist' to go from VCS ->
tarball that has to be somewhere.


Q. bzr-builder seems fairly generic, it should be separate from buildeb.

A. Yes.


The package-of-the-day stuff (aka mini-grumpy aka proto-grumpy) is the focus
for Bazaar, and not "main" features. However, it's a loose focus, in that
Bazaar will still be doing bugfixes, ui improvements etc.


James Westby says we should talk about loom & nested trees this week, since
they are relevant to bzr-builder.


Q. What do you think about the interaction between our stuff (loom, builder
  etc) and other patch management in Debian?

A. It would be great if they could apply back and forward. Not possible to be
perfect, probably. New source package format helps w/ patches.


Q. It sounds like we (Bazaar) could do looms or whatever without thinking too
much about what Debian is doing?

A. Yes, I'm keen to tackle the translation problem.


Q. Any Bazaar bugs particularly painful?

A. None, except formats.


Q. Why is parallel imports nice to have?

A. Current imports only have tarball history. Want to have Debian VCS history,
want to have upstream history. We can do lots of this w/ rewriting.

  -> Actually, this is more than parallel imports. [Ask lifeless for more
     details - ed]

  James says that maybe nicer erbasing would be more useful. Apparently jelmer
  is working on this.

James says vcs-imports increasingly important.


Q. What do we need to do about it?

A. Timely, reliable imports.

We note that there's a data management problem and an infrastructure problem.
The data management problem is actually getting all of the imports into the
system and keeping them up-to-date. This is really beyond the scope of the
Bazaar team.

However, the infrastructrue problem is making sure all of these work and are
reliable -- this is very much within scope.

There are UI issues with imports. We should have an API for requesting an
import now and blocking until done. It should be easier to make an import.

Graph of time to satisfaction on code imports would be nice.

Other people to talk to: Scott; Colin; Matthias Güg



Breaking down package-of-the-day
================================

- Need elevator pitch
- Need to break down steps


Notes
-----

 * Capability-based format might be useful
 * Need to nest parts of trees
 * Restrict to Ubuntu, at least for now
 * Combine branches without shared history


"Mini Grumpy" is package of the day and community around it. This is not
necessarily the grumpy of old, but it's shorter to type.


 * Imports of trunks
 * Mostly LP code
 * Shouldn't silo teams
 * Need more data on failing imports

Should we do code imports at all?

 * We could have seeds given by others
 * The responsibility should be on a larger body of people
 * Make it easier for people to own
 * For grumpy, we need lots of branches.

What we want is a series of easily describable milestones.


What we'd like to dent when all this is done:

 igc: Happy that my project is in a PPA. Getting lots of great feedback from
 Ubuntu users.

 jam: I've fixed my pet peeve in Project X. Install the fix here:
 http://is.gd/p,p4heus

 lifeless: subunit 3 released, builds available now

 mwh: Fixed conflict stopping trunk merging into lazy-import pyflakes -- my
 PPA now has trunky goodness.

 spiv: Twisted nightly packages available at http://is.gd/hsaeoumvj3

 mbp: 1000 people now using bzr nightlies!

 abentley: Firefox without all the Ubuntu crap here: http://is.gd/34oahkjsueoa