Hi Andrew,
Ah, okay, that makes sense. I was wondering about how the compatibility version would have to bedone anyway in such a case :D. So it should probably also be a general thing to better not change the compat-version during one merge window, right?
I'll try to make too patches now then, that's fine.
Cheers, Linus
On Thu, Mar 04, 2010 at 10:03:55AM +0100, Andrew Lunn wrote:
On Thu, Mar 04, 2010 at 12:39:46AM +0100, Linus L??ssing wrote:
Hi,
Marek and I have been chatting a little about the buggy vis raw output yesterday. And there was either the option to sort the mixed list on the receiving vis server or on the sender already. For the second option there was also the idea of changing the vis packet format accordingly to also save some more overhead.
A comment about the mainline development process. Changes which are clearly bug fixes we should be able to get merged into the -rc kernels at any time. Changes which look like development work have to wait until the next merge window.
This vis problem about it showing the wrong interface will be in -rc1. It would be nice to get it fixed. We are more likely to get such a fix accepted if it is small and looks like a bug fix. I expect it will get rejected if it is big and looks like development work.
So can we develop two fixes? Something small and simple for -rc1 and an optimizing fix which will go into linux-next and then into mainline during the next merge window?
Andrew