Re: [PATCH] RFC: Version support policy

[Wojtek Porczyk <woju@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Feb 23, 2022 at 01:20:26PM +0000, George Dunlap wrote:
> > On Feb 22, 2022, at 3:42 PM, Marek Marczykowski-Górecki 
> > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > On Tue, Feb 22, 2022 at 04:05:19PM +0100, Jan Beulich wrote:
> >> On 22.02.2022 15:58, George Dunlap wrote:
> >>>> On Feb 22, 2022, at 12:18 PM, Wojtek Porczyk 
> >>>> <woju@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >>>> On Mon, Feb 14, 2022 at 09:50:25PM +0000, George Dunlap wrote:
> >>>>> I think it’s too much effort to ask developers to try to find the actual
> >>>>> minimum version of each individual dependency as things evolve.
> >>>> 
> >>>> By "find the actual minimum version", do you mean to get to know the 
> >>>> version
> >>>> number, or install that version on developer's machine?
> >>> 
> >>> Well suppose that a developer writes code that depends on an external 
> >>> library.  The external library on their own machine is 4.5; so they know 
> >>> that 4.5 works.  But will 4.4 work?  How about 4.0?  Or 3.9?  Or 2.2?  
> >>> Maybe it works on 3.8+ and 2.13+, but not 2.0-2.12 or 3.0-3.7.
> >>> 
> >>> I don’t think it’s fair to ask people submitting patches to do the work 
> >>> of tracking down which exact versions actually work and which ones don’t 
> >>> actually work;
> >> 
> >> But somebody will need to do this. If it's not done right away, someone
> >> (else) will hit a build issue on a perhaps just slightly older platform.
> > 
> > That's why declare what version _should_ work (and test that via CI),
> > instead of trying to find what is the minimum version that is actually
> > required. This may result in saying "you need libfoo 3.4" while in
> > practice 3.3 would be fine too, but I think that's reasonable
> > compromise.
> 
> This paragraph is a little unclear; you say “should”, but then talk about 
> what has been tested to work.
> 
> To me “what version should work” means you track down the version of the
> library where the relied-upon functionality was introduced; in your libfoo
> example, it would be 3.3.  I think we should only include versions that have
> been tested to work.  If the CI loop only tests libfoo 3.4, then we should
> list 3.4 as the requirement.  If someone else tests 3.3 themselves and
> reports that it works, then we can use 3.3.

I don't think there should be much "tracking down" involved, at least not 
to the level of bisecting. Instead a simple statement of "tested with
dependency $D version $V from distro $L", and the reviewer checks if it's the
oldest supported version, or the relevant API didn't significantly divert.

Also, there's nothing wrong with declaring a later version for availability
reasons like "it's in one of the distros we use in CI". In the example: we
know that technically 3.3 works, but we don't test it, so to be safe we
"require" 3.4.

Distro-related availability reasons tend to be correlated between CI and
developer's boxen, so if we test 3.4 and not 3.3, chances are, it will be
easier to set up a 3.4 version on dev's workstation. Again, without specific
example it's hard to say, but if it's relatively easy to set up version 3.4,
then it might be reasonable to ask contributors to test against that version,
which I think is the answer your concern.

If anyone badly needs 3.3, it's his/her burden to argue why the project and
every single contributor needs to do extra work to acquire 3.3, because the
differential (compile themselves vs apt-get install) is what might cause
testing that version to be unfair for everone else. Other side of the coin is
pretty similar: if anyone needs a feature from 3.5, it's his/her duty to
convince everone why the dependency needs to be bumped.


-- 
pozdrawiam / best regards
Wojtek Porczyk
Gramine / Invisible Things Lab
 
 I do not fear computers,
 I fear lack of them.
    -- Isaac Asimov

Attachment: signature.asc
Description: PGP signature