leapp-sweep-siblings

name	leapp-sweep-siblings
description	After fixing an artifact in one LEAPP core, find and fix the same defect in the sibling cores. Use when a fix has just landed or is about to, when asked to "level" a change across cores, or when checking whether a defect found in one tool exists in the others.

Sweeping sibling cores after a fix

iLEAPP, ALEAPP, RLEAPP, VLEAPP and DLEAPP carry independent copies of many artifacts. A fix in one does not reach the others, and the stale copy keeps shipping the defect to examiners.

1. Update every checkout first

A local clone that is days behind will tell you a fix is missing when it already shipped, or that a file is clean when it is not. Fetch before you look, or query the remotes directly.

2. Find the twins

Grep each sibling for the artifact filename and for the app's package or bundle identifier. The filename alone misses copies that were renamed, and the identifier alone misses modules that handle several apps.

The leapp-cross-core rule lists app names already known to exist in more than one core. Treat it as a starting point, not the full set.

3. Read each twin before touching it

The copies drift. Expect the same defect at different line numbers, and expect extra defects the original never had. Do not apply the patch blind.

Check the reverse direction too. A defect you found in one core may exist unfixed in the one you think of as canonical.

4. Fix each one on its own branch and PR

One PR per repo. Each core has its own CI, its own lint debt and its own reviewers.

Apply the "Needs Cross Core Leveling" label when a change should propagate but you are not doing all of them now. Do the grep yourself rather than trusting the label to be actioned later.

5. Verify per core, not once

Row counts differ between cores because the underlying app data differs. Confirm each fix against data for that platform. A count that matches the other core is a coincidence worth questioning, not a confirmation.

Shared infrastructure counts too

The same drift applies to scripts/lavafuncs.py, scripts/html_safe.py, scripts/ilapfuncs.py and the admin/ checkers, which are meant to stay in step across cores. When porting one of those, verify the helper you are copying into is not older than the one you copied from, and check the helper itself rather than just the number of findings a checker reports. A stale helper can make a checker report zero while the defect is still live.

leapps-org/leapps-parity scans for exactly this class of drift and its report is a reasonable place to start.