From: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Ard Biesheuvel <ardb@kernel.org>,
dkiper@net-space.pl,
The development of GNU GRUB <grub-devel@gnu.org>,
distributions@lists.linux.dev
Subject: Re: [PATCH v2 1/6] ia64: Remove support
Date: Sun, 14 May 2023 01:31:23 -0500 [thread overview]
Message-ID: <ZGCAO_fjvH9rfDQr@dj3ntoo> (raw)
In-Reply-To: <5c434d4d76f74a0f2ac2eb6e12d5fe56eb8a05b0.camel@physik.fu-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 3841 bytes --]
On Fri, May 12, 2023 at 12:41:47 +0200, John Paul Adrian Glaubitz wrote:
> Hello Ard!
>
> On Thu, 2023-05-11 at 16:29 +0200, Ard Biesheuvel wrote:
> > > > Feel free to keep using it, but please stop demanding that our people
> > > > keep wasting their time on it. If you want to support it in Debian,
> > > > you can carry it as a downstream patch and shoulder the maintenance
> > > > burden.
> > >
> > > Who is "our people"? Do you think that you are part of the community and
> > > I am not? I don't think this kind of hostility is justified. Neither you
> > > nor I own this project.
> > >
> >
> > Apologies - I had meant to type 'other people' not 'our people'. I
> > rarely contribute to GRUB myself, so I wouldn't consider myself more a
> > part of this community than anyone else.
> >
> > But my point remains: I have inferred from your response (and your
> > involvement in similar discussions around the Linux kernel) that you
> > would prefer Itanium support to be retained, right?
>
> Not necessarily. I am generally not opposed to removing ia64 support, but it
> should happen in a coordinated form where downstreams and users are involved.
>
> Just dropping support from random projects without prior coordination seems
> like the wrong approach to me. I would suggest posting your plans to the
> distributions mailing list [1], Debian's ia64 mailing list [2], the Gentoo
> developer mailing list [3], the Linux ia64 mailing list [4] and maybe the
> NetBSD ia64 mailing list [5].
>
> If you don't get any objections there, I am not going to object either. I just
> want this to happen in an ordered manner.
>
For future reference, might I suggest the following "distributions" list
as well: distributions@lists.linux.dev
It's a relatively new list for cross-distro collaboration/PSAs. You can
find the archives here [6].
- Oskari
> > So could you explain who you think should carry the maintenance
> > burden? IA64 will be the only EFI architecture in GRUB that does not
> > boot via an EFI stub in Linux, and this deviation means that retaining
> > support for it is going to take actual developer and maintainer
> > bandwidth. GRUB gets very little of that as it is, which means that
> > keeping IA64 support alive comes at the cost of worse support for
> > other architectures and platforms. (The series that this patch is part
> > of breaks the ia64 build, and i i struggle to see why i should care
> > about that)
> >
> > Very few of those people have access to such systems to begin with
> > (probably none), and the companies that manufactured them stopped
> > supporting them in the open source years ago, so testing these changes
> > is not straight-forward, making it unreasonable to demand this from
> > contributors. Also, it is unclear to me why the needs of the few
> > people that do still run such a system are not served by a build based
> > on today's GRUB tree, and why ia64 support needs to be retained going
> > forward.
>
> Well, that's why I am suggesting to coordinate this properly and ask potential
> users of the code whether they are okay with the removal.
>
> Thanks,
> Adrian
>
> [1] https://lists.freedesktop.org/mailman/listinfo/distributions
> [2] https://lists.debian.org/debian-ia64/
> [3] https://archives.gentoo.org/gentoo-dev/
> [4] https://marc.info/?l=linux-ia64&r=1&w=1
> [5] https://mail-index.netbsd.org/port-ia64/tindex.html
>
[6] https://lore.kernel.org/distributions/
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer
> `. `' Physicist
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-05-14 6:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 12:06 [PATCH v2 0/6] efi: Implement generic EFI boot for x86 Ard Biesheuvel
2023-05-11 12:06 ` [PATCH v2 1/6] ia64: Remove support Ard Biesheuvel
2023-05-11 12:14 ` John Paul Adrian Glaubitz
2023-05-11 12:17 ` Ard Biesheuvel
2023-05-11 12:42 ` Steve McIntyre
2023-05-11 13:34 ` John Paul Adrian Glaubitz
2023-05-11 14:29 ` Ard Biesheuvel
2023-05-11 18:42 ` matoro
2023-05-11 22:09 ` Ard Biesheuvel
2023-05-11 22:40 ` matoro
2023-05-12 9:49 ` Ard Biesheuvel
2023-05-12 13:39 ` Gerd Hoffmann
2023-05-12 15:36 ` matoro
2023-05-12 0:08 ` Lennart Sorensen
2023-05-12 10:41 ` John Paul Adrian Glaubitz
2023-05-12 10:56 ` Ard Biesheuvel
2023-05-14 6:31 ` Oskari Pirhonen [this message]
2023-05-11 22:31 ` Vladimir 'phcoder' Serbinenko
2023-05-11 12:06 ` [PATCH v2 2/6] efi: Make EFI PXE protocol methods non-callable Ard Biesheuvel
2023-05-11 12:06 ` [PATCH v2 3/6] efi: Add calling convention annotation to all prototypes Ard Biesheuvel
2023-05-11 12:06 ` [PATCH v2 4/6] efi: Drop all uses of efi_call_XX wrappers Ard Biesheuvel
2023-05-11 12:06 ` [PATCH v2 5/6] efi: Remove x86_64 call wrappers Ard Biesheuvel
2023-05-11 12:06 ` [PATCH v2 6/6] efi: Use generic EFI loader for x86_64 and i386 Ard Biesheuvel
2023-05-11 12:14 ` Ard Biesheuvel
2023-05-14 5:12 ` Glenn Washburn
2023-05-16 17:57 ` Ard Biesheuvel
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=ZGCAO_fjvH9rfDQr@dj3ntoo \
--to=xxc3ncoredxx@gmail.com \
--cc=ardb@kernel.org \
--cc=distributions@lists.linux.dev \
--cc=dkiper@net-space.pl \
--cc=glaubitz@physik.fu-berlin.de \
--cc=grub-devel@gnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.