[PATCH 00/15] xserver: cleanup and standardize startup options

[Tiago Vignatti]

On Thu, Oct 28, 2010 at 08:50:54AM -0700, ext Alan Coopersmith wrote:
> Kristian Høgsberg wrote:
> > 
> > I agree, this is not something we can change.
> 
> I'm not sure I'd say none of them can change, some of the proposed patches are
> for options I'd expect few people use - unfortunately we have no way of knowing
> the real world usage of these and how widespread or unused they are.
> 
> Certainly for the ones we know people use, a sudden "flag day" approach where
> one day the old option works and the next day the new one does, with no
> transition in the middle where both work, is not a very friendly way to do it.
> 
> A "developer friendly" approach would leave enough of a transition that you're
> not likely to get broken every time you git bisect or switch from master to
> the 1.9 branch to check your backports.
> 
> A "distro friendly" approach widens that so that distros don't have to have
> complex constraints on their packaging, enforcing that if you install Xorg <=
> 1.9.x you get an old version of their display manager config package and if you
> install Xorg >= 1.10 you get the new version and the two must be kept strictly
> in sync.
> 
> A "user friendly" approach doesn't just take your existing config and return
> "Fatal error: invalid option", but "Warning: +extension is deprecated, change
> your config to -extenable" in one version, and "Error: +extension has been
> replaced by -extenable" in a later release.

thanks for the clarification, Alan. Very clever words!


While I do agree with most of your thoughts above, I want also to make clear
that part of this is due the lack of standardization in our development, in
which we suffers for awhile. 

Examples? We have XRandR but didn't deprecate XVidExtension; analogue story
for other extensions (e.g. xinerama, twinview, mergedfb confusion);
open-source drivers don't have any policy to whichever version of the server
it has to be compatible (think dropping XAA now); X is meant to be portable
but it's not based in any standard that I can step when I'm developing (like
POSIX); do we accept hw direct access or not (libpciaccess adoption Vs. old
modules like int10, vbe, linux video mapping and others). Well, I guess people
could help me with a bunch of others examples...

The main problem for me in not having a given mean to deprecate stuff (or keep
old compat in place), is that it makes the whole development process slow, in
a way that doesn't fit for my needs - discouraging X in handhelds (I mean, why
in hell I have to support 53 X debian packages right now?). On the other hand,
churn and rush with the development is not necessarily what enterprises
distributions (Solaris, Red Hat and some other Linux distributions mainly)
want - well, the money they get come from customers using old and stationary X
applications that they have to support for 10 years or so. They are happy with
the slow velocity that the process of development is being driven. Therefore,
having a policy to define what goes inside the FOSS X11 implementation is IMHO
a way to improve this situation... I'm totally opened and would like to hear
suggestions how to do so.

Anyway, I'm attaching the discussion we had on #xorg-devel regarding this, for
future references.

 
And I'm tired.


--- IRC log for #xorg-devel 2010-10-29 ---

07:27 < dottedmag> vignatti: I'd propose making a lengthy and cryptic shell
"Xorg" wrapper which mangles all the existing options and calls Xorg-sane with
sane ones.
07:29 < krh> vignatti: if you're going to break the option syntax you better
use a generic option parser than keeping the hand crafted nightmare we have
now
07:29 < krh> but I agree with alanc, you can't change this
07:31 < vignatti> damn, do we really need to keep a compatibility there?
what's the point?
07:31 < ajax> upgrade Xorg but not gdm and now your server doesn't start.
07:31 < krh> countless scripts and os integration that you can't change
07:31 < krh> there's no point
07:32 < dottedmag> vignatti: you know, every distro in the world contains
dozen of different scripts which run X.
07:33 < dottedmag> Not even mentioning thousands of scripts crafted by
sysadmins.
07:33 < vignatti> yeah yeah yeah, I agree with you... but, still, those
options are just pointless!
07:33 < ajax> they sure are.
07:33 < dottedmag> vignatti: make a shell wrapper.
07:33 < vignatti> dottedmag: oh dear
07:33 < krh> vignatti: if you want to change X, call it something else
07:34 < vignatti> would be another version of X. sysadmins, gdm-users, whoever
will need to updated it
07:34 < vignatti> I don't really understand why you guys are defending such
argument
07:35 < krh> vignatti: if your change cut the size of Xorg in half or made it
twice as fast, it'd be worth considering
07:35 < krh> but all it does is break things
07:36 < remi|work> vignatti, with my distro hat on, I tend to agree with krh
07:36 < remi|work> there are hundreds of ways, possibly more unknown to us, to
start X
07:36 < vignatti> krh: we're in the jenga tower we are right now because no
one cared some years ago about cleanup and code design. I don't want to keep
going towards the disaster direction
07:36 < dottedmag> vignatti: options parser is not really important
07:36 < vignatti> remi|work: yes, and I want to simplify it
07:37 < remi|work> custom initrc scripts, livecd shells, countless DMs
07:37 < vignatti> dottedmag: simplication is important, yes.
07:37 < dottedmag> vignatti: if you want to make world better, add a logging,
so every obsolete option would result in warning.
07:37 < dottedmag> And then 10 years later we probably could drop unused ones.
07:37 < vignatti> dottedmag: lol
07:37 < ajax> if you want to make the world better, go work on memory usage or
performance...
   ck of "obsolete, never use this idiotic API again" warnings.
07:38 < dottedmag> Both inside the server and as a result of using deprecated
requests.
07:39 < remi|work> vignatti, right now, people are using all sorts of X
options because X isn't completely automagic
07:39 < ajax> dottedmag: yeah, well, it's nice to be right and all, but it
doesn't really change what we have to support.
07:39 < dottedmag> Agreed.
07:40 < dottedmag> vignatti: still, I think nobody will object if you add
warnings.
07:40 < ohsix> speaking of X options, i miss the checker pattern
07:40 < remi|work> ohsix, -retro
07:40 < vignatti> dottedmag: the problem is that redhat and oracle don't want
changes - they have their customers using _very_ old X11 clients (using Xt,
etc) and they don't want big jumps
07:41 < ohsix> remi|work: i know it was a joke :] i remember the threads about
it
07:41 < vignatti> now the problem is that we, doing embedded, wanting to add
features as fast as hell, want rush the development
07:41 < dottedmag> vignatti: who cares about old X11 clients?
07:41 < vignatti> dottedmag: alanc and ajax
07:41 < ohsix> X12
07:41 < dottedmag> vignatti: no. I mean why should *you* care about old X11
clients?
07:42 < dottedmag> vignatti: there is some code. It does not
07:42 < ajax> vignatti: help me out.  how does removing cli options you don't
use make it easier to add your embedded features?
07:42 < dottedmag> preclude you from doing any stuff you want.
07:43 < dottedmag> vignatti: and 500 bytes of machine code is not a price for
dropping such massive amount of compatibility
07:43 < vignatti> ajax: dude, if you care about code design you might now. But
_this_ one in particular is nothing, I agree
07:43 < dottedmag> vignatti: so let's just stash it.
07:44 < vignatti> dottedmag: wrapper?
07:44 < vignatti> :)
07:44 < dottedmag> vignatti: whole patchset
07:44 < vignatti> :(
07:45 < ajax> vignatti: just saying, try to avoid moving the goalposts.
07:46 < vignatti> ajax: speak english for foreigners, please.
07:46 < ajax> "moving the goalposts" is a debate technique in which you start
arguing about topic A, and then when it's refuted, start talking about topic B
instead
07:46 < remi|work> vignatti, don't break X for the rest of U
07:46 < remi|work> *us
07:47 < ajax> in this case, you've started with "why do we need all this cli
compatibility" and then tried to tie it to the larger symptom of "old X
clients need to keep working"
07:47 < vignatti> ajax: right, I get it
07:48 < vignatti> but it's always the same - when I want to move a bit faster
there always someone nagging about pointless compatibility
07:48 < remi|work> vignatti, and we're telling you this bit isn't pointless
07:48 < ajax> pointless for you, maybe.
07:48 < remi|work> in *this* case
07:49 < krh> vignatti: look, X is terrible for embedded systems and X is also
a museum piece that you can't change
07:49 < krh> if you're using X you gotta take the whole package
07:50 < krh> if you want to make incompatible changes and move forward "fast
as hell", I have a project that might intereset you
07:50 < remi|work> vignatti, I would *love* it if X used getopt or some other
standard arg parsing mechanism, but it's just not going to happen with the
original "X" program
07:50 < vignatti> krh: :)
07:50 < vignatti> remi|work: it could advance though, because would keep the
compat
07:51 < remi|work> it *does* advance, take a step back
07:55 < antrik> I find it interesting that the same people who argue the
importance of command line compatibilty insisted on gratuitously changing the
default startup behaviour...
07:58 < vignatti> antrik: you see!? :)
---

             Tiago