Tools

bzr-builddeb vs. debbuild

<dholbach> james_w: "     * Ubuntu packages: A package-ubuntu branch containing the tree on disk that 'debuild' is able to be invoked on. "
<dholbach> where is bzr-builddeb in the scenario?
<james_w> it's not necessarily
<james_w> debuild -i should be sufficient
<dholbach> OK
<dholbach> maybe I should read the page to the end :)
<james_w> I don't think it states that explicitly

Branch Layout

More Debian branches

<dholbach> it might be worth adding $PACKAGE-debian-experimental and $PACKAGE-debian-experimental-orig to the list (not urgent though) - shortcuts for the tools for would be nice too :-)
<dholbach> also $PACKAGE-ubuntu-gutsy and $PACKAGE-ubuntu-gutsy-updates etc
<dholbach> it will be a hell of a lot of branches

"Packaging Branch"

<dholbach> maybe we could also avoid the term "packaging" branch so people are not confused by what currently debian maintainers do (just store debian/ in VCS)
<dholbach> "packaging branch" I meant

Lightweight Branches?

<dholbach> are we going to use "lightweight branches" or however they are called?
<dholbach> daniel@bert:~$ du -sh bzr/ubuntu-docs/
<dholbach> 500M bzr/ubuntu-docs/
<dholbach> daniel@bert:~$ 
<dholbach> ^ that's a good example of what will piss off people :)

LP Interaction

Updating Upstream VCS links

<dholbach> in the case of upstream branches: how are we going to avoid having to update LP whenever upstream "branches gedit for gnome 2.2{2,4,6,8,...}"?

Planning

Moving Forward

<dholbach> it'd certainly help to have a few use cases: "seb128 updates gedit to new upstream version and has to adapt a patch of ours", "doko does a fire and forget upload", "pitti runs the sync script on drescher", "jono files a sponsoring bug, dholbach in fear of his job instantly works on it", etc and line out what people would type in or have to script and then file TODO bugs from there

<james_w> Perhaps I should spend some time converting one package to be completely in bzr, so that we can show that off.
 as in upstream, Debian and Ubuntu.
<james_w> even if it's not used I can come up with the hypothetical situations and show how they would work.
 gah, if we didn't have to release I'd have loads of time to do it.

Bug Tags

<dholbach> james_w: maybe you can use a tag for all the bugs on bzr, bzrlp, devscripts, etc etc so you have a TODO list of stuff handy
<james_w> yeah, I think I'll do that.
<james_w> I don't think I'm ready for filing bugs yet though.
<dholbach> james_w: this is going to kick ass - I just know it
<dholbach> james_w: once you start about use-cases and what people need to type in, you will have a lot of fodder for bug reports :)

Phase 1

Problems

• DanielHolbach

  • In the case of fire-and-forget uploads (not using bzr at all) who is going to take care of updating the bzr branch again?
  • How does the merge request process work? Is there an overview of all merge requests of Ubuntu?

Documentation necessary

• DanielHolbach

  • at least PackagingGuide/Recipes should all have their bzr equivalents documented

  • merging features from upstream branches is one of the big selling points (even if it's a manual process of setting them up in LP)
    • how often are they updated?

UDS Discussion 1

• Number of branches: will increase over time, but will probably start small.
• Launchpad needs to scale better to handle the data we will want to throw at it.
• Package branch owner shouldn't be part of the URL.
• Branch naming:

  • <distro>/<package>/<release> <distro>/<release>/<package>

  • - Not all packages are in all releases. - Individual's branches

    • ~<user>/<distro>/what?

    - - Need a branch per-pocket.

Go Back to DistributedDevelopment/Specification.