grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB 2.06


From: Daniel Kiper
Subject: Re: GRUB 2.06
Date: Wed, 21 Apr 2021 14:21:58 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Apr 20, 2021 at 04:33:37PM -0400, Eli Schwartz wrote:
> On 4/20/21 1:48 PM, John Paul Adrian Glaubitz wrote:
> > I think it's reasonable to expect from a distribution that they
> > backport upstream fixes, at least in Debian, openSUSE and Fedora, it
> > isn't a problem.
>
> I think it is unreasonable -- backporting upstream fixes is a sign that
> upstream software has failed to be usable out of the box, and needs to
> release more often.
>
> If a distro is being *forced* to backport 200+ patches, we've officially
> entered the Madness Place:
>
> https://build.opensuse.org/package/view_file/Base:System/grub2/grub2.spec
> lines 174 - 395 (9 pages of source files, most named 0001?)
>
> https://src.fedoraproject.org/rpms/grub2/tree/rawhide
> carefully numbered list of patches 0001 - 0198

AFAICT F34 dropped more than 100 custom patches after 2.06~rc1 release.
And this did not happen by chance. It required a lot of work. I know the
situation is still not perfect. Though other folks and I are still going
to work on dropping most of these patches. So, please be patient...

> https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/series
> patch series of 219 patches

...same for Debian and other distros...

> ...
>
> I'm sorry? Claiming that distros "are capable of backporting, therefore
> it's reasonable to expect it is their job to do so" is completely
> missing the point.
>
> Claiming that for these distros "it isn't a problem" to roll a patchset
> for elaborate backport lists, based on I guess the evidence that they've
> done so, unjustly conflates "we like doing this" with "we were forced to
> do this with much gnashing of teeth".
>
> I can't point to citations where either one has been said, but I somehow
> doubt the former viewpoint is the one distro maintainers are holding.
> (Well, I'm given to understand Debian maintainers seem to actively enjoy
> having many patches. So I guess I shouldn't be *too* surprised that a
> Debian Developer is insisting that people maintain downstream patches.)
>
> "Basically insulting except not outright" a person who would like to see
> more frequent (read: any) maintenance releases because I dunno, clearly
> they're just irresponsible at running a distro if they're afraid of
> importing 200 patches in one go, is kind of really bad.
>
> This is a real problem that grub really has. Whyever that might be a
> problem (the standard reason is lack of developer time) can be seen as
> forgivable, because software development is hard and all too often
> unrewarding, and demanding more releases may not actually be feasible in
> practice.
>
> But I'd really, really, really like to NOT see victim blaming and
> holding the current state of affairs as some kind of joyous ideal which
> must be held sacred, because pooh-pooh anyone who dares post to the list
> merely asking if such a thing might be possible -- it's your own darned
> job, noob, stop being unreasonable and lern2patch, reasonable distros
> will reasonably patch.
>
> (I think it bears mentioning again -- 200+ patches. *200*. At what point
> is there more patches than source code?)
>
> ...
>
> Anyway, a grub 2.04.1 would have been fantastic 6 months or a year ago.
> At this point, people should just use 2.06-rc1, there is not much point
> in trying to stabilize a maintenance release in the middle of the
> freeze/RC cycle for 2.06 as the same effort is better spent getting 2.06
> out the door.

Sorry, I am not going to make maintenance releases until we are able to
make stable releases in proper cadence. Then we can get back to this
discussion...

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]