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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
