(Short?) merge window reminder
Version numbers should not be only numerology, but connected to quality or progress. Comparing the situation of the 1, 2.0, 2.2, 2.4, 2.6 versions, since starting 2.6 , the progress of the kernel, and also the situation of Linux as a whole and of its use changed very. Exactly in the last subversions with many new hardware modules/drivers the quality improved very. At the same time, the subversions becomes too much since the last new version. Thus, it's time for 2.8 or even 3.0 in order to mark this very improved quality and use of Linux since the start of the 2 and 2.6 versions. wl
---
Professional hosting for everyone - http://www.host.ru
Quoted 10 lines · werner
Version numbers should not be only numerology, but connected to quality or progress. Comparing the situation of the 1, 2.0, 2.2, 2.4, 2.6 versions, since starting 2.6 , the progress of the kernel, and also the situation of Linux as a whole and of its use changed very. Exactly in the last subversions with many new hardware modules/drivers the quality improved very. At the same time, the subversions becomes too much since the last new version. Thus, it's time for 2.8 or even 3.0 in order to mark this very improved quality and use of Linux since the start of the 2 and 2.6 versions. wl
---
If i were to give my feeling, and i am doing it right now, i wish that such version change to be backed with things like removal of dead code for instance in the GPU side we would like at one point to drop non KMS path and delete a whole bunch of files and dead API in the process (at least that's on my bad santa list). Non KMS is in survival mode, at this point we try to not break it but we don't give shit about it. Bug against it are redirected to the closest black hole.
Cheers,
Jerome