From: Jerome G. <gl...@fr...> - 2008-08-02 13:50:25
|
On Fri, 1 Aug 2008 17:29:39 +0100 "Keith Whitwell" <ke...@tu...> wrote: > > The biggest thing I have against this is that it cuts our testing base > > down, we have a small testing base already, cutting it further jsut to > > benefit some developers who are frustrated isn't really a gain. > > > I don't have a particular attachment to the standalone drm tree > concept. It really does date from another era. > > Back then we had different ideas about how people would get their > drivers and what OS's would be enthusiastic enough to want to join the > party. > > It is nice to be able to build new drm against older kernels, however > -- I'd be a bit sad to lose that possibility. If that can somehow be > preserved, at least for relatively recent kernels (perhaps a 1 year > window??), then there's nothing I've got against this. > I might be totaly wrong so feel free to ignore these. I got the feeling that the user test base on linux kernel is far bigger than ours. Also i think that our test user base are people wanting lastest things with old kernel, while i understand that (building kernel is not fun on my ram slim computer) i think this end up being a burden to us. So in the end i think we should be better off with linux development tree where dev know the deadline to get feature in. I got the feeling that this way we could drive development on features basis like getting vblank rework done for a given kernel release and so get dev to focus more on some features and get them done in a timely fashion. This way we could avoid to get some new feature to rot a bit in the drm tree because. Also i think the linux-next or other linux bleeding edge tree would give us lot more tester with a lot more experience on good bug report that our current test base (i am not saying that we have bad tester, we have some very good one too which we should give credits, just that we might be able to get more of them). Thought, i might be wrong, just my feelings here. Cheers, Jerome Glisse <gl...@fr...> |