Am Montag 11 August 2008 02:53:44 schrieb Stephane Marchesin: > On 8/2/08, Jerome Glisse <[EMAIL PROTECTED]> wrote: > > 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). > > Judging by the current trend (where we see lots of people reporting > the recent shmem_file_setup breakage because they tried to load git > drm on a non-tip kernel), we have a lot of testers that don't run > latest kernels but still get drm git. So the argument of more testers > may not be true.
As another data point, I belong to the "drm git on distribution-provided kernel" crowd but I would be happy to switch to the proposed in-kernel tree system. Here's why. As far as I can tell, there are three possible setups I could have: 1) The status quo (i.e. out-of-kernel drm tree) where I only compile the DRM module against my standard, distribution-provided kernel. 2) The status quo, but I compile both a recent kernel and the DRM module from the out-of-kernel drm tree. 3) The proposed new system where DRM development is done in the kernel tree. Now to be honest, of all these options I do find 1) to be the simplest option, but that simply *fails* when the DRM depends on advanced kernel developments. This leaves option 2) and 3) and quite frankly, I *really* don't like option 2) because it forces me to keep track of multiple trees that are not explicitly coupled. This is a recipe for build failures - after all, which kernel tree is guaranteed to always have all the things that the latest DRM tree needs? Is it Linus' tree? -mm? Something else entirely? As long as the DRM depends on recent kernel developments, option 3) is really the most friendly way to go forward. There's only one tree to track for me and I can simply use distribution-provided tools for the build. Of course, I'm probably not really representative, so take all this with a grain of salt. cu, Nicolai ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
