xorg7.3 [was: 7.0 preview slides]

[Florent Thoumie]

On Sun, 2007-11-04 at 17:52 +1100, Peter Jeremy wrote:
> On Sat, Nov 03, 2007 at 11:41:32PM -0500, Mark Linimon wrote:
> >The situation was that our import of 7.2 was delayed as we tested and
> >retested and retested, to get the framework working for the modular
> >code and ensure as few regressions as possible.
> 
> Thank you for that.  I think it's unfortunate that X.org has decided
> to stop bothering with integration testing themselves but am glad
> that the FreeBSD ports team were able to do this for 7.2.
> 
> >It seems as though 7.3 is better for some people and worse for others.
> 
> Having followed X within FreeBSD from XFree86 3.1.2 through to X.org
> 7.3, I can safely say that X.org 7.3 is by far the worst version as
> far as POLA violations and regressions are concerned.  I don't recall
> seeing anyone mention "better", though possibly those people aren't
> making a fuss.  It is difficult to understand how an "update" that
> broke generic features like xkb LEDs, xdm and mouse scrolling, as well
> as ati, mga and nv drivers (that I've personally used) could be
> considered an improvement.  I agree that the problem with xkb LEDs has
> been corrected, xdm has been partially fixed and I believe the nv
> problem has been fixed and there is an unofficial patch to work-around
> the MGA BIOS problem but this leaves the following regressions that
> I've noticed so far:
> generic:
> - Updating xdm over-writes local modifications

The problems with x11/xdm were my fault. If those aren't fixed now,
please say it now.

> I think it's unfortunate that X.org didn't spend more time testing
> X.org 7.3 before releasing it.  Hopefully X.org 7.4 will see an
> improvement in quality.
> 
> I agree that the FreeBSD Project is not responsible for the shambles
> that was released by X.org but X.org 7.3 is definitely nowhere near
> the quality of the FreeBSD core software or the vast majority of
> ports.  Unfortunately, IMHO releasing FreeBSD 6.3 or 7.0 with X.org in
> its current state _will_ adversely impact the general perception of
> the FreeBSD Project.
> 
> I don't believe it's feasible to roll back to X.org 7.2 so in the
> short term (for the upcoming FreeBSD releases) about all that can be
> done is to try and locate and apply fixes for the various regressions.
> 
> The solution for the longer term is unclear - the FreeBSD ports system
> can't really handle a '-devel' variant of modular X.org - it comprises
> too many ports.  At the same time, the normal X.org ports can't be
> used for beta code because too many people will wind up running that
> code, courtesy of portupgrade or similar.  Maybe the GNOME or KDE
> groups have some suggestions on how to handle integration testing of
> large ports collections without adversely affecting the ports tree.

As Mark mentioned it, X.org doesn't support old versions so there's just
no way I'm going to keep unmaintained versions in the tree. That being
said, as we're currently only updating ports when katamari versions are
released (except drivers, security or important fixes), I guess I could
work on some way to distribute snapshots of updated ports as the
components are released on fd.o, pretty much like I did during the 7.2
test period. That way, people who like living on the edge could test
them and that would give us a wider testing audience before the ports
are actually updated in CVS.

Of course that means more work for me, but I think I can handle it. I'm
just concerned about the fact that releases don't seem to be announced
on xorg-announce@ anymore. I'll have to check again.

-- 
Florent Thoumie
flz at FreeBSD.org
FreeBSD Committer