[bugzilla-daemon@freedesktop.org: [Bug 3080] libdps and libdpstkare obsolete and should be removed]

[Daniel Stone]

On Thu, Apr 21, 2005 at 02:52:04AM +0200, Roland Mainz wrote:
> Daniel Stone wrote:
> > There is a debate on bug#3080 (link inline) about removing DPS.  Roland
> > has asserted that since large UNIX vendors still ship DPS, we must ship
> > DPS also, despite the complete lack of a server-side implementation, and
> > that the upstream author has marked the project as abandoned for years
> > now.  It has been deprecated since XFree86 4.3, released in 2003.
> 
> Erm... Daniel... it would be nice if you would not reverse the facts
> here:
> 1. Only the DPS client side implementation of Julienz is abandoned for
> years, all the other implementations in AIX, HP/UX, Solaris etc. are not
> marked as depreciated (yet (see Alan Coopersmith's comment in the bug))

I would say a very definite statement saying 'this is going away in a
release or two' is a very good example of deprecation, wouldn't you?

Deprecation doesn't necessarily involve the code going away.  A
statement that the code is going away and thus should not be relied
upon is deprecation.

> 2. There is no common "upstream", DPS is mainly coming from Adobe and
> dps.sf.net was just an opensource implementation - one of many...

What Adobe does does not matter to us.  Xorg is an open source project.

Closed source libraries have no bearing on us: what Adobe does with DPS
has about as much bearing on us as DirectX, as long as they're not
releasing the source.

> 3. Unix vendors still ship server-implementations of DPS - and the
> client side should IMO removed _after_ the server side is gone
> everywhere else. Otherwise we may end-up in the interoperability
> catch-loop (how is that called in english - catch22, catch66... ?)

Catch-22.  I think this is only valid if there is a large userbase:
people expect that they can download any random X implementation,
install however many libraries and base clients it provides, and have
DPS apps work.  I do not think this is true.  DPS is a very specialised
niche used by very, very few apps (hence the deprecation by the very few
people who still ship it).  The people still using it can surely go to
dps.sf.net (or Adobe or whatever, since they're still DPS upstream,
apparently), and download it, no?

> 4. I never said "we must ship DPS also, despite the complete lack of a
> server-side implementation". My primary point is the way how the removal
> attempt is handled, not that DPS should not go away.

I must have misunderstood you here; sorry.

> 5. Could you please cite the Xfree86 release annoucement whidch declared
> DPS as obsolete for all X11 implementations ? AFAIK there is no such
> thing (yet... given the current debate it may be nice to stuff something
> like that into X11R6.9/X11R7.0). Note that there is also a huge
> difference between Xfree86 and Xorg - Xfree86 was AFAIK always only one
> implementation of X11 (of many) while Xorg is now the sample
> implementations (SI) for all X11 versions so any annoucements for
> depreciation in Xfree86 only apply to Xfree86 and not Xorg.

http://web.archive.org/web/20030208100612/http://dps.sourceforge.net/

Somewhere between November 19th, 2002, and February 8th, 2003, Juliusz
changed and put a huge notice on dps.sf.net stating that the entire
project was now deprecated.  Given that he was the guy handling DPS for
XFree86, that would be a statement from XFree86.  So, February 8th,
2003.  That's two years, two months, and thirteen days ago.  That's
four and a third X.Org release cycles.  Hm.

As for your XFree86 vs X.Org stuff, please be realistic here.  While
X.Org was stagnant after the licence disaster, XFree86 was effectively
*the* SI.  Xorg's heritage is from XFree86, and we cannot forget that.

Xorg is the XFree86 codebase with (mercifully) an entirely different set
of people and organisation behind it.  So please dispense with the 'it
doesn't apply to us' rhetoric, because we took their code and we're
running with it.

> > Does anyone have any realistic objections as to the removal of libDPS
> > from the monolithic tree,
> 
> My objection here is that Xorg should finally use a professional way to
> annouce that a feature on the Xorg tree (and default build) is going
> away in future releases in it's own documentation as one of the main
> documentation items. I am finally sick of the permanent bending of the
> rules while citing other cases where the rules were bend, too. At some
> point there should be a clear definition of "how to remove things from
> a) the default build and b) from the source repository".

This is a terrible argument, and I'll tell you why.

Person A adds useless library and complimentary sample applications to
the tree that no-one wants to support.  Person A keeps adding more and
more applications, and the whole thing snowballs, even if there isn't a
very large community behind it.

A release happens; everyone is too busy to notice and/or care.

Persons B, C, and D, say 'hold on, how did this get in?  What is this
doing here?'.

Person A says 'well, it's been released, and now you have to follow the
procedures'.

Persons B, C and D initiate the procedure for removal and in the
meantime, X.Org spends its time supporting stuff no-one wants to, and
the tree is massive.

In the middle of these release cycles, the entire process is repeated,
and eventually the source tree is huge.

Do you see the problem here?  If we're to have a 'professional' formal
process with a committee or something, then we need to have equally
difficult and stringent standards for *adding* things.  Else people are
just going to use X.Org as a dumping ground for crap that they couldn't
be bothered finding anywhere else for, and we're going to end up
supporting so much stuff that it's utterly unsustainable.

To me, DPS is very clear-cut.  The userbase is miniscule, there is *no*
open source implementation of the server side, it has been marked as
deprecated and unsupported by both XFree86 (and implicitly X.Org, since
no-one did a single thing to change the status quo -- and, as much as
you protest, it was the status quo), and its sole upstream author.

I don't know what else you want for a removal process.  If you want a
committee, then that committee (useless as it would be) cannot just be
for removing code -- it must also be for adding code.

But I don't think anyone really wants that committee, so let's move on.

> AFAIK originally in the Xorg Consortium times this was handled via 1)
> Annouce the removal in the release notes 2) remove the feature from the
> default build in the following release and then 3) remove it from the
> sources in the following releases.

We are not the X.Org Consortium.  Thankfully.

> There should be a clear way how users/customers of the Xorg tree can
> watch the changes and adopt to them. Immediate removal of features
> without warnings isn't considered very professional. And for DPS it's
> IMO important as DPS was once a major feature in X11 and it's removal
> should be handled therefore carefully (and the removal of PEX cannot be
> cited there as PEX was not building at the time it was removed. DPS
> still builds (and Daniel... please... don't run around and hack the code
> until it does not build anymore... this kind of argumentation is
> childish...)).

I'm honestly incredibly tired of you accusing me of sabotaging the tree.

If you want to accuse me of sabotaging the tree, ask for the removal of
my access (doubly so as I have root on freedesktop.org).  Otherwise,
please leave this kind of stupid nonsense at home and grow up.

> > given that a) there is no server-side
> > implementation, and b) it has been abandoned upstream for some time
> > now.
> > 
> > The upstream code still builds,
> 
> Which is not true. There is a) no common "upstream" and b) the sources
> at dps.sf.net lack the years of minimum maintaince done at Xfree86/Xorg
> and do not build anyomre out of the box (yes, I know... you can hack
> them until they're working - but that is not the same).

Is it telling that no-one upstream cared enough to merge this?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-arch/attachments/20050421/eda3519b/attachment.pgp