Skip to content

[Question]: Linux compatibility contribution submission #362

Closed

Description

@ASHURA1800

Product or interface

None

Question

Hello MiniMax team,

I have implemented a Linux compatibility improvement for MiniMax Code and would like to contribute it upstream.

The changes include:

  • XDG data directory support on Linux
  • Backward-compatible data migration
  • Linux .bashrc and .zshrc PATH integration
  • Linux terminal notification test coverage
  • Ubuntu ARM64 CI/compatibility coverage
  • ARM64 CLI release-target coverage
  • Unit tests for the Linux-specific changes

Branch:
https://github.com/ASHURA1800/minimax-code/tree/feat/linux-compatibility

Commit:
ASHURA1800@f3f0538

Local validation:

  • data-dir tests: 15/15 passed
  • terminal notification tests: 17/17 passed
  • PATH integration tests: 9/9 passed
  • git diff --check: clean

GitHub currently prevents me from opening a pull request because only repository collaborators can create PRs.

Could you please let me know how you would like me to submit this contribution, or whether there is a contributor workflow I should follow?

Thank you.

Activity

  1. hetaoBackend commented on Sep 25, 2026

    @hetaoBackend
    Collaborator

    Thanks for preparing this and sharing the branch and validation details. Opening this issue is the correct entry point: external PRs are currently restricted to repository collaborators, as described in CONTRIBUTING.md. There is no need to work around that restriction; we can coordinate the proposal here and prepare a maintainer PR with attribution.

    I inspected commit f3f0538 and found a few things to address before integration:

    • The XDG change still treats only ~/.mavis as the legacy directory. With existing data only in ~/.minimax, resolution selects a new empty XDG directory and leaves the existing configuration behind. With .mavis pointing to .minimax, migration moves the data but leaves the old .minimax path unavailable. Both upgrade paths need coverage and compatibility handling.
    • A relative XDG_DATA_HOME is currently accepted. Invalid relative values should fall back to the default absolute location.
    • The new config test is missing from test/vitest-suites.json, the two new test files are missing from the generated source inventory, and the workflow matrix assertions need to match the ARM64 additions.

    The migration cases above were reproduced with synthetic temporary data on macOS while exercising the Linux code path; this is not native Linux or ARM64 acceptance.

    I will work through these corrections in an isolated branch, keep the changes reviewable, and link the PR here after local verification. We will also distinguish native CI results from the local checks before considering integration. Thanks again for the contribution.

  2. hetaoBackend commented on Sep 25, 2026

    @hetaoBackend
    Collaborator

    The maintainer adaptation is now in #364, with attribution to your original commit.

    For the data-directory change, existing Linux installations keep their .minimax directory and symlink targets in place; only new installations default to XDG. This avoids relocating an active database or breaking existing shell PATH entries. Older .mavis installations retain their existing migration to .minimax. Relative XDG paths fall back to the standard default, and the CLI now completes Linux directory resolution before setting runtime overrides.

    The PR also includes the bash/zsh PATH change, notification coverage, ARM64 CI/release-installation targets, the missing test/inventory registration, and updated workflow assertions and documentation.

    Local verification passed all 15 applicable pnpm verify gates on macOS ARM64 / Node 26.4.0 at 611ec8e, including 4,690 passing capability tests. Native Linux/ARM64, Windows, archive-installation and performance CI results are still pending; these are not covered by the local result. The PR remains open for independent review and has not been merged or released.

  3. hetaoBackend commented on Sep 25, 2026

    @hetaoBackend
    Collaborator

    This was generated by AI during triage.

    @ASHURA1800 — this question is answered and the contribution is in flight, so I'm closing this issue to keep the tracker tidy. Nothing further is needed from you here. Recapping the outcome so it's documented in one place:

    Answer to your question

    • External PRs are restricted to repository collaborators (per CONTRIBUTING.md), so GitHub blocking your PR was expected — there's no workflow to work around, and you shouldn't try to bypass it.
    • Opening this issue was the correct entry point. We coordinate the proposal in the issue and prepare a maintainer PR with attribution to your original commit.

    Current state of the work

    The maintainer adaptation is in #364 (fix(linux): preserve existing data with XDG and ARM64 support), with attribution to your commit f3f0538. It incorporates:

    • Your Linux XDG data-directory support, adjusted so existing Linux installs keep their .minimax directory and symlink targets in place (only new installs default to XDG). This avoids relocating an active database or breaking existing shell PATH entries — the two upgrade paths you flagged needed coverage.
    • Relative XDG_DATA_HOME values now fall back to the standard default.
    • The bash/zsh PATH change, terminal-notification coverage, Ubuntu ARM64 CI/release-installation targets, the missing test/vitest-suites.json + source-inventory registration, and updated workflow assertions and documentation.

    Local verification passed all 15 applicable pnpm verify gates on macOS ARM64 at 611ec8e (including 4,690 capability tests). Native Linux/ARM64, Windows, archive-installation, and performance CI results are still pending — the local run does not cover those, and #364 remains open, unmerged, and unreleased pending independent review.

    If you have questions about the adaptation or want to iterate on #364, feel free to comment on that PR.

    Thanks again — the XDG + ARM64 work is a meaningful contribution to Linux support.

  4. added
    wontfixThis will not be worked on
    and removed
    needs-triageAwaiting maintainer assessment
    on Sep 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionUsage or project-policy questionwontfixThis will not be worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions