Hi David,
First of all, thanks very much for the prompt and detailed response.
On 30/10/2007, David Allouche <ddaa@xxxxxxxxxxxxx> wrote:
> 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?
The main development is done on the development branches, but we
intend to do some work on release branches. In particular these will
include translation updates, and occasionally fixing substantial bugs.
> * 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.
Work on each flavour will take place separately in the relevant
branches, with any changes that are identified as relevant to other
flavours being merged as and when possible over to the other branches.
Some files are common to all the branches, they will be merged
consistently through all the branches for a particular series.
> > 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.
Ok, noted. Thanks
> 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.
Great, I'll wait for feedback from those people.
> > The next question is how to structure this project.
{snip}
> > * 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.
It sounds to me too like this is the most accurate model and I will
look into how difficult it is to maintain. It does sound like it might
be a bit of a struggle.
> > 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.
So as explained above, we've previously gone with the stable branch
approach. However, I suppose it would be possible for us to change
this approach, and go with the "small-to-medium" approach. In order to
do this we would abandon version control for any updates sent to
stable Ubuntu releases (translations or bug fixes) and just make ad
hoc changes to the Ubuntu archive for such things. This would simply
things, but might be a shame.
--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)