public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Jon Turney <jon.turney@dronecode.org.uk>
To: Thomas Wolff <towo@towo.net>,
	"cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>
Subject: Re: Cygwin x86 end-of-life
Date: Sun, 13 Nov 2022 17:07:33 +0000	[thread overview]
Message-ID: <12c02fd6-2a4e-842c-274a-cea9499c2457@dronecode.org.uk> (raw)
In-Reply-To: <93ad1bbe-b1a7-0133-5382-2ba7a4ccc549@towo.net>

On 12/11/2022 16:58, Thomas Wolff wrote:
> Am 12.11.2022 um 17:08 schrieb Jon Turney:
>> On 11/11/2022 20:02, Thomas Wolff wrote:
>>> Am 11.11.2022 um 20:50 schrieb Achim Gratz:
>>>> Thomas Wolff writes:
>>>>>> I plan to pause package uploads this coming Monday (2022-11-14),
>>>>>> before starting the re-organization of the package repository to
>>>>>> make this archive.
>>>>> Although expected for a while, the exact date is now a very short-time
>>>>> announcement. Can we have a moratorium for a short while?
>>
>> So, if not now, when?
> Well, first, I think it's not a good idea to change and over-interpret a 
> plan in this way. The announcement for a year or so has been "cygwin 3.4 
> will not support 32 bit anymore". This does not imply that the 
> repository will be closed so any other package would not be allowed 
> anymore to provide updates. What about security updates? Basic 
> functionality?

Security is a complete red-herring here. We are not good at making 
timely updates for that purpose, generally.  To suggest that x86 will be 
receiving security updates, when we've also said x86 is deprecated, and 
some maintainers aren't updating it at all, makes no sense at all.

The message needs to be: If you care about security, at the very least, 
don't use x86 Cygwin. This is one of the reasons why I want to archive x86.

If you think there is some broken "basic functionality" in the current 
package set, please say what it is.  If something critical is discovered 
after the freeze, I am not totally ruling out permitting an exceptional 
upload (although the case for criticality would have to be well made, 
as, again this involves yet more work for me, to benefit a small 
percentage of installations, and one would think that such critical 
problems would be evident currently).

> I think a plan to freeze the repository would need a separate and 
> explicit announcement, and some decent period from then.
>>
>> Is this actually going to cause you problems, and if so what are they 
>> specifically, or is this just a case of "change is bad"?
> Well I would certainly wish to upload a few more updates for mintty also 
> for 32 bit, and also one other package of mine, to know their 32-bit 
> packages are in a good final state. Mintty 3.6.1, for instance, has an 
> exotic crash condition to be fixed but I wouldn't like to make an upload 
> in a hurry this weekend.

>>>> That moratorium is already running for more than a year:
>>>>
>>>> https://cygwin.com/pipermail/cygwin/2021-October/249690.html
>>> That message does not announce a blocking of further 32-bit package 
>>> uploads, and not a precise date for such hard step either. So please 
>>> let's not commit a violation of the principle of least surprise.
>>
>> Sorry if this was communicated in a surprising way, but there is also 
>> another, important principle at work here, the principle of least 
>> effort, or as we might call it in this application "the principle of 
>> not inventing more work for Jon Turney to do".
> Understood, but is it really work to just not touch the repository for 
> another few weeks?

This veers between "indefinitely", "until I'm happy with my packages", 
"a decent period", "a short while", and "a few weeks", so I'm still 
unclear what you are actually asking for here.


  parent reply	other threads:[~2022-11-13 17:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cfc30991-0dd0-3308-9aca-df7cf81169aa@dronecode.org.uk>
2022-11-11 16:16 ` Jon Turney
2022-11-11 19:45   ` Thomas Wolff
2022-11-11 19:50     ` Achim Gratz
2022-11-11 20:02       ` Thomas Wolff
2022-11-12 16:08         ` Jon Turney
2022-11-12 16:58           ` Thomas Wolff
2022-11-13 13:58             ` Thomas Wolff
2022-11-13 16:43               ` Achim Gratz
2022-11-13 17:01                 ` Thomas Wolff
2022-11-13 17:07             ` Jon Turney [this message]
2022-11-13 19:17               ` Corinna Vinschen
2022-11-14 15:24     ` Andrew Schulman
2022-11-13 20:31   ` Brian Inglis
2022-11-14 16:25   ` Jon Turney
2022-11-14 17:18     ` Andrew Schulman
2022-11-14 20:16     ` Brian Inglis
2022-11-14 21:29       ` Jason Pyeron
2022-11-18 15:51         ` Jon Turney
2022-11-15 19:14     ` Erwin Waterlander
2022-11-28 13:08     ` Jon Turney
2022-11-21 12:45 Corinna Vinschen
2022-11-22 17:51 ` Brian Inglis
2022-11-22 21:07   ` Achim Gratz
2022-11-23 20:00     ` Brian Inglis

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=12c02fd6-2a4e-842c-274a-cea9499c2457@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=cygwin-apps@cygwin.com \
    --cc=towo@towo.net \
    /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).