Re: DRM development process wiki page..

On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <rnoland@2hip.net> 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 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).
>
> We all have our religions. ;)  This is the most fair of any of the
> proposals I've seen or heard.  I am certainly willing to compromise, but
> even this proposal converts the project from what has historically been
> a collaborative effort (yes, I know)

tbh it wasn't really a collaborative effort ever, apart from anholt,
the BSD sharing stems from the days of the r100/r200 Weather channel
stuff, they wanted to run it all on FreeBSD at the time if memory
serves.

> tolerates renting a subdirectory in the repo to BSD.  I'm honestly about
> ready to throw in the towel.  While I have been slowly raising awareness
> in FreeBSD circles with my frequent pleas for help, I just don't have
> enough voices to influence the outcome.  I have been getting some
> attention from far more qualified developers than myself lately, but no
> commitments for substantial work have yet been made.  I already know
> better than to commit infrastructure changes that impact linux, even if
> they fix obvious bugs.  The linux side of the house is not held to the

The thing is you can't expect equality, its just not possible, there
are about 10-15 Linux developers,
and 1 Free and 1 Open BSD developer working on DRM stuff at any one
time, so you cannot expect the Linux developers
to know what the BSD requirements are. If you do checkin a major
feature that is BSD only, I'd be quite happy for it
to break the Linux build until I got around to fixing it. The thing is
we end up with a tree where you symlink from a different place.
If we can setup some tinderboxes, I'd be happy to hold up patches on
minor BSD breakages, however things like GEM etc I can't see
the point of holding up until BSD catches up. At the moment there is
no way for a Linux developer to know they have broken the BSD
build.

> same standards obviously.  Jesse and I, have a reasonably good track
> record of collaborating early enough that we have been able to commit
> working code at very near the same time.  I am having a really difficult
> time seeing what benefit I get from continuing to work in drm.git with
> this proposed model.  While all commits to master going through the
> mailing list, I don't anticipate that I have any veto power or even
> delay powers until I can at least prevent imports from breaking BSD.
> Then once I do get it squared away, I'm still left having to send those
> to the ML and wait for approval to push the fixes.  I can just save
> myself that part of the hassle and work privately.  If I'm going to have
> to hand edit and merge every change, I don't see how it is really any
> harder to do that in my own repo, where I'm only subject to FreeBSD
> rules.  That way, if I need to make a change to infrastructure to fix
> issues, all I have to worry about is maintaining ABI/API compatability.
> We all want nice pretty pristine code in our kernels and if I can't
> easily import the shared code it just isn't worth it.  I can get testing
> on our -CURRENT branch, at least for things that aren't inherently
> sketchy.  I'm probably more likely to attract other developers attention
> if I'm working in our tree anyway.

You could also have a bsd-master branch that you regularly pull from the master,
and send the fixes back to the list, You can point your testers at that tree.

but I'm not seeing a major difference between shared-core symlinks and
drivers/gpu/drm/ symlinks,
even removing a lot of the macros won't make life any harder, they
will just have different names. So at
no point have I mentioned you won't be able to re-use the shared files.

However I am sure that we will see more of a push towards using Linux
constructs in dri drivers, things like
idr, list.h, locking constructs are too much of a pain to reinvent for
every driver..

It may be that sharing the code is a dumb model, and you are better
off working on a patch level, just porting each patch to your own
tree, I'm not sure, shared-core may in fact cause more problems than
it solves.

Dave.

-------------------------------------------------------------------------
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&...
--