Re: DRM development process wiki page..

[Thomas H. <th...@tu...>]

Dave Airlie wrote:
> On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström
> <th...@tu...> wrote:
>   
>> Dave,
>>
>> This process looks ok to me,
>> but I think some clarifications are needed:
>>
>> Dave Airlie wrote:
>>     
>>> Okay I've put some thoughts up at:
>>> http://dri.freedesktop.org/wiki/DRMProcess
>>>
>>> and I've pasted it in below this for discussion.
>>>
>>> some other points:
>>>
>>> a) People are pushing for a process change, we will have something
>>> change, however this isn't a who shouts loudest competition, so more
>>> than likely you'll end up compromising, deal with the fact that
>>> nirvana for you may be hell for others.
>>>
>>> b) BSD developers do exist now, giving out that they didn't exist in
>>> the past or aren't adding features is pointless. Would you seriously
>>> start developing features before
>>> getting the code caught up?. So live with the fact that we should help
>>> the BSD guys *if* its practical. So we shouldn't do anything major
>>> that alienates their further development.
>>> (personally I care little for BSD, the license or the OSes, however
>>> I'm attempting to be some way fair).
>>>
>>> c) We get testers from drm master, we get better testers using drm
>>> master for features than a separate kernel tree. We get better
>>> regression tests from getting stuff upstream. However upstreaming
>>> stuff to Linus is not how to find regressions, it helps but its
>>> suboptimal in that he will eventually ignore us if the regression rate
>>> gets too high. So upstreaming is great for features like GEM, however
>>> it would suck for something like vblank-rework. This appears to point
>>> at, upstream is great if you touch one driver and exist in your own
>>> world, however if you want interfaces that all drivers can use like
>>> vbl-rework you need to work somewhere else or carry two interfaces
>>> until everyone is ported.
>>>
>>> So lets see if we can improve this for everyone...
>>>
>>> Dave.
>>>
>>>
>>> DRM Development Process (Proposed)
>>>
>>>
>>>       
>> ...
>>     
>>> 1. All patches to be sent to the mailing list with S-O-B, no patches
>>> to be committed to master branch. Nothing goes upstream or into master
>>> without Signed-off-by and maintainers Signed-off-by. 2. Do not mix
>>> cleanup and developement ever. If you move a bunch of registers or
>>> code into a separate file, do just that in one patch. 3. Backwards
>>> compat patches in separate patches. So first patch should be
>>> upstreamable, backwards compat patches should be in sequence.
>>>
>>>
>>>       
>> Let's say we rework a driver completely, including DDX, to support GEM / TTM
>> or whatever.
>> The driver is, in effect, a "new" driver and there are no intermediate
>> versions of drm
>> that could be of interest really, since they wouldn't work with any of the
>> user-space
>> clients. So no bisecting is possible. Would it be OK to treat such work as a
>> new driver
>> and post it as a (URL to)  single patch?
>>     
>
> Yes I'd be happy with that, of course I'd also like the development to
> occur in the open.
> If someone else were to start working on something in the open that
> others were working on under contract or in secret, then I'd expect
> the contracted group to merge to the open stuff....
>   

Yes, that sounds fair. I guess at least the very least should be a 
common understanding with
the people actively working on the open stuff on what to keep and what 
not to keep.

>   
>>> Upstream first policy
>>>
>>> This policy places a restriction on users of the drm, i.e. Mesa, DDX,
>>> X server. No upstream release should include code that hasn't been
>>> included in a Linux kernel release cycle. Upstream can use a
>>> --enable-experimental-kernel-api type flag but default build should
>>> never require any unreleased kernel/drm API to build or run. Distros
>>> should not enable experimental APIs in releases, unless they are
>>> willing to version their kernel and other components against each
>>> other and deal with the fallout of API changes.
>>>
>>> All userspace APIs need to be submitted to dri-devel and to the Linux
>>> kernel list, also all patches which need exports or use new non-drm
>>> kernel functionality should be reviewed by both lists.
>>>
>>>       
>> Are driver-specific IOCTL interfaces included in this?
>>     
>
> Yes, any userspace API, anything we need to support for ever and ever.
>   
That's really the point that this may or may not be the same thing. The 
old drm model placed a
driver's user space interface under versioning, and any app using that 
interface would need to
monitor the major version number to check for compatibility, although 
major bumps were
strongly discouraged.

/Thomas

> Dave.
>