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