d then it still require regular maintenance and management. >> >> Getting DRI into XFree86 CVS seems like a relatively low-overhead way to >> reduce the lag between the two systems, perhaps we can try to restart >> those discussions. > > Well, I confess I was unaware of this, and it's really not my choice, > but I would like to share some concerns I have regarding this. > > First, would it be possible to have same amount of branches we have here > and continue the development in the same way? > > More importantly, would it be easy to add CVS access to newbies eager to > help? My personal experience here it that is enough one is keen to help > and shows he's able to and is granted with CVS access.
This is a valid concern -- I don't have CVS access to XFree86, and I've been working on the dri for years. It seems a lot like a members-only club. I'm sure there are private mailing lists and all sorts of other "in-group" discussions that the rest of the world just doesn't see. So, I guess I've got a foot in both camps: Yes I'd like to get rid of the dual repository bullshit, but No, I don't think that eg. the mach64 project would have gotten as far if DRI cvs didn't exist. It's only really since the collapse of the bozo-corp consulting group that the pressure has been lifted off the DRI project & we're obviously experiencing a renaissance. I'd hate to see that evaporate. > Here there is so > much work to do for each card, that any help is gladly welcome. I'm not > so sure if that's true with the XFree86 project. At least is not as > fast, and could frustrate some newbies. For example, I applied to be a > XFree86 developer over a week ago (just to be able to follow the XFree86 > development) and didn't got a reply (besides an automated one) so far ... > > On the other hand, it's less work to sync, and we would benefit from > mutual fixes. What's the general feeling about this? I think you sum the dilemma up pretty well. Another possibility is divorce: Move to a utah-glx type code arrangement with just enough here to build what we need to for binary releases that can be layed down on top of existing XFree installations. Periodically suck in XFree code, but don't worry too much about the other direction. Keep our stuff contained & quarantined as much as possible from ongoing XFree development. Again, this has real drawbacks and doesn't solve the issue of multiple divergent drivers. Keith _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
