Re: Ubuntu Patches
On Mon, Mar 21, 2005 at 07:29:24PM -0800, Thomas Bushnell BSG wrote:
> Matt Zimmerman <mdz@debian.org> writes:
> > The only distinction here is between merely publishing the patches on our
> > website, and pushing the patch to the Debian maintainer immediately. We
> > publish all of our patches relative to Debian on a regular basis, and make
> > an honest effort to sort and separate them to the extent that this can be
> > automated.
>
> Um, so these patches, are they bugfixes?
Some are bug fixes, some are enhancements, some are Ubuntu branding,
some are a result of different policy decisions (e.g. "the desktop
should look this way"), etc. The last two, for instance, would typically
be noise as far as Debian's concerned.
In the case of bug fixes that we found out about due to an RC bug that
we imported from debbugs, we have a clear policy that we should push
them back. Others are left up to the judgement of individual Ubuntu
developers, but still do often get pushed back when time and sense
allows.
To try to clarify why it doesn't seem to make sense in practice to have
a simple policy of sending back all patches, I'll take the example most
familiar to me. My Ubuntu installer changes roughly divide down into the
following categories (and this is a slightly unusual case since I have
commit access in both Debian and Ubuntu, I guess, but bear with me):
* Ubuntu branding. Enormous patches due to having to update .po files
as well, and really not very interesting to anyone, but it has to be
done. (Making this easier for people to do, somehow, would be nice;
I estimate a few man-weeks of largely tedious work to produce a
fully custom-branded and translated installer from scratch at the
moment. Handling branding and translations in the d-i manual is a
particularly thorny and unsolved problem.)
* Deliberately different distribution policy. For instance, Ubuntu
assumes a single CD, patches out some installer questions as a
result, and does stuff like copying desktop packages to the hard
disk in the first stage so that you can ditch the CD altogether
after the first reboot. Doesn't make sense for Debian, at least not
unless we can figure out a way to make this switchable at a high
level in the installer build process, which isn't easy. I'm more or
less resigned to carrying these patches for a long time. Since
debconf questions are asked programmatically, patches to change
question structure can often be larger than you might expect (c.f.
partman-auto, base-config).
* Accelerated changes due to different schedules. For instance, Ubuntu
assumes a 2.6 kernel, and now the installer uses hotplug and udev
rather than discover and devfs to match this. I made all these
changes in such a way that they could be merged back to Debian with
suitable conditionals, so that even if Debian e.g. doesn't want to
use hotplug in the installer, it should be switchable by a small
change in the debian-installer build process. However, with d-i
largely frozen for sarge and these changes still highly experimental
until recently, I didn't want to merge them back yet. I intend to
land them after sarge when large d-i development work is more
appropriate; but that didn't change the fact that we wanted to make
the change for Ubuntu on our own schedule. (Life is so much easier
when Debian isn't in a freeze.)
* Generally-applicable bug fixes. Often I just apply these with my
Debian hat on, because it's less work all round that way: I have a
less complicated patch to merge, and some d-i hacker doesn't have to
run around applying my patches even though I already have commit
access. Sometimes code is already divergent due to freezes or
whatever, and I just have to apply it in both places. Sometimes I'm
in a tearing hurry because we're doing a release the next day and
have other priorities as a result, and this is where bug-fix patches
are most likely to fall through the cracks due to human error;
fortunately we have the Big Pile of Patches to refer to, thanks to
Scott, and I can go through when things are less busy and try to
sync up.
* Generally-applicable new features. The installer isn't somewhere
where you find a lot of these any more, and there's only so much
code that one person can write, but there are a few. In the case of
rescue mode, after answering a couple of dozen similar questions
from Ubuntu users I was interested enough in it off my own bat to go
off and write the bulk of the code in my spare time, commit it to
the debian-installer Subversion repository, and then merge it into
Ubuntu for more general testing, which worked fairly well. I've yet
to decide what to do about Kickstart support, which is very new,
lightly tested, has a fair bit of Ubuntu-specific code in it, and
includes at least two very scary hacks about whose correctness I'm
uncertain. :-) It'll be easier to consider this post-sarge.
* Stuff I'm unsure about. #268425 was a good example: we needed to do
something to stop the Ubuntu installer behaving weirdly, and it
seemed that it would be more generally applicable, but I wasn't sure
if my patch was correct. File a bug and move on. Some of these may
have slipped through the cracks until the next not-so-busy time as
well, if I was particularly unconvinced that my change made sense.
* Trivial changes. Frankly I'm not interested in extra merge effort
due to an Ubuntu patch for a spelling error, so I generally just
make these in Debian directly as I notice them and only hurry the
merge to Ubuntu if they're user-visible.
I hope this helps to clarify things a little. It's a huge job, but we
are trying to do what we can, and to improve the general visibility of
changes.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: