Re: xinit-1.3.4-1: breaking backwards compatibility

Re: xinit-1.3.4-1: breaking backwards compatibility

[Angelo Graziosi]

Laurens Blankers wrote:
> Then I drag the X icon to my
> Start-up folder, so that it starts every time my desktop boots

The same you can do with the link created as suggested in my previous 
replay. When I had Win XP I did that way for almost 7 years without 
tacking care of any configuration and/or xinit upgrade. Now with Win7 I 
don't use much X so I have left the link on the task bar and start it 
manually when I need X.


Ciao,
  Angelo.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: xinit-1.3.4-1: breaking backwards compatibility

[Laurens Blankers]

On 30-12-2014 17:04, Angelo Graziosi wrote:
> The same you can do with the link created as suggested in my previous
> replay.
You are probably right, but again, that is not the issue. The point I am
trying to make is that breaking configurations which have worked for
many years in a patch release is very bad practice.

Laurens

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: xinit-1.3.4-1: breaking backwards compatibility

[Angelo Graziosi]

Laurens Blankers wrote:
> I noticed that updating to the latest xinit (1.3.4-1) from the previous
> one (1.3.2 I believe) completely breaks existing configurations.

What about changing the way X server is started? I flagged here:

   https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html

my experience with which I have no problems. But it may be that you have 
other needs which require starting X differently..


Ciao,
  Angelo.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: xinit-1.3.4-1: breaking backwards compatibility

[Laurens Blankers]

On 30-12-2014 13:46, Angelo Graziosi wrote:
> What about changing the way X server is started?

I could change the way I start X, and I have successfully gotten things
to work by doing so. But that is not my point. My point is that I need
to make significant changes to the configuration to get back to the
functionality that used to work.

> But it may be that you have other needs which require starting X
differently.

I will describe my use case: I use PuTTY to connect to several Linux
servers, sometimes I need to run a X11 program on those servers (e.g.
virt-manager) and I would like to get the output on my Windows desktop.
In order to do that I install Cygwin, check the xinit package, wait till
everything is installed. Then I start X server using the icon in my
Programs menu. The first time an annoying xterm window pops up, which I
suppress by running 'touch .startxwinrc'. Then I drag the X icon to my
Start-up folder, so that it starts every time my desktop boots and sits
in the tray area, where it doesn't bother me, ready to be used when needed.

With this update the X server fails to start, well actually it starts,
but exists immediately because .startxwinrc is empty. But there is no
error message, or warning, or something to tell me this. So it took me
30 minutes to figure this out. After fixing it (sleep inf) I now have a
very annoying icon on my taskbar representing the .startxwinrc which is
still 'running'.

Once I got that figured out I started PuTTY. But things didn't work. As
it turns out this is because of the nolisten, which is now the default.
A workaround suggested is to use 'ssh -Y' in stead of 'ssh -X', but I
don't use SSH I use PuTTY and it doesn't support 'trusted' X11
forwarding. So to fix this I would have to go and change the startxwin
script, a change which will be reverted every time I upgrade.

Once I figured this out I just reverted back to the previous version of
xinit and went on to do the things I wanted to do.

Now, I am not against changing the way things work. I am definitely not
against making the default more secure. And I think it is perfectly fine
to have things change when people install Cygwin fresh.

However _please_ think of all the people who just upgrade for the
bug/security fixes and just want things to work. Ideally there should be
an automatic script that sets things up for us automatically so that
everything works as we were used to (e.g. automatically adding 'sleep
inf' to the end of .startxwin might do). And at the very least the
changes should be clearly documented, preferably a pop-up when
installing the update, but at the very least a notice on the main
website and FAQ. Posting an announcement to a mailing list with a
details list of changes from which one may infer that things completely
break just doesn't qualify as proper documentation in this case.

I would like to reiterate my request to revert these changes, e.g. by
releasing a 1.3.6 which is identical to 1.3.2, so that people like me,
those not normally following cygwin-xfree can continue to work.

Laurens


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

xinit-1.3.4-1: breaking backwards compatibility

[Laurens Blankers]

I noticed that updating to the latest xinit (1.3.4-1) from the previous
one (1.3.2 I believe) completely breaks existing configurations.

The changes have been mentioned in the release announcement:

https://cygwin.com/ml/cygwin-xfree/2014-11/msg00029.html

And numerous posts have since reported bugs regarding these changes. For
most a workaround has been provided, except for the 'icon in the
taskbar' issue.

I would like to express my wonder and dismay that such a seamingly minor
version change includes functionality which completely and utterly
breaks many, if not most, existing configurations. I am not sure what
versioning strategy is being used for Cygwin/X but I would like to call
attention to the semantic versioning standard (currently version 2.0.0):

http://semver.org/

Signalling this major change by increasing the major version number of
the xinit package (e.g. 2.0.0) would have made it a lot clearer what the
impact of the change would have been.

I would also like to call attending to the following FAQ item from the
same website:

Q: What do I do if I accidentally release a backwards incompatible
change as a minor version?
A: As soon as you realize that you've broken the Semantic Versioning
spec, fix the problem and release a new minor version that corrects the
problem and restores backwards compatibility. Even under this
circumstance, it is unacceptable to modify versioned releases. If it's
appropriate, document the offending version and inform your users of the
problem so that they are aware of the offending version.

I would like to kindly request that this change is reverted, at least
until the time that a proper and documented upgrade path is available.

Now please don't take this the wrong way. Although I realize some
probably will. I do appreciate all the time that everyone, and not in
the least Yaakov, invests into maintaining Cygwin/X. However as a user
and software engineer myself I also very much appreciate systems
continuing to function after minor upgrades.

Sincerely,

Laurens Blankers


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/