>> 3) Out of tree drivers will become second class citizens. > > I don't see that as a con. I see that as a benefit. If something is not in > the tree, it IS a second class citizen, and users should not expect it to > work any more. If the trident driver breaks, they can always use vesa. > >> This doesn't >> apply to proprietary drivers only but also e.g. to the Gallium xorg >> state tracker, which we may want to use for Radeons at some point (and >> some nouveau people have been playing with it as well, but I don't know >> what their plans are for it). > > As someone without much experience with the Gallium xorg state tracker, I'm > curious what technical hurdles prevent you from using it as a library linked > against by the x11 driver.
I thought Thomas wanted to move the gallium state tracker to a driver/xa split anyways going forward. > >> Speaking as a radeon driver developer, merging the driver into the >> server tree would be unworkable at this point because since the "new >> development model" has been in effect, it's not possible to get even >> trivial changes into the server tree without a ridiculous amount of >> time/effort. > > Can you be more specific? When we were discussing this yesterday, it seemed > like the "new development model" was working and that it was no longer a > barrier to this problem. The longest you will go to get in to a stable > release is 7 weeks. That is in the rare case that you have it ready > immediately after the release of rc2 and you really want to use a stable > release version. > > Instead of pushing your changes to xf86-video-ati, you would push them to > xorg-server-ati and when ready send [PULL] emails to the manager for the > branch you want your changes to land in. > > Looking at the xf86-video-ati git repo, I was shocked to see that you really > only have master and don't use separate branches for old stable releases. > IMO, transitioning to a code management paradigm of development versus stable > branches would be a win for you and your customers because you can do more > experimental changes in master and just cherry pick support for new hardware > and general bug fixes into the stable branch. We do, its just not much interesting happened lately. We only branch stable when we see the need. Dave. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
