Proposal: multiple binaries, one source package

[Matthew East]

Hi,

2009/4/2 Cody A.W. Somerville <cody-somerville at ubuntu.com>:
> Matthew has talked a lot about working together and I think
> thats awesome. So why don't we really take things to the next level and do
> something that will actually assist us in doing just that - multiple
> binaries, one source package.

Thanks to Jim for the detailed analysis of pros and cons with this.
I'm just going to add some thoughts of my own here, without trying to
be exhaustive.

1. To start off, I think it's a laudable aim to share as much material
as possible.

2. Up until the hardy release, ubuntu, kubuntu, xubuntu and edubuntu
documents were contained in a single repository. We didn't generate a
single source package, but that was just due to laziness, we could
have done so had we so wished. So the proposal is essentially to
return to the previous setup, and add the capacity to build multiple
binaries from a single source.

3. For that reason, it's important that we go back and look at the
reasons that we moved to separate branches in the first place. I've
managed to find these two emails (and follow up responses), although I
think there were probably others as well:

  https://lists.ubuntu.com/archives/ubuntu-doc/2007-August/009160.html

  https://lists.ubuntu.com/archives/ubuntu-doc/2007-September/009383.html

4. The main advantages of separate branches are that they are quicker
to check out, and that contributors (whether documenters or
translators) can contribute without necessarily being 100% familiar
with all the relevant desktops. I would envisage serious confusion for
translations in particular if we are publishing a common template for
material which covers different desktops, because translators will not
necessarily be familiar with how different desktops behave, and in
some cases it may not be clear to which flavour a particular string
belongs.

5. If we do try to have the documents in a single source package,
there are two ways to do this. One is to have the documents for each
flavour in a separate sub-directory (which is how we used to do it).
That would not really give rise to any benefits over the current
system because the material would not actually be reused. The other
way is to try and build documentation for different flavours out of
single xml source files. This is technically possible using xml, but
would require a hell of a lot of work. It would mean that each section
of documentation would have to be "tagged" as applicable to particular
flavours, and that the structure of the documentation and sections
would have to be the same for all flavours. Contributors changing a
particular string would have to work out whether that string was
applicable to more than one flavour, or just one, and act accordingly.
I think that would cause serious confusion, and it would also
constrain us to a single structure of documents for all the flavours,
which might not be practicable. As Jim pointed out, linking would also
be a major challenge.

6. One of the main reasons for moving to bzr was the strong merging
functionality that it has which permits us to merge material from one
branch to another. So if someone working on xubuntu docs spots a
change to an ubuntu document which is also applicable to xubuntu, it
should be easy to use bzr's merging functionality to merge that.
Equally, the libs and other common directories can be kept in sync in
the same way.

On that basis I'm in favour of keeping things the way they are now.
However, it certainly doesn't hurt to talk about improvements that
could be made.

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF