On Tue, 30 Oct 2007 11:05:08 +0000, Matthew East wrote:
> Hi there,
>
> Further to a quick exchange I had recently with Christian on irc, I'd
> like to seek advice about the best way to structure the Ubuntu
> documentation project on Launchpad.
>
> The current structure is a bit of a mess. We have these two projects:
>
> https://edge.launchpad.net/ubuntu-doc - main project
> https://edge.launchpad.net/ubuntu-docs - historical umbrella project
> created for reasons unknown ;)
If it turns out you do not need the ubuntu-docs project group, you
should probably request that it be deleted, to prevent confusion.
There is already another project in this group: jubuntu, which looks
like driftwood, since it contains nothing (no code, no bug, etc.) and
if it did, should probably be a distribution instead of a project.
> We have bugs on the first project, but also on Ubuntu in the various
> ubuntu-docs, kubuntu-docs, xubuntu-docs and edubuntu-docs source
> packages.
>
> We have code on the first project, and we intend to have one main
> branch for each source package we produce in Ubuntu. So ubuntu-hardy,
> kubuntu-hardy, xubuntu-hardy and edubuntu-hardy. Note that the
> branches we have are intended to work as source packages: i.e. they
> have debian directories and we intend in the future (to the extent
> this isn't already true) to make them buildable "out of the branch".
> There is a single team with commit rights to the various branches.
So your project is spread along two dimensions:
* Ubuntu series (feisty, gutsy, hardy, etc.)
* Ubuntu flavors (ubuntu, kubuntu, xubuntu, edubuntu)
To pick the best model in Launchpad, you need to understand how those
dimensions relate.
* Is work done one more than one Ubuntu series at a time? I'd imagine
the bulk of the work is done for the upcoming Ubuntu series, but is
the documentation maintained after the release? In other words, do
you only release development snapshots, or do you maintain multiple
divergent release branches?
* How do changes flow between flavors? Is the bulk of the
documentation work done the ubuntu flavor, with the other flavors
maintaining a delta and not being merged back into the the ubuntu
flavor? Is core documentation work done on all flavours with patches
flying around wildly in all directions? I guess it's the former,
because bzr does not support the latter well.
> Translations are done in Ubuntu under the source packages.
>
> The Ubuntu Documentation Project is not really an upstream project at
> all, but in fact just works within Ubuntu. As such, logic would
> probably dictate that we work on Ubuntu source packages only. However
> my understanding is that there is no infrastructure in Launchpad to
> enable us to host code or have close control of bug permissions
> without an "upstream" project.
I believe such packages are called "Native packages" in Debian
parlance. They are a bit of edge case. The Launchpad model for native
packages is to have an "Upstream project", even if the people behind
the projects are the same as the people behind the package.
This seems a bit heavyweight at first, but it takes all its meaning
once you start interacting with derived distributions. To any derived
distribution that includes your, the ubuntu-doc project is effectively
an upstream.
Similarly, Ubuntu packages which are native in Debian have an "Upstream
project" in Launchpad. This project is intended as the place of
interaction between Ubuntu and Debian for this package.
> I'd be grateful for people's feedback on that point alone, but
> assuming I'm right, then on that basis it seems to me that we need to
> work with an "upstream" project that is closely associated with the
> Ubuntu source package. That's particularly important for bugs, which
> we get in both places, and translations, which we get in the Ubuntu
> distribution location.
There is a very old bug open about displaying in project context the
bugs on packages that are associated to the project.
https://bugs.launchpad.net/malone/+bug/3152
I am not sure what is the best way for you to manage bugs and
translation at the moment. I hope the experts of those subsystem can
answer your request.
> The next question is how to structure this project. I noticed recently
> that there can only be one mainline branch associated with each
> release series. As a result, I think we could have either of the
> following structures:
>
> * One release series per source package per Ubuntu release cycle.
This would be appropriate if packages are maintained after the Ubuntu
release and you do not need fine grained tracking of which flavours
bugs occur into.
> * One project per source package with one release series per Ubuntu
> release cycle (with an umbrella project to link them together).
That sounds like the most accurate model. It allows you to track in
which flavour each bug occurs, and should enable all of launchpad
features.
Effectively, it models each package as a fork. It might be too much
overhead to maintain.
> * One project, with one release series per Ubuntu release cycle and
> simply not bother associating all the branches with the release series
> (i.e. as the ubuntu-doc project is now).
This is not ideal. In particular it prevents you from recording
accurate links between upstream release series and ubuntu source
packages.
> * Other?
You could have one project, with one release series per source package,
where the series branch contains the package under development (at the
moment, hardy for the ubuntu flavor).
This would be appropriate if source packages in each distribution
series are not significantly updated after the release of their
distribution series.
> Any opinions on which of these is better? I tend to associate release
> series with time based releases so if that is right then perhaps the
> first option is less attractive. But the second option seems pretty
> high maintenance.
Upstream release series are intended to model large projects that have
multiple active branches, such as PostgresSQL, Apache, Zope, or Python.
Such projects have at least one branch that is the main development
focus (for which the conventional name in Launchpad is "trunk"). When
release time come, this development branch spawns a stable branch that
only receives non-disruptive changes. Often, multiple stable branches
are being actively maintained and produce parallel releases.
In contrast, in your typical small-to-medium free software project,
there only one active branch that produces releases. When release time
approaches, the branch is "frozen". After a release, the branch is
thawed and past release are not maintained. The Launchpad model for
such project is to use a single "trunk" upstream series.
Many projects choose to use releases series for other purposes. You
do not have to be limited by the intent of the authors of Launchpad.
--
-- ddaa
Attachment:
pgpLIygVLSyma.pgp
Description: PGP signature
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)