On Mon, Mar 21, 2005 at 07:29:24PM -0800, Thomas Bushnell BSG wrote: > Matt Zimmerman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]