KDE Gear and hotfix releases, how to see whether a user has the hotfix?

[Friedrich W. H. Kossebau]

Am Dienstag, 26. Oktober 2021, 01:00:23 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’octubre de 2021, a les 1:57:58 (CEST), Friedrich W. H. 
Kossebau va escriure:
> > E.g. how can users & developers later know in
> > a consistent way if an instance of the software really has the hotfix, or
> > if some issue seen by the user has another cause?
> 
> You can never 100 % trust that a package from a distribution is 100% the
> code upstream, every distribution is more or less liberal with having
> patches (and rightfully so, i'm not saying it's a bad practice, I mean we
> literally ask them to do so :D).

Yes, that what I referred to by the "(at least when it comes to the hotfix)" 
earlier, assuming they usually would not wipe out again any fixes :)
But then, distributions are called "distributions" because most of the time 
they surely favour being able to package sources 1:1 without having to do any 
patching :)
((For everyone else making use of the FLOSS nature and heavily patch things, 
we would want to have users of that also deal with that distribution/operating 
system for that fork instead of upstream.))

> But I would like to say:
>  * We've seem to be doing quite well without needing this for "almost
> decades"

Quite well, unless one from a developer POV had to spend time in discussiog 
bug reports with users to find if they are using packages which have patch x 
or y already applied (and help them how to find out). And users time/energy 
wasted in such discussions also sad.

> * I fear that the possibility of "endless re-rolls" may make
> people test/review code less because "we can always re-roll the package if
> it breaks"

Same fear here, though then I think people are already shaming themselves 
enough now when having to ask for distributions adding patches, so I would 
think the same applies for having to ask for extra releases. Something to 
watch for in any case to not becoming a habit and approaching the cause, if 
so.

Then the use-cases I had in mind were less bad developers on our side, but 
rather emergencies triggered externally:
* a dependency changes behaviour in a new version, with severe effects in our 
software
* a security flaw gets published

So things which are not/less in our control, yet need instant handling. And 
some mean to denote the very version that has a fix, so end-to-end 
communication (user <-> developers) is simple.

Same like having a system to extinct fires :) We do not want fires, but we 
know they can happen in accidents, so we better have something prepared to 
handle it when needed.

> * If we would be going to be doing this, I would personally
> prefer if the person that made that code mistake is the responsible for
> rolling out the packages and not the release engineer (that is Heiko for
> the most part). Doing a release every month is already quite some work.

Agreed, would be better to have people take responsibility and not live off 
the free work from others in such cases, that should help in case of own 
slacking earlier. Even more when main release workers are not around, but 
things need to be handled soonish.

Cheers
Friedrich