Re: Official protest against bug 1060 / was: Re: Away for a fewdays..

Owen Taylor wrote:
> 
> On Fri, 2004-08-20 at 20:20, Roland Mainz wrote:
> 
> > Erm. _WHO_ decided that libXaw is legacy code ? I thought the new X.org
> > Foundation is an _open_ organisation where people are allowed to
> > continue development on any piece of code.
> > At least my plans for libXaw are more directed in continuting
> > development on libXaw - which means: Better font support, print support,
> > accessibility support (e.g. making it 508 compliant) etc. And creating a
> > library on top of libXaw which provides more complex sets of dialogs
> > (file, font, print, list selection etc.).
> 
> X.org (or at least freedesktop.org) is definitely meant to be an
> inclusive umbrella. And I think a 21st century Xaw fits within
> that umbrella.
> 
> But on the other hand, the X.org releases should be targeting the
> mainstream of X usage; and for better or worse, the main stream
> of X usage is not using Xaw, and it's (mostly) not using Xprint.
> 
> I think the right long term solution here is clear:
> 
>  - For Xprint neither the Xprint server nor the Xprint library
>    needs to be part of the X distribution, as far as I can see.
>    libxprint just needs to use the standard Xlib extension
>    hooks,

See below.

> the Xprint server is a separate server.

Yes and no. The Xprint server can be seperate but there is no need for
that. At least HP has an unified Xserver for both video and printing.

>    So, make them separate packages, distributed on X.org, but
>    not part of the main tree.

Xprint _IS_ part of the main tree and was added with X11R6.4. And in
those days there was a _CONSENS_ to add it. You cannot simply undo that
or kick Xprint out of the main tree (yes, I know, lots of RedHat staff
like [email protected], [email protected] or Mike Harris want to see
it dead and pester around whereever they can... ;-( ).

Like Xvfb, Xnest and Xvnc the Xprt server needs huge parts of the
Xserver infratructure and it is very difficult to seperate that stuff
out. And sticking the Xprint server into a seperate tree would also mean
that all new extensions and fixes need to be ported to the Xprint tree,
too - which would result in a huge amount of unneccesary maintaince work
when new stuff gets added (XST comes in mind) or stuff gets updated
(like XRENDER). All Xservers - and this includes Xorg, Xnest, Xvfb and
Xprt - should be kept together in one tree to avoid that the common
parts of these Xservers gets out of sync.
One of the goals behind the creation of the Xorg foundation was to have
ONE common, central source repository for X11 to avoid that the codebase
of the various vendors get more and more out of sync. Ripping out some
Xservers which do not "fit" into the political plans of some vendors
will contradict these goals.

Removing the Xprint client side extension library is also not neccesary
nor something I would recomment for the simple reason: The API is stable
(AFAIK since 10 or more years) and we have no plans to change that API
in the near future. Moving it into a seperate project will cause more
havoc than neccesary.

>  - Similarly, Xaw could be broken out into a separate package,
>    that people who were excited about developing could develop
>    as they see fit.
> 
>    The problem with breaking out Xaw is definitely the toy
>    and demo apps that come with the X server. They'd have
>    to be broken out as well.

That sounds like the X tree modularisation project - which is something
for the far future. Nothing which can be done for X11R6.8 or within this
year.

> But short term, I think the need is to come to a consensus and
> release the tree. I don't really have a say in this, but
> here's the argument I'd make:
> 
>  - Adding Xprint support to Xaw really isn't the sort of change
>    that should have gone into the tree without active agreement;
>    passive "nobody objected" isn't enough.

Again, various annoucements were made. And most of the people related to
Xaw/Xaw3D I knew about were informed about the change and even people
outside that circle. This includes people like Kaleb Keithley (who wrote
parts of Xaw and Xaw3D), D. J. Hawkey Jr. (the current Xaw3D
maintainer), Egbert Eich (Xorg board member), Alan Coopersmith (Xorg
arch member) and many others.

And: Could you please list the message ids of the Xorg arch board
discussion which approved the "Tooltip" widget in libXaw ? AFAIK this
was silently added without any approval by the Xorg arch board and
neither was it annouced.
If the same rules and same conditions which were used as justification
to back out the XawPrintShell code apply to the "Tooltip" widget issue
then that code needs to be backed out, too.

>    If Xaw was a separate project, that would be a different
>    issue ... people would have an opt-out by simply using an
>    older Xaw without the new additions.

Erm... one of the goals of adding XawPrintShell to likXaw/Xaw3D was to
_gurantee_ that the new widget doesn't break binary compatibility to
older versions of libXaw.so.7.
Yes, there is the option to simply bump the major version number of the
shared library (e.g. libXaw.so.8) but then the whole effort and (mainly)
the testing was for the trashcan (after the whole disaster and the
debate here at am at the point to consider that as an option... but
somehow I start to feel sorry with the poor guys who did all the
testing).

>  - On the other hand, Roland did do this work in good faith
>    of expecting to have it released.

It's not my work. I only did the collection of reviews (and integration
of changes based upon the review comments), the commit to the Xorg tree
and the annoucements. And this debate.

>  - In my opinion, conditionalizing the Xaw/Xprint changes and
>    noting that they are experimental in the release notes
>    is a similar to what we could do with a modularized tree,
>    it indicates:
> 
>      "these changes don't reflect the technical consensus of the
>       community, but they are interesting work being done
>       within the X.org umbrella"

The same applies to the "Tooltip" widgets. And likely a couple of other
changes to libXaw made between X11R6.6 and Xfree86V4.4.0RC2. Noone
objected or complained about these additions nor was AFAIK the Xorg arch
board involved. Nor were any weired release notes written which
indicated that this code is "experimental" or "... failed to have a
technical consensus...".

>    So, I'd suggest the changes should be included with the
>    necessary liberal application of #ifdefs.

There are more options than that:
1. Leave the code as it was originally designed. It's the same design
choice as it was made for version 2 of the Motif toolkit and NOONE ever
complained about that change or the added dependicy to libXp.so.
And noone ever complained about the detail that libXaw depends on the
SHAPE extension (which cannot be turned off without breaking libXaw,
too).
2. Link libXp.a _statically_ into libXaw (the complains about the size
increment aren't valid - as I wrote a while ago we're talking about 25Kb
on x86 - which is _litte_ compared to the size increment of libX11
between X11R6.6 and current X11R6.8 trunk) and only build the print
support in the demo applications if a new switch has been set to |YES|
3. Bump libXaw's shard library major version number to "8". That would
give people the choice to ship both the old versions - and optionally
the new version
4. |#ifdef| out the XawPrintShell support in libXaw but keep the symbols
intact. Missing print shell support in libXaw is indicated via setting
the Xt class pointer of XawPrintShell to |NULL|.
5. Load libXp.so dynamically at runtime using |dlsym()|
6. Back out XawPrintShell completely (and the whole Tooltip code, too.
And don't forget to make SHAPE extension support in libXaw optional
(which will require a version bump of the shared library version number
to "8", too))
7. Split XawPrintShell into a seperate library. (But I explained already
in detail elsewhere why this is not possible: Again, for reference:
-- snip --
I already explained that (in release-wrangers I think) splitting
XawPrintShell into a seperate library will cause significant PAIN for
the distributors since they have an additional shared library to support
- which somehow collides with the argument that XawPrintShell should be
split off due resource reasons.
And AGAIN: Splitting XawPrintShell into a seperate library will make it
IMPOSSIBLE that the other widgets in libXaw can properly interact with
the print shell. Please do not look at libXaw, look at Motif and it's
applications and how the printing stuff is implemented there. Then you
can imagine in which hell we suddenly end when XawPrintShell is placed
in a seperate library.
-- snip --

I think this is pretty much clear. And rules out this option.
).

Comments:
- Personally I would favor [1] since it causes zero pain for both users
and programmers.
- Options [4] and [5] are UGLY and scream for trouble

>    If that isn't technically feasible though, I'd point out that
>    you can always add later, but removing once you've released
>    is a *lot* harder.

Right. But the XawPrintShell API is mainly a clone (with minor
enhancements) of the XmPrintShell widget class which is stable since at
least Motif release 2.1. As long as noone changes the Motif print API in
an incompatible way there will be no need to change the XawPrintShell
API. The XawPrintShell API is rock-stable.
And it's waiting for integration into the Xorg repository since a long
time. It ONLY missed X11R6.7 because I didn't had the time to do so and
was quickly added after the tree was open again for new commits.

>    In any case, we should make sure there is a plan for
>    the next release for moving Xaw development out of the
>    line of fire for the main release.

What do you mean with "main release" ?

>  - It's unfortunate that people weren't paying enough attention
>    early in the process, but these things happen. Any realistic
>    freeze policy needs a mechanism for exceptions.

I wish there would be a policy like Mozilla.org has: All patches get
explicitly reviewed by a fixed list of reviewes and superreviewers (or
review+2nd review) and changes after the freeze go only "in" after they
got "approval" by the release management. Freedesktop.org's bugzilla is
ready for that, the thing needed would be a consens by the Xorg Board to
make such a policy mandatory.

----

Bye,
Roland

P.S.: Just to quote it here: the backout of XawPrintShell and in the X11
demo application did some damage to the demo applications - partially
non-printing related fixes were backed out, too... ;-(

-- 
  __ .  . __
 (o.\ \/ /.o) [email protected]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)