which branch for near-term walletFactory work? master or release-mainnet1B?

[dckc]

What is the Problem Being Solved?

near-term walletFactory work such as #8445 is the/a first step in un-tangling dependencies in upgrading all vats to match master. Should that work be based on master or on the release-mainnet1B branch?

Lack of clarity is starting to have tangible time costs.

Description of the Design

This issue is mainly a choice between 2 designs. quick IBIS sketch:

• ? build the bundle to upgrade the walletFactory contract based on master or on the release-mainnet1B branch?
  • : continue to use main
    • (-) risk: testing in master might not reveal problems when deployed on mainnet
      • : agoric-3-proposals tests the bundle in a mainnet-like environment
        • (-) agoric-3-proposals tests are very limited / basic: "does the system not explode when I upgrade this one piece?"
          • : agoric-3-proposals should test all product features
            • (-) that's a lot of work; do we want to put it in the critical path?
  • : use release-mainnet1B branch
    • (-) porting the work in vat-walletFactory upgrade would cause wallet to stop tracking existing offers #8445 could be costly; do we want to put it in the critical path?

cc @mhofman @warner @Chris-Hibbert

Background

The most substantial progress so far, #8488, is based on master.

In starting work on #8293 by making a failing test (#8557), I took a more conservative approach and based it on release-mainnet1B. Today I was curious whether #8488 already fixes #8293, so I ported the test in #8557 to the branch in #8488. There was friction, since the bootstrapTests have been moved from the @agoric/vats package to @agoric/boot and ported to typescript (less friction than I thought; @turadg got me past it in a few minutes).

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

[mhofman]

IMO, the code should be tested in the release-mainnet1B branch, and the bundles built from there too. The cherry picking from master to the release branch, or opposite is definitely adding friction, especially with the various large refactors missing from the release branch, but the limited test coverage from the docker upgrade test framework worried me enough to think the cherry-pick / porting effort is worth the piece of mind.

[dckc]

the resolution seems to be:

• we build the bundle for release from the release branch
• we also land the fixes on master

Whether one starts on master and backports or the other way around is at the discretion of devs.

[dckc]

p.s. for a more general policy:

• Formal process and infrastructure for release branch development #8578