Migration strategy brainstorm #20
Replies: 2 comments 1 reply
-
We go for parallel running. Those maintainers with boxit access should continue to push their packages there. Some maintainers who want to test BXT add additional packages to BXT for testing the system. BXT will point to Boxit server as upstream source. This way packages pushed to boxit will be pulled by BXT also. BXT need a set of test packages to test the process. The packages can be dummy packages or AUR packages normally not found on boxit. When we tested all functions of BXT we can create a migration plan to see how we move from boxit to BXT.
|
Beta Was this translation helpful? Give feedback.
-
I'd like to offer my assistance anywhere possible perhaps
|
Beta Was this translation helpful? Give feedback.
-
Since boxit and bxt are fully incompatible between each other, we need to find an optimal migration strategy.
Some ideas:
Parallel running
Having a dedicated testing instance of bxt so we can teach maintainers to operate it, find bugs and get feedback
Pros:
Cons:
Incremental migration
Migrate only unstable branch to bxt while keeping testing and stable on boxit
Pros:
Cons:
Beta Was this translation helpful? Give feedback.
All reactions