grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2] i386-pc: build verifiers API as module


From: James Bottomley
Subject: Re: [PATCH v2] i386-pc: build verifiers API as module
Date: Mon, 22 Mar 2021 14:43:47 -0700
User-agent: Evolution 3.34.4

On Mon, 2021-03-22 at 15:19 -0500, Glenn Washburn wrote:
> On Mon, 22 Mar 2021 16:16:26 +0000
> Colin Watson <cjwatson@debian.org> wrote:
> 
> > On Mon, Mar 22, 2021 at 04:20:00PM +0100, Daniel Kiper wrote:
> > > NAK for this patch and others "fixing" small MBR gaps. I am not
> > > going to deal with this kind of issues any longer because a few
> > > folks in the world cannot/do not want/... reinstall their
> > > systems. Sorry guys.
> > 
> > I'd just like to say that I think this is an unfortunate mistake,
> > and puts distributions in an invidious position.
> 
> Forgive my ignorance, this seems like a fairly simple patch. While I
> personally do not like maintaining patches just solely for myself, my
> understanding is that distros are quite accustomed to carrying
> patches for very long periods of time (indefinitely?). Is part of the
> push back because its onerous for distro/package maintainers? Or is
> this more a coming from a matter of principal?

The point of an open source upstream is to provide a code base from
which users can build things.  That's why most upstreams aren't simply
code dumps, but are buildable projects.  Since most users don't build
things any more, distributions serve as the build and delivery
mechanism for the majority.  This means that in an ideal world the
upstream and the distributions that package them have a synergistic
relationship.  Ideally any patch which is useful to more than one
distribution should be in the upstream,  so in the ideal model the
upstream serves as a communication and synchronization point for
distributions even if they serve greatly differing markets and open
discussion of these differences helps the upstream determine the best
form of any proposed change which often provides great synergy when a
common and agreed upon resolution is achieved because the distributions
are reflecting the needs of their users back into the upstream and the
upstream is, in turn, responding and refining the inputs.

In the real world, of course, there are a variety of dysfunctional
upstream to distro relationships for reasons as varied as philosophical
differences to personality clashes.  However, when the relationship
becomes dysfunctional it's usually the everyone (including the
upstream) who suffers.

James





reply via email to

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