Managing Divergence

[Reinhard Tartler]

Hello fellow MOTUs,

I hope you enjoyed a merry Christmas, and will have a great start in the
new Year. This mail contains some thoughts I had the last days, but I
think they are rather important, and so I'd like to share them with you.
I'm sorry that this email got rather length, I'd suggest you take
yourself a beer or a coffee in advance ;)

When going through my uploads to dapper, I noticed that quite some
packages I touched are diverged from debian unnecessarily, so they
could/should be fixed by requesting a sync the next time an upload
appears in debian.

What do we actually do in universe? Mostly, we are managing Divergence
from debian. Sure, some of us do have some pet packages which they care
of, and some of us are even DDs, who do work in debian on the packages.
But most of the work is divergence. Lets summarise some types of
divergence we have in ubuntu:

      * Unneeded divergence (can be synced on next debian upload)
      * Different Default Python (debian has 2.3, we have 2.4)
      * Newer Xorg (some build deps needs to be changed, most notably
        libgl)
      * different Kernel
      * other kind of build depends need to be changed
      * init.d file lsb conformity
      * new upstreams
      * Desktop file added
      * Random Bugfixes
      * amd64 related
      * Packages not in debian (yet)

I hope I didn't miss too much, but you get the idea. There are several
kinds of divergence, some can be fixed in debian and some rather not.
With random bugfixes and .desktop files I made good experiences with
filing whishlist bugs to the debian bts, so I think it is a very good
idea to do this.

Since this is the core of our work what we do, I think we should
classify the diverged packages in our universe. I imagine a wiki page,
where we can mark and register what kind of divergence a given package
has. We should also note "unneeded diverged" at the top of the list, so
that this can get an easy merge (just request a sync). This task could
be done automatically in the best case.

But also the rest of this classification is useful. Imagine what happens
when e.g. debian switches to python2.4. Then we need a list of all
packages, which we touched because of our python transition, most of
will be most probably just synced. But having that list in advance is
really useful. The same applies to other categories (like xorg) as well.

There are other kinds of divergence, like specific diffs because of our
kernel or the new Packages that we accepted through REVU. These packages
do cause quite some work in maintenance. In oder to facilitate these
maintenance work, I'd propose that we could establish a MOTU svn
archive, so that we can manage these packages via svn-buildpackage.
Since we don't have real maintainers I think a common archive would be
most appropriate. For my own packages, I maintain them in my private svn
repo, but I would have no problem in putting them in a semi-public MOTU
svn. I beleive that others think the same.

I hear you crying why svn, and not bzr. Well, there are some (IMO)
technical reasons against bzr. First, there is no bzr-buildpackage and
bzr-inject yet. Second, we need a central, authoritative place where all
works goes to, so that we get notified as soon as someone commits
something new. svn offers this, bzr not.

Anyway, I think tiber should have enough resources left for hosting such
an archive. Authentication via htaccess files, so that we can hand out
access to that svn even to some of our MOTU hopefuls.

Puh, this was a rather lengthy mail for just some thoughts, well, happy
discussion after new year. 

PS: I won't be available the first week in January, please don't break
revu and/or tiber when I'm snowboarding ;)

-- 
Reinhard Tartler <siretart at tauware.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-motu/attachments/20051230/69ae3ad2/attachment.pgp