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
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
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
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
Major bumps once stuff went into the kernel weren't allowed at all.
You'd need to fork the driver in any case. So we did this once or
twice on drivers in devel trees like mach64.
However upstream first policy should avoid this need. I'd also prefer
to see getparam for new features instead of
On Thu, Aug 28, 2008 at 8:23 AM, Keith Whitwell
[EMAIL PROTECTED] wrote:
Major bumps once stuff went into the kernel weren't allowed at all.
You'd need to fork the driver in any case. So we did this once or
twice on drivers in devel trees like mach64.
However upstream first policy should avoid
Keith Whitwell wrote:
Major bumps once stuff went into the kernel weren't allowed at all.
You'd need to fork the driver in any case. So we did this once or
twice on drivers in devel trees like mach64.
However upstream first policy should avoid this need. I'd also prefer
to see getparam for
On Wed, 2008-08-27 at 13:35 +1000, Dave Airlie wrote:
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland [EMAIL PROTECTED] wrote:
On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote:
Okay I've put some thoughts up at:
http://dri.freedesktop.org/wiki/DRMProcess
and I've pasted it in below
On Tue, Aug 26, 2008 at 11:17 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
I am outlining the fact that you confuse a problem and its solution.
Problem: merging stuff upstream takes time to Dave
Your solution: have lots of
On Tue, 2008-08-26 at 14:17 -0700, Jesse Barnes wrote:
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
As for the new development model...
or carry two interfaces
until everyone is ported.
So lets see if we can improve this for everyone...
Dave.
DRM Development Process (Proposed)
1. Master branch in Linux tree style with links for BSD etc.
2. Always compatible with current release Linux kernel + with
backwards compat *where
On Tuesday, August 26, 2008 5:15 pm Dave Airlie wrote:
DRM Development Process (Proposed)
1. Master branch in Linux tree style with links for BSD etc.
2. Always compatible with current release Linux kernel + with
backwards compat *where* practical for older kernels. We should
probably limit
everyone is ported.
So lets see if we can improve this for everyone...
Dave.
DRM Development Process (Proposed)
1. Master branch in Linux tree style with links for BSD etc.
2. Always compatible with current release Linux kernel + with
backwards compat *where* practical for older
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland [EMAIL PROTECTED] wrote:
On Wed, 2008-08-27 at 10:15 +1000, 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
14 matches
Mail list logo
