I was about to start this thread just this morning, but didn't have the time. Here is what I think: The Arch way is to keep things as untouched as possible and frankly, our kernel has become full of stuff that I don't see a reason for. * acpi-dsdt-initrd-v0.8.4-2.6.21.patch My opinion on this one is unclear: There have been tons of fixes to ACPI and the kernel developers claim that this patch should not be needed, as the Linux ACPI implementation is supposed to support everything out of the box. Right now, many people who needed a custom dsdt years ago, still use it despite the fact that they don't need it. However, there are _some rare cases_ where only a dsdt can fix the problems. The majority of computers however should now work without it. What I definitely don't like about the patch is that the ACPI subsystem has changed substantially since 2.6.21 - the fact that the patch still applies doesn't mean it doesn't introduce unwanted and stupid behaviour, or hidden bugs. None of us would know the problems the patch may cause, as none of us knows anything about kernel/ACPI code. * toshiba-bluetooth.patch What does this patch even do? It has been sitting there since .21. What is the reason this hasn't been merged upstream? 1) It breaks other setups, which would mean we should remove it, 2) it has been merged in a different way and still applies, in which case it will only cause bugs, but don't fix any, so we should remove it or 3) it has never been submitted, in which case it shouldn't be our responsibility to keep it along while the author isn't even capable of submitting it. In any of the above cases, we should remove the patch. * usb-storage-unusual-devs.patch I submitted this patch after I created it, so either 1) or 2) of the above apply, so we should remove it as well. * mactel-linux-2.6.23.patch What does this patch even do? There have been Macbook patches sitting around since .20 or so, and again: why aren't they merged upstream? Any of the reasons for them not being merged imply we should remove them. * http://www.archlinux.org/~tpowa/alsa-patches/alsa-20071109.patch.bz2 *http://www.archlinux.org/~tpowa/alsa-patches/alsa-include-20071109.patch.bz2 Why do we update alsa all the time, especially to non-released versions? This may have been necessary, when a large number of chipsets were broken, but I don't think that is still the case. Is there any specific reasons we cannot stick with the alsa version that Linux provides? * acpi-buggy-bios.patch Like mactel, this patch has been there since .20 or so, the ACPI implementation has had many changes, and it is more likely that it introduces bugs than that it fixes any. Again, this patch should be removed for one of the above reasons. squashfs3.2-patch.bz2 http://download.filesystems.org/unionfs/unionfs-2.1/unionfs-2.1.8_for_2.6.23... Why are none of these merged upstream? Why do we have to add features ourselves? I know we had problems with externally built unionfs, but adding it in-kernel shouldn't be the solution, especially because it results in more work maintaining. * put_filp.patch * lhash-2.6.22.patch I don't know what these are, but these seem to be new bugfixes. Still, it should be evaluated if they are still needed before they are added again in 2.6.24. * adjust_current_level_to_closest_available.patch This is a bugfix that has already been merged for 2.6.24. This is an example of how things should work. I discovered this bug on my notebook, posted to the right mailing list and got a fix, confirmed it and now it will be merged in the next version. So we only need to take the patch along until the next version, and can then drop it. hibernate-saa7134.diff How long has this been sitting here? Again, the "why hasn't it been merged" question should be asked, and the patch removed, most likely. sata_sis-2.6.23.patch ipw2x00-2.6.23.patch zd1211rw-oops-2.6.23.patch ide-helper-2.6.23.patch I guess those are new, so again, we can keep them until .24, but they should be fixed by then and our patches removed. * linux-phc-0.3.0-kernel-vanilla-2.6.23rc3.patch This is an extra feature. One that a small minority of people can use. It is said to be unintrusive, but then, why isn't it in the upstream version? If it is so unintrusive, the upstream devs shouldn't object to adding it. So either it was never submitted or it was rejected for a good reason. # genpatches from gentoo * 2405_hostap-netdev-type.patch * 2525_usb-storage-nikon-d200-quirk.patch * 2530_usb-storage-nikon-d40x-quirk.patch What do these do? Why do we need them? * pre-2.6.23.2.patch Where does this patch come from? Where is it (not in our CVS)? The 2.6.23.y git tree shows no new patches since .23.1, so I would at least like a comment about it. My opinion is, we should remove most of the above patches as 1) we don't know what bugs they may introduce, 2) they haven't been merged upstream for a reason or 3) they have been merged but in a different way, introducing two fixes for the same problem, and the one in the vanilla kernel is most likely much cleaner. It appears to me that tpowa often blindly adds patches that are submitted, with the only condition that they apply and build. I want to reduce the number of patches applied to our kernel, and I want that any patch that adds a new feature or bugfix MUST be merged in a future version. If a patch has never been submitted, it should be submitted, if it has been submitted and rejected, it should be dropped.