Re: Kernel Oopses in recent DRMs

[Thomas H. <uni...@sh...>]

Hi, Ian.

Ian Romanick wrote:

>
> Since our CVS situation has changed, the policy has also changed.  The 
> docs, unfortunately, have not.  As near as I can tell, the situation 
> is as follows:
>
> - Client-side driver development happens in the Mesa CVS trunk.  
> Stable code lives in a branch.
>
> - DRM driver development happens in the DRI CVS trunk.  Stable code 
> lives in the kernel tree.
>
> - Any code not covered by the previous two rules follows whatever the 
> X.org policy is.
>
> Based on that, how does the currently shipping kernel (2.6.8.1 still, 
> right?) fare? 

Ok, fair enough.

The via drm is AFAIK not in the kernel due to the security issues. And 
also the via-specific features has undergone some development lately, 
and that is what our users are after. I guess creating a reasonably 
stable "via-stable" branch in drm would be an option?

How do we make sure the drm code that ends up in the currently shipping 
kernel is reasonably stable?

>
> There are basically 3 classes of users. 
> The third group are the people in the middle.  They want the latest 
> stable updates.  I think this is the largest group, and it is also the 
> group that getting the short-end of things right now.  We've had 
> discussions about "those people" in the past, but we've never come to 
> any firm conclusions.  I've always liked the idea of, once a month, 
> picking the "known best" nightly snapshot and marking it as the stable 
> build.  The only problem is that requires a certain amount of 
> manpower, and nobody has had / taken the time.

I understand. This is an idea also proposed on the unichrome lists, and 
we mostly have users of this third category. However it has a tendency 
to not help developers find bugs, since a "third category" user would 
try the "last known good" release instead of reporting a bug.
Also, should the last known good releases be the basis of what's going 
into the shipping kernel?

What about having a "release" branch that merges in trunk code that is 
known as reasonably stable?

Regards
Thomas