[Xorg] Notes from release call

[Ely Levy]

25 Aug means to release a beta preety soon?
When are we going into code freeze?
should we brench into release and continue to advance in the tree?

Ely Levy
System group
Hebrew University
Jerusalem Israel



On Fri, 9 Jul 2004, Eric Anholt wrote:

> Here are a few notes I'm writing down from the release call, in case we
> don't get minutes.  I wasn't paying attention to who said what, so these
> are just my impressions/conclusions from the call and are not complete
> in any way.
>
> First topic was .so modules:
> - keithp explained the debrix work on making the server use .so
> modules.  We should be able to produce .so modules that retain
> cross-platform compatibility for anything using ELF by using the libc
> wrapper, as long as the modules avoid certain hazardous functions
> (setjmp/longjmp)
> - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> on autotooling the x server but have found sticky issues with modules
> involving references to global symbols.  They've been fixed in that
> tree, mostly, but this may prove to be a hazard for vendors moving to
> .so modules
> - We should make our modules as .so, which gives us more architecture
> support and debugging ability, but retain the old loader if it proves
> difficult to make the switch fully.  We could also take vendors' .a
> modules they produce and convert them to .so using ld probably.
> - Has anyone tested .so modules cross-platform?  Nobody on the call at
> least.  anholt was volunteered for testing.
>
> Modularizing the build:
> - keithp had volunteered, eich had volunteered to help, but progress has
> stalled due to lack of time.
> - keithp doesn't have time until at least 3 weeks from now
> - Many, but by no means all libraries have been autotooled in the xlibs
> project, so we have a basis to work from
> - Modularizing of xorg can be done incrementally.  First, rearrange
> includes directory to make modular while retaining imake build, which
> allows the libs to be done.  Later the xserver autotooling can be
> brought in, at which point the imake build can be left to rot.
>
> Composite:
> - anholt has attempted to do Composite support for XAA, which was never
> completed, but the first thing to do would be to make a wrapper at the
> miext layer that retained binary compatibility.
> - If we move the new fields in PixmapRec to the end, we shouldn't have
> any binary compat issues, because nobody should be statically allocating
> PixmapRecs (since they wouldn't have the privates), or at least if they
> do, the rest of the server shouldn't be seeing them.
> - anholt concerned about doing Composite wrapper because of lack of
> experience, eich suggested he could.  (I'm attempting it anyway)
>
> Release:
> - Timing of next release: two months?  end of year?  next year?
> - Proposed that we release in time for Fedora Core 3
> - FC3 schedule would require a release by Sep 6?
> - Proposed that we target having a release by Aug 25
> - General agreement found.
> - What should be in release?  Composite/Damage/Fixes found general
> agreement.  What else?  Call put out to xorg@
>
> --
> Eric Anholt                                eta at lclark.edu
> http://people.freebsd.org/~anholt/         anholt at FreeBSD.org
>
>
>
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
>