public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Yaakov Selkowitz <yselkowitz@cygwin.com>
To: cygwin-xfree@cygwin.com
Subject: Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3
Date: Mon, 05 Jan 2015 09:49:00 -0000	[thread overview]
Message-ID: <54AA5E05.2040600@cygwin.com> (raw)
In-Reply-To: <54AA5429.1090907@blankersfamily.com>

On 2015-01-05 03:06, Laurens Blankers wrote:
> On 5-1-2015 05:04, Larry Hall (Cygwin-X) wrote:
> As far as I can tell, from the available information, users which meet
> any of the following criteria will run into trouble:
>
> - Custom .startxwinrc or .xinitrc

Just .startxwinrc, and the changes were explained in the announcement.

> - Using untrusted X11 forwards over SSH (e.g. ssh -X or PuTTY)

ssh -X hasn't been supported since X11R7.4 way back in 2008 (see the FAQ 
for details).

> As a software engineer I strongly believe in the principle of least
> astonishment [2]. At least for the vast majority of users. In this case,
> in my opinion at least, that would mean that changing the behaviour of
> startxwin should be done in such a way as to provide a seamless way of
> users to upgrade. Preferably by maintaining compatibility with existing
> configurations, or by automatic conversion, or, if necessary through a
> well documented manual transition process.

That's what the announcement was for.

> What I am trying to say is that I don't object to your solutions, but I
> would really like this to be solved in a way that provides a create user
> experience. For me that would mean that the first step would be to
> retract the update (revert back to 1.3.2-1) as to prevent more users
> from running into problems. I do realize that that would mean forcing
> people who have already converted to go back. But I assume this is a
> minority of users. Then I would propose to evaluate what could be done
> to provide a smooth transition, possibly over a longer time, popping up
> increasingly annoying warnings about the configuration, for example.

I am not going to revert the recent changes, which are important and 
long overdue.  If any has constructive suggestions for incremental 
improvements thereto, they will be duly considered, but going backwards 
is not the solution.

>> So I withdraw my previous request that you not post
>> your policy question to the Cygwin main list (since I agree it is a
>> general issue) but instead request that you only discuss the policy and
>> not overlap with the specifics covered in the xinit package threads [..]
>
> Thank you, I would like to discussion on the general list to be broader.

That won't be necessary.  As a rolling distribution without stable 
releases, these kind of changes in UX happen from time to time.  That's 
what announcements are for.


Yaakov


--
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/


  reply	other threads:[~2015-01-05  9:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02 20:11 schilpfamily
2015-01-02 20:21 ` Laurens Blankers
2015-01-02 20:35   ` schilpfamily
2015-01-03  3:49     ` Larry Hall (Cygwin-X)
2015-01-03  8:04       ` Laurens Blankers
2015-01-03  9:25         ` rcunningham
2015-01-03 23:02         ` Larry Hall (Cygwin-X)
2015-01-04 11:41           ` Laurens Blankers
2015-01-05  4:04             ` Larry Hall (Cygwin-X)
2015-01-05  9:07               ` Laurens Blankers
2015-01-05  9:49                 ` Yaakov Selkowitz [this message]
2015-01-05 10:03                   ` Laurens Blankers
2015-01-05 10:34                     ` Yaakov Selkowitz
2015-01-06  4:19                 ` Larry Hall (Cygwin-X)
2015-01-12  0:26   ` solution for package startup scripts changing: do your own (was Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3) Linda Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54AA5E05.2040600@cygwin.com \
    --to=yselkowitz@cygwin.com \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).