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 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&url=/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
