> 
> We want to ship packages with all new features wherever possible. But
> we have to make sure, that at least 2D is always working and 3D should
> be stable and fast. We know we will often run into bugs first but our
> community likes it - see us as a big testing group for you :)

Unless you have a large amount of time of ppl with experience of graphics
I'd recommned the following (below)..
> 
> That's why we ask for your recommendations what is already usable and
> worth packing.
> 
> 1) kernel drm modules: 
> Is it enough to ship the latest stable kernel? Or do you recommend
> drm-next or any other branch replacing the the default kernel modules
> in /lib/modules/${_kernver}/updates/ ? We are thinking about such
> additional packages we can update more often if needed (we did so in
> the past for nouveau-drm).
> Do you recommend to enable kms now by default for all chips?

Ship Linus kernel, when things leave staging, you can generally turn them 
on, not before unless you can provide the support to users and upstream 
feedback cycles for bugs. Its worse for us when ppl have a load of binary 
packages that the distro has just picked in  the middle of a dev cycle and 
never upgrade. We generally provide experimental features so we can get 
feedback and debug them, shipping these without a supporting person in the 
distro keeping the feedback cycle alive is actually a drain on our end. We
get bug reports for sutff 2-3 mths after we've fixed it because of some 
distros.

> 2) libdrm
> What configuration is recommended? Is enable eperimental api code
> needed and recommended for for certain chips?

Same, leave it alone, --enable-udev is probably all oyu want.

> 
> 3) mesa
> Do you still recommend 7.6.1? When will it make sense to package 7.7?
> When Xorg 1.8 is out or when will the driver make use of 7.7 features?

7.7 is out, probably best to ship it now. since it contains all 7.6.1 
fixes

> 4) Driver packages should be announced clearly on what they depend.
> Maybe better or more clear branching is needed.

Generally if there is experimental APIs then you need to do the research
with normal packages on a Linux distro, the latest released everything 
should be the best option.

Dave.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to