No subject

much as we can.

Finally, we'll add the ubuntu packaging history, again, preserving as
much as we can.

Depending on the packages, the priorities between debian and ubuntu may
change, but the idea is that the upstream history is the most important
if available, the packaging history (in the VCS meaning) having not been
preserved until now (or if it has, we'll preserve it).

4) Daily builds

mini-grumpy/package of the day seems to be called daily builds here so
I'll stick with that from now on.

It has been clearly said that the idea here is to:

- get upstream tip,
- add ubuntu packaging without *any* patch
- make it work

This clearly means the packaging information should be kept separate
from the patches themselves as best as possible (there are known cases
where that's not possible, hence the 'make it work' vague definition :)

But in turn, that mean we may want to keep the packaging in a proper
thread and have a final thread where we merge both the patches and the
packaging thread.

That doesn't mean that building stable branches (the one released in
Ubuntu) is not interesting, but that will come later.

Keeping all these threads properly used and ensure the commits always
happen in the right one is certainly the most important challenge
here. We don't strictly need that, at the cost of lots of merges that
may be uninteresting to the user. So we can start without that but then
we'll probably need ways to filter out the history in various ways when
presenting various parts of the history to the user (upstream history,
packaging history, both, etc)

5) packagers

Many of the packagers I've discussed with so far are already using the
source package branches when available and say they are happy with what
already exist.

Packagers are extremely busy at UDS

While I repeat everywhere I can that the bazaar team priority is to help
the Ubuntu packagers in the coming months, I haven't been able to
discuss with as many people as I wished.

So if you feel concerned and are at UDS, feel free to contact me[1] !

6) Use cases not mentioned so far

An interesting variation of the daily builds has been discussed in the
'qa-lucid-fixing-bugs-with-patches', while this is not directly related
to the packaging stuff, I think it's worth keeping in mind.

Not all patches may lead to a build, but certainly some will and helping
the people involved to test their patch and send it upstream is
certainly not that far from our current objectives.

changelog merging is an issue often mentioned, it certainly shares some
aspects with our NEWS conflicts and a specific merge algorithm could
certainly be found here (bzr core should provide the necessary hooks for
that at least).

Various tweaks have been mentioned around lp: branches usage:
- aliases for lp:debian/testing/package to lp:debian/squeeze/package

- better heuristic for directory names when using co/branch (i.e. some
  users would like bzr branch lp:ubuntu/karmic/package to create a
  'karmic' directory not a 'package' directory), some will prefer
  ubuntu/karmic there too)

Packagers want to know, for a list of packages, whether there is debian
changes waiting to be merged.

I'll provide more feedback as I keep talking with packagers,

     Vincent

[1]: Or james_w or jml or dhollbach or slangasek who will be able to
find me ;)