Hi, Am Samstag, den 21.02.2009, 23:47 +0000 schrieb Adam Baker: > On Saturday 21 February 2009, Hans Verkuil wrote: > > > The high rate of changes and new drivers means that keeping up the > > backwards compatibility becomes an increasingly heavy burden. > > > > This leads to two questions: > > > > 1) Can we change our development model in such a way that this burden is > > reduced? > > Possibly but even just spreading the burden better (and avoiding the compat > code affecting the main tree in the case of i2c) would be a worthwhile > change. > > > 2) How far back do we want to support older kernels anyway? > > > > To the point that the effort expended on the compat work is balanced by the > benefit of more testers. > > > These questions are related, since changes in the development model has > > implications for the answer to the second question. > > > > > > 1: Alternatives to the development model > > ---------------------------------------- > > > > I see the following options: > > > > A) Keep our current model. This also keeps the way we do our backwards > > compatibility unchanged. > > > > B) Switch to a git tree that tracks Linus' tree closely and we drop > > backwards compatibility completely. > > > > C) Switch to the ALSA approach (http://git.alsa-project.org/). > > > > Another example of this approach can be seen with the linux-wireless git tree. > There is a description of the process at > http://linuxwireless.org/en/users/Download#Developers > > It might be a more relevant example as there are changes in 2.6.27 that make > it difficult to support older kernels. They therefore made a decision at that > point to restrict the automated backporting to 2.6.27 onwards and say patches > will be accepted to the compat tree that covers 2.6.21 to 2.6.26 if a driver > change is compatible but they must be manually flagged as being suitable > (I've no idea how many are). > > It does require one person (who isn't the main wireless maintainer) to be the > maintainer of the compat tree. > > > B: Switch to a git tree and drop compatibility completely > > > > Pros: > > > > - makes driver development and v4l-dvb maintenance very easy. > > - no compatibility issues anymore, this saves a lot of time. > > - ability to change kernel code outside the driver/media part. > > - received patches against the latest git tree are easy to apply. > > > > Ensures that driver changes get tested in the kernel they will be released in > so there is less chance of a change elsewhere breaking your change. Also > means more people are testing pre release kernels so might have stopped the > USB bug in 2.6.28 making it to the released kernel. > > > Cons: > > > > - no compatibility means that the initial testbase will be reduced > > substantially since it will be too difficult for many users to install the > > bleeding-edge kernel. So real feedback won't come in until the code is > > released as part of the main distros kernels. > > - the same is true for ourselves: we need to continuously upgrade our > > kernel, which is not always an option. > > > > It also means that a git pull can result in a long long rebuild if the > upstream has just pulled a load of changes to other subsystems. > > > > > 2 How many kernels to support? > > ------------------------------ > > > Keeping support for older kernels should come with an expiry date as at > > some point in time the effort involved outweighs the benefits. > > I think the outweighs the benefits point is critical here and indicates what > the break point should be. > > > > > Oldest supported Ubuntu kernel is 2.6.22 (7.10): > > https://wiki.ubuntu.com/Releases. End of life for this one will be in April > > 2009, after that the oldest kernel for Ubuntu will be 2.6.27 (8.10). > > > You missed 8.04 which EOLs in April 2011 for Desktop use and uses 2.6.24 > > > > In my view these criteria strike a good balance between supporting our > > users so we can good test coverage, and limiting the effort involved in > > supporting the compatibility code. And they are also based on simple facts: > > whenever the oldest regularly supported kernel changes, we can go in and > > remove some of the compat code. No need for discussions, the rules are > > clear and consistent. > > I don't think anyone will (or need) actively track theses dates unless the > code is causing them a headache but the rule is still a useful guide - if the > compat code is causing you a problem and the 3 most popular distros have > EOLed the relevant kernel it can be dropped without discussion by whoever > administers the compat repository, otherwise it should be discussed on the ML > first. > > The only question then would be how to choose the 3. I don't think 1 and 2 are > in much dispute but I suspect OpenSUSE is slugging it out for 3rd place with > Debian. > > > > > And luckily, since the oldest kernel currently in regular use is 2.6.22 > > that makes a very good argument for dropping the i2c compatibility mess. > > > > Unfortunately this all omits one important point, are there any key developers > for whom dropping support for old kernels will cause them a problem which > could reduce their productivity. Mauro has stated that it would cause him a > problem but I can't tell how big a problem it would really be. > > Adam > -- all nice, but ... First, we have the best out of kernel build and compat system ever. This has reasons. Second, Jean and Hans gave arguments for some limitations after we previously worked in the other direction. I and others tried to express, that we can't provide support for latest drivers for commercial distributions endlessly and that there must be a limit for what is released at kernel.org and how far they can fall back. Even if they are most productive contributors, Greg has statistics, they are it _not_ here at all. I would leave this entirely to those who contributed, Mauro, Trent, Mike and Hans to help Jean further. In fact, we had a breakage first for 2.6.18 and later for below 2.6.22 and nobody did care anymore. I repeat that Hans caused his own problems now going further down :) Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
