Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]: > On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote: > > Judging from the conversation, killing i386 quite obviously is desired > > by some participants, but evidently not by all. How quickly we want to > > kill it is not obvious to me. > > When considering the future of i386, a factor that we need to bear in > mind is that there are two major use-cases for i386, with requirements > that sometimes conflict: > > 1. i386 as a fully-featured architecture that you can run independently > on 32-bit x86 systems from roughly the 2000-2010 era > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > modern x86_64 systems > 2a. legacy native Linux i386 binaries > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat > complete i386 Linux library stack) > (...)
I completely agree with your analysis here, and I agree we should strive to keep 2a and 2b covered, as they are (and they will be, every time by a bigger margin) by far more common and productive than 1. I agree with your assessment that date woes will be minor for the i386 user than incompatibility woes going forward; there is the possible case of people running I-don't-know-which proprietay productivity tool provided as a binary that cannot be convinced of a 64-bit time_t that will receive errors when the timeocalypse approaches, but I guess the gaming use cases will be much more frequent than that; even though your vision might be somewhat skewed by the fact that you work in Steam, it makes complete sense. Of course, given our i386 users would be running (>10 years for now) a Debian architecture used mostly for compatibility with old non-free binaries, we'd have to think whether it makes sense to provide a full Debian experience (i.e. you don't want i386 users to have a PostgreSQL with a known-borked time implementation storing important information in it -- and of course, this is only the first of too many examples that comes to my mind, but won the race to get to my fingers 😉) But anyway, back to what matters here: I support Helmut's idea. I have long thought we fear the GR process too much, and we should excercise it more. Not every GR has to be a flamefest. Having a clear statement of what is being voted on, and the possible consequences on each of the options, can lead to a civil, useful way to measure the opinion of project members interested in the subject. Right now, I imagine a ballot similar to: The future of i386 in Debian from Trixie onwards A. Drop support of i386 completely B. Keep support of i386 as a multiarch-foreign arch, with 32-bit time_t C. Keep support of i386 as a multiarch-foreign arch, with 64-bit time_t D. Commit to supporting i386 as a full-featured arch, with 32-bit time_t E. Commit to supporting i386 as a full-featured arch, with 64-bit time_t F. Further discussion I know this woul conflate two decisions in one ballot, but arguably they are part of the same issue. I do not feel qualified to draft the full vote, as I have not followed the discussion as closely as I'd like to and I'm not directly affected anyway, but would be very happy to second it. FWIW, I believe the only real danger in having non-controversial GRs would be that a vote does not reach quorum (48 voters in the last GR), but I don't believe it is a real danger to worry about; in any case, failure to reach quorum would mean the project does not _mandate_ a decision, but it can be anyway implemented by porters / RT.
