Org sign-off: bbl-dres #8

Closed
opened 2026-09-14 12:54:13 +00:00 by mirror-sync · 1 comment
Owner

The sources list bbl-dres, but there is no such organisation on this instance and the scheduled run does not create one unattended — admitting an organisation authorises the import of everything under it, so a person decides. Nothing from bbl-dres is mirrored until it exists.

  • Repositories waiting: 19
  • Imported automatically on admission: 18 (~3.20 GiB)
  • Needing their own sign-off as well: 1
  • Headroom now: 13.3 GiB
  • First raised: 2026-09-14

What admitting it costs

Creating the organisation is the whole decision for the 18 repositories below the size cap: the next run imports them with no further review. Anything above the cap is held separately — size is its second blocker, not its first, which is why those have no ticket of their own while this one is open.

The over-cap ones are a second decision, taken later: each gets its own sign-off ticket on the run after this one is admitted, and the same approve label answers it there. Admitting the organisation here does not approve them, and nothing is lost by waiting — they stay listed below and in every run report meanwhile.

Above the size cap — need approving too

  • https://github.com/bbl-dres/data-catalog — 100 MB

Below the cap — imported on admission

  • https://github.com/bbl-dres/kennwerte-db — 2233 MB
  • https://github.com/bbl-dres/reconstruction — 452 MB
  • https://github.com/bbl-dres/service-portal — 292 MB
  • https://github.com/bbl-dres/tenant-portal — 119 MB
  • https://github.com/bbl-dres/process-hub — 33 MB
  • https://github.com/bbl-dres/workspace-management — 26 MB
  • https://github.com/bbl-dres/plan-check — 21 MB
  • https://github.com/bbl-dres/green-inventory — 18 MB
  • https://github.com/bbl-dres/ppm-cockpit — 12 MB
  • https://github.com/bbl-dres/property-inventory — 12 MB
  • https://github.com/bbl-dres/ict-portfolio — 10 MB
  • https://github.com/bbl-dres/geo-check — 10 MB
  • https://github.com/bbl-dres/area-estimator — 8 MB
  • https://github.com/bbl-dres/landcover-survey — 7 MB
  • https://github.com/bbl-dres/resource — 7 MB
  • https://github.com/bbl-dres/transaction-portal — 5 MB
  • https://github.com/bbl-dres/.github — 0 MB
  • https://github.com/bbl-dres/mieterportal — 0 MB

Three ways to resolve this, all done on this ticket

Admit it — apply the approve label. The next scheduled run records bbl-dres in config/org_approvals.txt, creates the organisation, imports what is listed above as under-cap, and closes this ticket as approved.

Decline it — close this ticket. The next run records that in config/org_declines.txt pointing back here and relabels it declined; the alert stops naming bbl-dres and the closed ticket becomes the answer for anyone who asks later. Leave a comment saying why before you close — the file links here, so this ticket is where the reason has to live. Reopening it withdraws the line and brings the question back.

Leave it — it stays listed in every run report and is not mailed again. That is a decision nobody can read, which is what a recorded decline avoids.

Both of the first two are carried out by the scheduled run, not at the moment you click. Until it next runs, the label or the closure is a request on record and nothing has happened yet.

This ticket's title is how the scheduled job finds it — please do not edit it.

The sources list `bbl-dres`, but there is no such organisation on this instance and the scheduled run does not create one unattended — admitting an organisation authorises the import of everything under it, so a person decides. Nothing from `bbl-dres` is mirrored until it exists. - Repositories waiting: **19** - Imported automatically on admission: **18** (~3.20 GiB) - Needing their own sign-off as well: **1** - Headroom now: 13.3 GiB - First raised: 2026-09-14 ## What admitting it costs Creating the organisation is the whole decision for the 18 repositories below the size cap: the next run imports them with no further review. Anything above the cap is held separately — **size is its second blocker, not its first**, which is why those have no ticket of their own while this one is open. The over-cap ones are a **second decision, taken later**: each gets its own sign-off ticket on the run after this one is admitted, and the same `approve` label answers it there. Admitting the organisation here does not approve them, and nothing is lost by waiting — they stay listed below and in every run report meanwhile. ### Above the size cap — need approving too - `https://github.com/bbl-dres/data-catalog` — 100 MB ### Below the cap — imported on admission - `https://github.com/bbl-dres/kennwerte-db` — 2233 MB - `https://github.com/bbl-dres/reconstruction` — 452 MB - `https://github.com/bbl-dres/service-portal` — 292 MB - `https://github.com/bbl-dres/tenant-portal` — 119 MB - `https://github.com/bbl-dres/process-hub` — 33 MB - `https://github.com/bbl-dres/workspace-management` — 26 MB - `https://github.com/bbl-dres/plan-check` — 21 MB - `https://github.com/bbl-dres/green-inventory` — 18 MB - `https://github.com/bbl-dres/ppm-cockpit` — 12 MB - `https://github.com/bbl-dres/property-inventory` — 12 MB - `https://github.com/bbl-dres/ict-portfolio` — 10 MB - `https://github.com/bbl-dres/geo-check` — 10 MB - `https://github.com/bbl-dres/area-estimator` — 8 MB - `https://github.com/bbl-dres/landcover-survey` — 7 MB - `https://github.com/bbl-dres/resource` — 7 MB - `https://github.com/bbl-dres/transaction-portal` — 5 MB - `https://github.com/bbl-dres/.github` — 0 MB - `https://github.com/bbl-dres/mieterportal` — 0 MB ## Three ways to resolve this, all done on this ticket **Admit it** — apply the `approve` label. The next scheduled run records `bbl-dres` in `config/org_approvals.txt`, creates the organisation, imports what is listed above as under-cap, and closes this ticket as `approved`. **Decline it** — close this ticket. The next run records that in `config/org_declines.txt` pointing back here and relabels it `declined`; the alert stops naming `bbl-dres` and the closed ticket becomes the answer for anyone who asks later. **Leave a comment saying why before you close** — the file links here, so this ticket is where the reason has to live. Reopening it withdraws the line and brings the question back. **Leave it** — it stays listed in every run report and is not mailed again. That is a decision nobody can read, which is what a recorded decline avoids. Both of the first two are carried out by the scheduled run, not at the moment you click. Until it next runs, the label or the closure is a request on record and nothing has happened yet. *This ticket's title is how the scheduled job finds it — please do not edit it.*
mirror-sync 2026-09-15 07:45:13 +00:00
  • closed this issue
  • added the
    approved
    label
Author
Owner

Closing: approved — bbl-dres was created on 2026-09-15, and its repositories import on the next run.

The decision itself lives in versioned config; this ticket only recorded it.

Closing: approved — `bbl-dres` was created on 2026-09-15, and its repositories import on the next run. The decision itself lives in versioned config; this ticket only recorded it.
mirror-sync referenced this issue from a commit 2026-09-15 07:45:13 +00:00
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
meta/reports#8
No description provided.