State of X.Org Report

[Dave Airlie]

On Sat, Feb 23, 2013 at 1:20 AM, Jeremy C. Reed <reed at reedmedia.net> wrote:
>
> On Fri, 22 Feb 2013, Bart Massey wrote:
>
>>     In keeping with the X.Org goal of about one release per
>>     year, Release 7.7 of the X Window System occurred 6 June
>>     2012. Release 7.6 was about 1.5 years earlier, in
>>     December 2010. However, there is some feeling among the
>>     developer community that the "katamari" point releases
>>     of all of X are no longer terribly useful, yet are a big
>>     consumer of developer resources. Thus, it is likely that
>>     these releases will be farther apart in the future, or
>>     will cease altogether--not because development pace is
>>     decreasing, but because point releases of individual
>>     components are a better mechanism in the "new" world of
>>     modularized X development.
>
> Does X.org have an automated build and test farm that will prove that
> the important individual components continue to build and work together?
>
> A common problem I see as a package maintainer is mismatch of components
> due to upgrading one X.org component but not some other (missing
> features, missing headers, etc.).  pkg-config dependency checking may
> not reflect accurately the versions required. I have also seen that some
> new version is required even though that new version is not publicly
> released yet (it is in git, but no tarball release).
>
> Maybe the large yearly all of X release is useful as a manual
> confirmation until an automated confirmation is available.
>
>>     Sprint, in March, was a "virtual" online event that
>>     produced an "X.Org New Developer Guide" that has not
>
> Where is this? A google search and wiki search doesn't find it for me.
> (I do see ModularDevelopersGuide.) Is it in the wiki or in git?
>
> Thank you very much for your report. Was there any board discussion
> about licensing? In particular, the concern I see is with various driver
> support changed from MIT-licensed X.org code to using code provided in
> the Linux kernel tree (such as under drivers/gpu/drm). Much of that
> newer Linux code is MIT-licensed, but many files are missing licenses,
> some are marked with GPL2 or GPL2-or-later, and some are MIT-licensed
> but tagged with EXPORT_SYMBOL_GPL.

Generally the code that is portable is MIT if the authors submit is as
such. Some vendors don't want MIT code, so they need to be addressed
when someone wants to port the code (Samsung is probably the only
one).

The symbol exports are nothing to do with the license of the code,
they are to do with the license of code linking with the code.

Dave.