Xorg 7.4 release plan

[Adam Jackson]

On Tue, 2008-02-26 at 17:32 -0300, Paulo Cesar Pereira de Andrade wrote:
> Adam Jackson wrote:
> > pciaccess is not done.  We still have ~20 drivers that haven't been
> > ported, and some of them are not quite trivial to convert.  This needs a
> > champion in a serious way.  I'm convinced enough of pciaccess' value
> > that I don't intend to revert it for 7.4, but we need to make progress
> > here.
>
>   Until all drivers are either ported, or dropped, at least an interface
> that converts old functions calls to pciaccess format should be made.
>   Last time I looked at the code, there was initial work on it, and since
> drivers that have support call xf86AddDriver with "HasDriverFuncs" argument,
> instead of 0, it should be possible to adapt at run time.

Patches gratefully accepted.  Personally I think pciaccess could have
been done in-place as an ABI-but-only-kinda-API change, by redoing the
backend and widening the return types to be int64 instead of void * as
appropriate.  But, bit late for that.

I agree with Ian here, a compat API is approximately as much work as
just fixing the drivers.  And drivers that don't get converted are an
excellent opportunity for swamp draining.

>   I am concerned more about if also because I need to work with VIA
> and SIS hardware and binary only modules for OEMs; and long delay from
> the vendors to adapt to changes.

People shipping binary-only modules have chosen to make their life hard.
I'm not going to have the server held hostage to preserve binary
compatibility with a grenade some company lobbed over the wall five
years ago to sell that quarter's hardware.  It's not how you build
working long-term relationships, and it's not how you write good
software.

> > In light of discussions about various people's time commitments at LCA,
> > I'm going to be taking the release manager role for this one, with Eric
> > and Daniel acting as deputies for things like patch review.  My interest
> > is primarily in the server component; driver maintainers, if there's a
> > specific branch I should be looking at for 7.4 inclusion, please notify
> > me, otherwise I'll assume releases should happen from git master.
> 
>   Ideally, git master should be always in an stable state, but 
> unfortunatelly
> it is not, so  I suggest using server-1.4-branch for the X Server, otherwise
> the breakage may be too much to handle, and this is what most distros are
> already using.

I understand the sentiment, but I disagree with the conclusion.  From an
engineering perspective, we have to stabilise master sometime.  At this
point, the longer we wait to do so, the harder it's going to be.  This
is just simple entropy management, for the same reason cleaning your
room is easier if you did it recently.

From the product perspective, I think we need to accept that _the_
release driver for the katamaris is the server.  The server is the
fundamentally interesting piece of technology, everything else is just,
uh, window dressing.  The katamari release is our advertising.  7.4
needs to be a material improvement over 7.3 along an axis other than
mere stability or else we're not doing our jobs.  Therefore, to make a
compelling 7.4, we need a compelling server.

1.4 is not a compelling server.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080227/11079476/attachment.pgp>