From 5d6fa52b8985f8068314aba26878a1d7d5cb84e5 Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Wed, 6 May 2026 20:42:32 +0300 Subject: feat: flip swap mechanism — MD as primary, RST as override (Phase 1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is the first of three phases inverting the per-page swap mechanism so MD becomes the canonical primary and RST becomes the rare override. Phase 1 — file renames + conf.py exclude_patterns flip only: - Rename docs/**/md-.md to docs/**/.md (drop md- prefix) for all 254 stems previously listed in docs/_swap.txt - Rename docs/**/.rst to docs/**/rst-.rst (add rst- prefix) for the same 254 stems - Repurpose docs/_swap.txt as docs/_rst_overrides.txt; initially empty comment-only since no pages need the RST fallback right now - conf.py exclude_patterns flipped: rst-*.rst is now excluded by default instead of md-*.md - conf.py runtime-artifact references updated to _rst_override_state.json and _md_exclude.txt (Phase 2 will rewrite swap_sources.py to produce these names; for now no swap script runs because overrides list is empty) Phase 2 (next commit on this branch) will rewrite scripts/swap_sources.py with inverted rename direction, delete scripts/import_myst.py + tests, and update tests/test_swap_sources.py for the new semantics. Phase 3 will be the cleanup pass and ready-for-review flip. Generated by robots https://vyos.io --- docs/contributing/md-issues-features.md | 122 -------------------------------- 1 file changed, 122 deletions(-) delete mode 100644 docs/contributing/md-issues-features.md (limited to 'docs/contributing/md-issues-features.md') diff --git a/docs/contributing/md-issues-features.md b/docs/contributing/md-issues-features.md deleted file mode 100644 index ab235326..00000000 --- a/docs/contributing/md-issues-features.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -lastproofread: '2025-12-08' ---- - -(issues_features)= - -# Issues/Feature requests - -(bug_report)= - -## Bug Report/Issue - -Issues and bugs occur in every software project, and VyOS is no exception. - -### I found a bug, what should I do? - -When you find a potential bug, first: - -- Consult the [documentation] to ensure you configured your system - correctly. -- Check if the VyOS community has identified a workaround for the bug through - [Slack] or the VyOS [Forum]. - -### Ensure the bug is reproducible - -Include the following information when reporting a bug: - -- A sequence of configuration commands or a complete configuration file needed - to recreate the bug. Avoid partial configurations: a sequence of commands is - easy to paste and a complete configuration is easy to load, but a partial - config is hard to reconstruct. -- Describe the expected behavior and how it differs from what you observe. - Include command outputs or traffic dumps. Explain briefly why these outputs - are incorrect and what the correct behavior should be. -- A sequence of actions that trigger the bug. While not always possible, this - helps developers and community members confirm the issue and verify fixes. -- If the bug is a regression, specify the VyOS version where the feature worked - correctly (any working version is acceptable). Identify the exact version - that the feature stopped working, if possible. - -If you are uncertain whether the behavior is a bug or what the correct behavior -is, or if you lack a reliable reproducing procedure, post on the forum or ask in -chat first. If you have a subscription, create a support ticket. The team and -community can help identify the issue, work around it, and create an actionable -bug report. - -### Report a Bug - -To open a bug report or feature request, create an account on -[vyos.dev](https://vyos.dev), the public issue tracker for VyOS. - -When creating a new issue, select the appropriate project and: - -- Provide as much information as you can. -- Specify which VyOS version you are using: `run show version`. -- Explain how to reproduce the bug. - -(feature-request)= - -## Feature Requests - -Have an idea to improve VyOS or need a feature that would benefit all users? -Before submitting a feature request, search the public issue tracker -[vyos.dev](https://vyos.dev) to check if a request already exists. You can -also enhance an existing request by providing additional information. - -Create a task before starting work on a feature, -even if it is a trivial feature. -The task tracker generates release notes, so all work must be reflected -in the tracker. - -Include at least the following information: - -- Provide a detailed description of the feature: what it is, how it works, and - how you would use it. Maintainers may not have experience with every feature, - protocol, and tool in VyOS. Detailed information helps VyOS contributors and - maintainers test new features they are unfamiliar with. -- Include proposed CLI syntax if the feature requires new commands. Provide both - configuration and operational mode commands if both are needed. - -Consider including the following information: - -- Is the feature already supported by the underlying component - (FreeRangeRouting, nftables, Kea, etc.)? -- How would you configure the feature manually within that component? -- Are there any limitations to using the feature - (hardware support, resource usage)? -- Are there any adverse or non-obvious interactions with other features? Should - the feature be mutually exclusive? -- Any relevant documentation or references about the feature. - -You do not need to provide all this information, but if you can, it simplifies -developers' work considerably. Research these questions when possible. - -## Task auto-closing - -A special task status exists for when all work by maintainers and contributors -is complete: **Needs reporter action**. - -VyOS assigns this status to: - -- Feature requests that do not include required information and need - clarification. -- Bug reports that lack reproducing procedures. -- Tasks that are implemented and tested by the implementation author, - but require testing in the real-world environment that only the reporter - can replicate (for example, hardware VyOS does not support or specific - network conditions). - -When a task is set to **Needs reporter action**: - -- If the reporter does not respond within two weeks, the task bot adds a comment - ("Any news?") to remind the reporter. -- If there is still no response after another two weeks, - the task is closed automatically. - -We do not auto-close tasks with any other status and do not close tasks due to -lack of maintainer activity. - -[documentation]: https://docs.vyos.io -[forum]: https://forum.vyos.io -[slack]: https://slack.vyos.io -- cgit v1.2.3