Raku / Raku/whateverable

Build everything back to 2014.01

Open
#117 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

testneeded whateverable
Dominant language
Raku
Stars
19
Forks
16
PR merge metrics
No merged PRs in 30d

Description

Kind of annoyed that we cannot bisect sometimes because the change is too old. It is surprising how often this happens.

In issue #23 it was noticed that lrz, although being relatively slow, does an amazing job compressing several builds at the same time. This means that for long-term storage we can put 50 (or so) builds together, and this way store most of them for free (in terms of storage). Yes, all operations with these builds will be slower, but I guess anyone can wait a second or two if they're trying to access something that old.

These changes are required:

  • build-exists should try to find .zst archives first, and if this fails try to find the build elsewhere. We will need some sort of lookup mechanism for finding the right file.
  • These two lines changed accordingly. Make sure that during this process we are not saving builds that are not required.
  • Change build.p6 so that it can figure out that 50 consequent .zst archives can be recompressed with .lrz instead.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with build-exists in Whateverable.pm6, especially the linked lines 124 and 172-173, and read issue #23 for the compression context. Then inspect build.p6 to understand how builds are selected and stored. Done means older builds can locate .zst archives, avoid retaining unnecessary builds, and identify groups of 50 consecutive .zst archives for .lrz recompression.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.