Minutes from X.Org Architecture Call for 30 August 2004

All,

The minutes of today's Architecture call. 

Since the issue discussed on today's call has been discussed
on both the [email protected] and [email protected]
lists, I'm posting the minutes to both of those lists.  Apologies
to those who receive multiple copies.


Attendees
---------
Paul Anderson
Stuart Kreitman
Kevin Martin
Alan Coopersmith
Keith Packard
Leon Shiman
Dan McNichol
Egbert Eich
Roland Mainz


[Note: This was a long call with a lot of discussion, so I
wasn't able to completely capture everything in the minutes.
I hope this provides a reasonable summary, but I would ask
participants to add comments in places that I have missed,
and to correct any errors.]

The call began at 10:00 Mountain Time.

As noted in the agenda, the entire call today will be devoted
to discussing the issue raised on various mailing lists
with respect to libXaw and its dependency on libXp.  There have
been a number of issues raised with this approach, despite
the fact that it has been in the tree for some time.  For
a summary of this, please see the mailing list archives
to the [email protected] and/or [email protected]
lists.

Objectives for today's call:

(1) How to resolve this in this release
(2) How to resolve issues w/changes to this library in the future

If there are time constraints, we'll defer (2) to a future call.


The first question raised was: Will the "new" libXaw that
links in libXp avoid having to relink applications that
use libXaw, or will shipping a "new" libXaw be sufficient?

Keith noted that old versions of executables on OpenBSD/NetBSD
still use a.out format, so libraries cannot have dependencies
on other libraries, because the executable lists all of the
shared libraries.  As a result, applications that link Xaw on
OpenBSD/NetBSD will need to be relinked to pull in Xp, if we
went this route.  One possible solution would be to implement
Roland's solution on platforms that don't have a.out.

Roland asked why this doesn't affect SHAPE on those platforms,
since Xaw references SHAPE symbols.  The answer is that SHAPE
was added in Xaw version 7 (Xaw version 6 does not include SHAPE
support).  This means we have an instance where new dependencies
were added and the major version of the library was bumped
accordingly.  SHAPE, however, is pervasive today and is considered
a defacto part of the system.

Is this considered a showstopper for platforms that only support
a.out executables?  Keith felt it would - we'd have to change
the version number of libXaw and ship two libraries on those
platforms.  It would be good to ask someone who more regularly
supports the platforms in question to see what their perspectives
are.  Egbert noted that OpenBSD has already been versioning 
Xaw on their own.

For other systems, apps that use Xaw will not need to
relink, since Xaw will load in Xp automatically.  This gets
back to the building and distribution of Xp itself, which has
its own set of issues. 

Is libXp something that we can build or deliver conditionally?

The primary issues with the building and distribution of Xp 
that have been raised are (as I understand them) as follows.
One approach that has been proposed is to allow the Xp support
to be conditionally compiled into Xaw, based on whether or
not the build options indicate Xp will be built.  While
this avoids having to ship multiple versions of libXaw, it
can cause another problem where by different vendors
deliver a libXaw (version X) that has different content.
As a result, application providers won't necessarily know
which version of libXaw exists on a system, and they may
revert to the lowest common denominator.

libXp is used by a wide variety of applications.  Most vendors/
distros on the call today deliver some flavor of Motif to support
legacy applications, and the current version of Motif depends
on libXp.

Keith: X.Org shouldn't force members to support specific
functionality.  Application vendors and developers who want
to use Xprint shouldn't be affected by what distributions choose
to ship/not ship.  For example, many versions of Mozilla require
XPrint support, but Debian and RedHat ship versions of Mozilla
without XPrint support.

There are two other historical issues that have made this
particular issue with Xaw more contentious:
(1) Versioning Xaw - 6 to 7 was painful; some people don't want
    to do it again unless absolutely necessary
(2) Involves what distributions are expected to ship


Keith asked if it is possible to do this slightly different from
how Motif does it.  Can we make a slight change that will make
it easier to add a libXawXp (or whatever we would call a smaller
version of Xaw with Xp support) without requiring libXaw to depend
on Xp?  Keith discussed a possibility, but Roland feels it is
significant enough that it would require a full retest.

The other option is to version libXaw.  Would it be possible to
do this?  Roland has suggested freezing libXaw at its current
version and putting the Xp changes into a new version.  Others
suggested that we could bump the major version to give us an entire
"minor" version space to play with so that the current version
could pull in additional fixes.  Roland this could work, but his
goal throughout the project was to maintain compatibility with
Xaw version 7, so that work as well as the testing would be lost.

Egbert asked what the disadvantages (now and in the future) of putting
this functionality in a separate shared library.  Roland said
that it can complicate the implementation and could result in
circular dependencies among shared libraries.

One of the issues highlighted is that there is still work to
be done with Xaw and its relationship to Xp that is not ready
yet.  One of the concerns mentioned in this context is that
we don't want to implement a solution in X11R6.8 that might
complicate this future work, or leave an unpleasant support
legacy.


Possible solutions:
(1) Ships as a separate library - potential disaster in the future
    if not thought out carefully.
(2) Ship Xaw as different major version.  This means we have two
    libraries that essentially do the same thing.  This would 
    likely be a quick fix that we could regret later.
(3) Say we don't have a good solution now and come up with a 
    better solution later.
(4) Freeze old version of Xaw from X11R6.7, put it in a separate
    directory and vendor ships the version they want.  This means
    that an application vendor doesn't know what version they'll
    have on a system and may have to deliver their own.  This
    could have the same encumbrances as (2).


Paul asked that if we chose (3), what could we do to give Roland
confidence that this would be taken seriously and that people
would work together to come up with an acceptable solution 
ASAP after the current release ships?

Keith: The vendors who don't want to be dependent upon libXp
need to put some resources on this so that changes to Xaw
related to this functionality don't necessarily depend on
libXp.  

(Keith will send out a note to the board further elucidating
some of the potential architectural possibilities he discussed.)


After further discussion, the options facing the X11R6.8
release were restated (and renumbered) as follows:
(1) Ship the X11R6.7 version of libXaw in X11R6.8 and plan to come up
    with an architecture that will allow Roland to do what he needs
    to do in Xaw without requiring a dependence on libXp.  
(2) Split functionality into a separate shared library.  This is
    not preferable to Roland.
(3) Bump major version of libXaw
(4) Ship Roland's completed work on libXaw, noting that it will depend
    on libXp.


Since option (2) is not preferred at this time, options (1), (3),
and (4) remain as the most viable options from which to choose.



Conclusion
----------

During today's discussion, it was evident that the group would
not converge on a solution during today's call.  After further
discussion, it was agreed to put this to a vote of the Architecture
Board.  The attendees present on today's call agreed to abide
by the decision of the Architecture Board.  Kevin further stressed
that he, as release manager, would abide by the decision of the
Architecture Board on this matter.

Therefore, a formal vote is needed by the current members of
the Architecture Board.  Given that the release schedule depends
on the resolution of this matter, it needs to be resolved in
a timely fashion.  

Keith suggested an 18 hour discussion window that starts once
the minutes are posted, followed by a vote.  Members of the
community are free to voice further opinions on this matter
during the discussion window.  The votes need not be posted in
public during the voting process, but votes will be made public
when the process is complete.

The Call adjourned at 12:30 Mountain Time.

[Note: The minutes will be sent at the following time:
 2:00PM PDT/3:00PM  MDT/4:00PM CDT/5:00PM EDT/21:00 UTC.
 Please send all comments on this matter as soon as possible.]



Best regards,

-paul