Re: Automatically testing package updates

[Efraim Flashner]

On Mon, Dec 02, 2024 at 08:14:04PM +0100, Simon Tournier wrote:
> Hi,
> 
> On Mon, 02 Dec 2024 at 14:44, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > This manifest is just an example.  We could come up with manifests
> > targeting package collections like CRAN packages, astronomy packages,
> > and so on.
> 
> Let consider that a “leaf” package is a package that does not appear
> elsewhere in any other packages.  Then, if there is no mistake, I count
> 14143 leaf packages over 32459 all packages.
> 
> Well, if we filter using gnu-build-system and cmake-build-system then it
> reduces to 2847 packages.
> 
> These packages are “safe” to automatically update because the only
> annoyance will be users at run time. ;-)
> 
> Somehow, the loop and type conversion are not optimized but maybe this
> kind of “leaf” packages could defined and then filtered build-system per
> build-system, i.e., team per team.
> 
> WDYT?

To repeat what I said on Mastodon and the impression I got from the Nix
folks, if we can automate away the easy/simple package upgrades then we
can spend our time on more complex upgrades that require more attention
to get correct.

I'm now thinking about the easy-package -> hard-package learning curve
for new contributors, and I'm not sure how we'd address that.

Also I don't think we should spam the bug tracker with package upgrades,
so we'd have to think about something for that.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature