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

[Albert Astals Cid]

El dilluns, 25 d’octubre de 2021, a les 1:57:58 (CEST), Friedrich W. H. Kossebau va escriure:
> Hi,
> 
> (distributions as CC: as they are stakeholders on the matter)
> 
> while discussing a potential move to KDE Gear (or rather, the great automatic 
> Release service part), the question came up how cases of urgent fixes are 
> handled, especially when it comes to identifying products at users whether 
> they have a respectively fixed version.
> 
> 
> USE CASE:
> 
> the application Foo gets released as version 2.1.3. A day after release a 
> security issue is found. A hotfix is quickly written and pushed to the 
> repository. The patch-level version is bumped, new release is done the same 
> day.
> 
> The version number in the tarball name, the one of the packages created by 
> distributions and the one displayed by the application at runtime all properly 
> tell whether this is a version with the hotfix or not.
> So both users and developers know they talk about the same variant of the 
> software (at least when it comes to the hotfix).
> 
> 
> KDE GEAR: BREAKING EXPECTATIONS
> 
> If Foo was to released with KDE Gear, the same experience should be possible.
> 
> Right now though this seems not easily possible, due to the strict scheme in 
> the schedule as well as the version data used.
> 
> 
> ASKING DISTRIBUTIONS TO JUST PATCH?
> 
> It seems a practice is post-release to simply ping the distributions on the 
> distributions ML, point them to a commit to apply as patch and be done.
> 
> But does that work good enough? 

I think it does work relatively well, distributions that package our software "quickly" will have no problem adding a patch if explained why it's needed.

Then there's distributions that don't package our software quickly, but those are on past versions anyway so they are not going to be exposed to "new bugs".

> 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).

> Digging into distribution-specific packaging to find which patches are applied 
> is not considered a sensible solution not only by me.
> Also might distributions/packagers fancy real source tarballs w/ matching tags 
> over adding custom patches in the package specs.
> 
> 
> WAITING WEEKS FOR NEXT SCHEDULED RELEASE?
> 
> Alternatively waiting up to a full month until the next patch release gets out 
> in such cases also seems not user-friendly (and not developer-friendly, when 
> they have to face the issue reports of users as result in the meantime).
> 
> 
> CAN WE HAVE KDE GEAR DO INDIVIDUAL AND VERSIONED HOTFIX RELEASES?
> 
> So ideally KDE Gear has an option to do intermediate hotfix releases of 
> individual software as well, with proper identifier in the version.
> 
> Two challenges I see:
> a) a simple way to run the KDE Gear scripts for an individual package
> b) have an extended KDE Gear version scheme, to be able to denote any 
> additional hotfix releases (e.g. for tag, package name, UI version strings).
> 
> I know this will make things more complicated for KDE Gear. But it makes more 
> things easier at other places later. And once in place, it hopefully should 
> not cost more.

I don't think this is that complicated, a) is easy as Heiko mentioned and I don't see a problem with b) either, just add another .1 at the end. (or more if you make so many mistakes in between releases ^_^)

But I would like to say:
 * We've seem to be doing quite well without needing this for "almost decades"
 * 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"
 * 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.

Cheers,
  Albert

P.S: Heiko feel free to disagree on the last bullet point above if you think you'd be fine with doing as many re-rolls as needed.

> 
> Should be in bed now, but sending off to trigger your initial reactions and 
> thoughts and comments. More from me later the week.
> 
> Cheers
> Friedrich
> 
> 
>