The libdps and libdpstk libraries are ancient and should be removed from CVS head. The DPS X server extension is not included with Xorg or XFree86 and wont ever be. There was an open source DPS extension project on sourceforge at http://dps.sf.net by Juliusz which is officially abandoned now. We might as well disable this and remove it. Now is as good a time as any.
the dpsexec, dpsinfo, and texteroids programs should be dropped at the same time.
mharris: 1. About the default build: Most Unix versions still ship with DPS and it would be nice it Linux keeps it for a while until the other Unices have removed it from their OSes. 2. The source code should NOT be removed until after two releases where it has been turned off in the default built.
No. DPS was not included in 6.6. We picked it up from XFree86 when we did the 4.3.99 import, and Juliusz had already declared it deprecated by then, on 8 February 2003 if the Wayback Machine is to be believed: http://web.archive.org/*/http://dps.sourceforge.net/ XFree86 4.3.0 was released on 27 February 2003, so there have already been two major releases in which DPS has been formally deprecated. If other platforms still need it, it's still available from http://dps.sourceforge.net/ . Our version is not materially modified from the upstream source, so there is no reason for us to keep it. I'll take this one.
(In reply to comment #3) > XFree86 4.3.0 was released on 27 February 2003, so there have already been two > major releases in which DPS has been formally deprecated. excuse me, 3 releases: 4.3, 6.7, and 6.8.
+1 for removing it. There is no useful implementation in the Xorg tree, and never will be; it's been marked deprecated and utterly useless for a very long time. In the event that people actually need the stuff, they can get it from upstream (who's abandoned it).
(In reply to comment #5) > +1 for removing it. There is no useful implementation in the Xorg tree, and > never will be; it's been marked deprecated and utterly useless for a very long > time. In the event that people actually need the stuff, they can get it from > upstream (who's abandoned it). dps.sf.net is not the upstream, it's just one implementation. DPS is coming from Adobe, however Xorg is now the upstream for the client side which is still compileable with the Xorg stuff. I'd like to follow the normal rules for depreciation in this case - which means: 1. X11R7.0 gets a note about that the DPS client side is depreciated 2. Post-X11R7.0 the code gets disabled in the default build 3. Two releases after X11R7.0 the source gets removed unless there are objections These are AFAIK the normal rules for depreciation in the Xorg tree. Please follow them.
Created attachment 2488 [details] [review] kill-dps-1.patch in addition, the following directories need their contents cvs removed: config/pswrap programs/{makepsres,dpsexec,dpsinfo,texteroids} include/DPS lib/{dps,dpstk,psres} this drops about 60k lines of dead code totalling around 2.2M.
Comment on attachment 2488 [details] [review] kill-dps-1.patch Note: This patch cannot land until after X1R6.7.0 has been released (unless xorg-arch explicitly decides it otherwise).
> I'd like to follow the normal rules for depreciation in this case - which means: > 1. X11R7.0 gets a note about that the DPS client side is depreciated > 2. Post-X11R7.0 the code gets disabled in the default build > 3. Two releases after X11R7.0 the source gets removed unless there are objections > These are AFAIK the normal rules for depreciation in the Xorg tree. Please > follow them. i don't feel that "the normal rules" apply here, because this code was deprecated when we started shipping it. we didn't wait two release cycles to deprecate PEX, we just said "this is unused, unmaintained, and bad" and we nuked it. DPS has been formally abandoned for three major releases now, regardless of its inclusion in the default build. i don't think it's correct to conflate deprecation with default build status.
(In reply to comment #9) > > I'd like to follow the normal rules for depreciation in this case - which means: > > 1. X11R7.0 gets a note about that the DPS client side is depreciated > > 2. Post-X11R7.0 the code gets disabled in the default build > > 3. Two releases after X11R7.0 the source gets removed unless there are objections > > These are AFAIK the normal rules for depreciation in the Xorg tree. Please > > follow them. > > i don't feel that "the normal rules" apply here, > because this code was deprecated when we started It was not depreciated when the new Xorg foundation started. That was only Juliusz statement on dps.sf.net. All bug Unix vendors still ship the DPS server+client side with their Unices and this is mainly what counts here. > shipping it. we didn't wait two release cycles to deprecate PEX, PEX was abadoned since three years by all big unix vendors at that point. That's a difference to the DPS status where the big Unix vendors still have it in their portfolio. > we just said "this is unused, > unmaintained, and bad" and we nuked it. Yes... and it was afterwards said that this procedure was a bad way to handle code removal that way. It was considered risky and unprofessional. For PEX it did fortunately harm noone anymore since the PEX code did not build anymore. But DPS is still in active (but rare) usage so it may be better to go the official path for depreciation here to avoid any customer complains. > DPS has been formally abandoned for three major releases > now, regardless of its inclusion in the default build. This was AFAIK not annouced in the Xorg documentation (the comments on dps.sf.net do not count here) ... > i don't think it's correct to conflate deprecation with default build status. Erm... the code still compiles and works. My first question is: Why the h*ll to you bother to get rid of it ? As long it works&&compiles noone gets harmed...
I'll CC:'ing Paul Anderson here for the issues with depreciation...
> Yes... and it was afterwards said that this procedure was a bad way to handle > code removal that way. It was considered risky and unprofessional. > For PEX it did fortunately harm noone anymore since the PEX code did not build > anymore. But DPS is still in active (but rare) usage so it may be better to go > the official path for depreciation here to avoid any customer complains. tell me again why the unix vendors who still require DPS as part of their shipping software suite can't go get the identical code from dps.sf.net. > > DPS has been formally abandoned for three major releases > > now, regardless of its inclusion in the default build. > > This was AFAIK not annouced in the Xorg documentation (the comments on > dps.sf.net do not count here) ... why does the official position of the maintainer and primary author not count? > Erm... the code still compiles and works. My first question is: Why the h*ll > to you bother to get rid of it ? As long it works&&compiles noone gets > harmed... no, it is harmful. unless you're suggesting that continuing to include copies of ugly, unmaintained, and basically unused software - readily available from external sources and actively deprecated for over two years - is a good thing.
(In reply to comment #12) > tell me again why the unix vendors who still require DPS as part of their > shipping software suite can't go get the identical code from dps.sf.net. The code is not identical. dps.sf.net's code lacks at least several years of the minimum maintaince done at Xfree86/Xorg. The code there does not build while ours does. > > > DPS has been formally abandoned for three major releases > > > now, regardless of its inclusion in the default build. > > > > This was AFAIK not annouced in the Xorg documentation (the comments on > > dps.sf.net do not count here) ... > > why does the official position of the maintainer and primary author not count? Because it's part of the Xorg distribution and we should follow our own guidelines to make consumers of our software aware of removal of features far far ahead before doing so. Otherwise the RENDER extension should be removed as long ago there was an annoucement that RENDER is bad and should go away. Not every rumor you can find in the internet is something usefull... > > Erm... the code still compiles and works. My first question is: Why the h*ll > > to you bother to get rid of it ? As long it works&&compiles noone gets > > harmed... > > no, it is harmful. unless you're suggesting that continuing to include copies > of ugly, unmaintained, and basically unused software - readily available from > external sources and actively deprecated for over two years - is a good thing. The complaint from my side here is that we permanently bend the rules and cite earlier times where the rules were bend, too. At some point this silly behaviour should end and strict rules should be honored. Long ago DPS was considered a major feature in X11 and all of the big unix vendors had to implement it to match the customer demands. If such things which were once big&great in X11 should be killed off the tree then at least a professional way of removal should be chosen. BTW: I do not have anything against the DPS removal but I have strongly something against the way it's attempted here - silent and underground-style. It should be announced officially in the Xorg release notes for X11R7.0, then the code gets disabled in the default build for X11R7.1 and in X11R7.2 you may remove the sources if there are no complaints (which means: it shouldn't be killed if there are still users of it...).
Unix vendors who ship DPS got the code from Adobe. Adobe itself has dropped DPS, so there is no common upstream anymore. (As for this "big Unix vendor," while we still ship DPS support in Xsun, we have not and will not port it to our Xorg server, which is the direction we're heading. Whether we officially drop support for DPS by itself or just wait to drop support for Xsun as a whole is yet to be determined.) As for killing it, I'd lean towards the path of least work: leave it in the 6.9/monolithic tree, but set to not build unless explicitly requested and then never port it to the 7.0/modular tree. If anyone out there really truly desperately still cares, they can modularize it and have space for it on freedesktop, but it won't be included in any official set of Xorg 7.0 packages. And I'm curious where this "rule" of "announce first, wait two releases, then drop" is coming from - I don't remember ever hearing such a rule before, and since the only previous code removals were done without prior announcement for the 6.7 release, it doesn't seem we've followed it. I would agree that the xorg-arch board should approve any deprecation or removal of code that has shipped in prior releases, but I think a simple e-mail discussion should suffice.
> > why does the official position of the maintainer and primary author not count? > > Because it's part of the Xorg distribution and we should follow our own > guidelines to make consumers of our software aware of removal of features far > far ahead before doing so. as stated earlier, its inclusion in 6.7 was purely a result of cloning from xfree86, who had already declared it deprecated. > Otherwise the RENDER extension should be removed as > long ago there was an annoucement that RENDER is bad and should go away. Not > every rumor you can find in the internet is something usefull... unless the person who made this announcement was Keith Packard, this analogy doesn't apply. > The complaint from my side here is that we permanently bend the rules and cite > earlier times where the rules were bend, too. At some point this silly behaviour > should end and strict rules should be honored. this analogy doesn't apply either, unless you can think of other things in 6.8 that are uniformly declared obsolete by their primary authors that we're continuing to ship anyway. > BTW: I do not have anything against the DPS removal but I have strongly > something against the way it's attempted here - silent and underground-style. i don't feel that any discussion that happens on bugzilla can reasonably be called silent or underground. there's a reason we open bugs, attach patches, wait a few days, then commit: so discussions like this can happen.
(In reply to comment #15) > > > why does the official position of the maintainer and primary author not count? > > > > Because it's part of the Xorg distribution and we should follow our own > > guidelines to make consumers of our software aware of removal of features far > > far ahead before doing so. > > as stated earlier, its inclusion in 6.7 was purely a result of cloning > from xfree86, who had already declared it deprecated. Xfree86 is just one single vendor and not Xorg which represents many vendors. Annoucements for depreciation of a feature from a single vendor should not affect all other vendors. But the Xorg tree is the topmost upstream and does not inherit any depreciation notes done by a vendor by default (that was AFAIK more or less the definition how the X11 Consortium handled such issues). > > Otherwise the RENDER extension should be removed as > > long ago there was an annoucement that RENDER is bad and should go away. Not > > every rumor you can find in the internet is something usefull... > > unless the person who made this announcement was Keith Packard, > this analogy doesn't apply. The analogy applies here as Adobe did not make the annoucement on dps.sf.net - that was Juilusz. [snip] > > BTW: I do not have anything against the DPS removal but I have strongly > > something against the way it's attempted here - silent and underground-style. > > i don't feel that any discussion that happens on bugzilla can reasonably be > called silent or > underground. there's a reason we open bugs, attach patches, wait a few days, > then commit: so discussions like this can happen. The comment with "underground-style" was for the detail that the change of the default build and source removal is done within one step between two major releases without having an excplit depreciation annoucement in the Xorg release notes.
Created attachment 2589 [details] [review] kill-dps-2.patch per mailing list thread, disable DPS build by default, with the intention of not including DPS in 7.0.
applied to HEAD, closing.
Created attachment 2636 [details] [review] Doc patch to clearly delineate the planned death of DPS
Sorry, but our docs might as well be correct: "the X.Org Foundation and it's volunteers" 'its volunteers'
Created attachment 2637 [details] [review] Revised doc patch with it's/its typo fixed Whoops. Fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.