Creating an Ubuntu remix is a big effort that requires the orchestration of a lot of small pieces. Many users assume they want to create a project or distribution to manage this, but neither can manage all the pieces. I recommend using a Project Group to manage the unique parts of the remix, and a team with a Personal Package Archive (PPA) to define the unique and common parts that are published.

Let me state first that while this scenario does describe what many call a derivative distribution, Launchpad does not provide all the features you want in a distribution. Ubuntu is the only distribution that has packages built by Launchpad. While you could have a distro whose series parent is an Ubuntu series, your distro will have no source packages, binary packages, or mirrors. The archive management tools are exclusive to Ubuntu. Translations are also exclusive to Ubuntu. This is not out of selfishness, it is just a matter of fact that these seminal services were built for Ubuntu, and extending them to support other cases is a lot of work.

You can use other Launchpad features to accomplish a remix. This practice was discovered through trial and error by users. It also reveals that in most cases, users really do not want a Launchpad distribution, because they have original work that that stands on its own.

Launchpad Project Groups are a way for a community (a team) to control several projects. The Project Groups drivers are automatically project drivers, allowing a team to plan releases across several project are once. Project Groups allow you to see a unified view the series and milestones on the sub projects.

Your projects represent the original work that makes your remix special. The original work for a project is the code, artwork, and documentation kept in the series branches. The team that owns the Project Group should also be the owner of all the Projects [1].

Most remixes need one or more projects that provide new art for boot, login, and desktop themes. Some remixes want to provide packages for projects that are not in Ubuntu yet, so they maintain a mirror of the code in a Launchpad project [2]. Some teams are using Launchpad to host their projects--it is pretty common for a team to build specialised tools then decide to distribute them using a live Ubuntu ISO as a base.

Many teams choose to create a project to represent the meta-package that controls the default mix of packages. This is an ugly hack, and the explanation deserved more than a footnote. Since the meta-package project does not produce something that a user or system runs, it does not deserve to be a project. Launchpad projects permit communities to share code, translations, etc--these projects do not have much to share. The branch that holds the code (/debian directory) of the meta package could easily be in a personal branch [3], but that prevents the team from sharing it between themselves. A project is the better choice in this situation.

Here is an illustration of the common way to set up a Project Group that distributes its packages

ProjectGroup -- owner Team -- PPA
|
+ Project1 (original artwork)
|
+ Project2 (no Ubuntu package)
|
+ Project3 (team is the upstream maintainer)
|
+ Project4 (meta-package hack)*
.
.
.

The team needs an archive to distribution its original packages and updated Ubuntu packages. Any team can create a PPA from their profile page on Launchpad. Team can dput their packages to their archive and Launchpad will build them. Users can add the PPA to their sources list, install the meta-package, and get all the packages in the remix in a single install.

Many teams want to create custom versions of Ubuntu packages. The simplest way to change a package is to get the source, add a patch, then dput it to Launchpad, but you then need way to manage that patch. An alternate way to so this is to use a source package branch. Every Ubuntu package has a branch that contains the source code, debian packaging rules, and patches to build the packages. You can usr bazaar to pull a copy of a branch, make your changes, then push them to your team's location. Launchpad beta users are testing a new feature called recipes. They allow you to describe how to merge and nest several branches to create your source package and dput it to Launchpad.

This kind of problem also explains why users and teams own archives, not projects. The archive contains packages derived from the Project Group, from other Projects that are not packaged in Ubuntu yet, and modified packages from Ubuntu. The team's archive is a single source that provides a diverse set or packages. The team is not the owner of the projects it packages, and it does not need to be to distribute them. Other users and teams can reuse your branches to make their own remixes. Your change may make their way into Ubuntu.

[1] Any user can make a project be a part of the Project Group you control. This is a bug. Control and affiliation are conflated in Launchpad and this needs to be fixed.

[2] You may not want to make mirrored projects a part of your group because you would be happier if someone else managed it. You can always make someone else the maintainer if a volunteer appears.

[3] Since projects are shared. there is no such thing as a personal project. You do not need a project store your personal branches. All Launchpad users have a location to keep non-project branches, but I have never seen a Launchpad page tell me about them :( Also "+junk" implies the branch has no value, which is wrong...it is versioned and public, of course it has value, it is just not a source for a project :( See https://help.launchpad.net/NonProjectBranches