[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: KDE Gear and hotfix releases, how to see whether a user has the hotfix?
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2021-10-25 22:59:37
Message-ID: 4659498.GXAFRqVoOG () xps
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]