Malin
8d4eaa1489
- Clone all 5 Zonemaster component repos (LDNS, Engine, CLI, Backend, GUI) - Dockerfile.backend: 8-stage multi-stage build LDNS→Engine→CLI→Backend - Dockerfile.gui: Astro static build served via nginx - docker-compose.yml: backend (internal) + frontend (port 5353) - nginx.conf: root redirects to /es/, /api/ proxied to backend - zonemaster-gui/config.ts: defaultLanguage set to 'es' (Spanish) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.5 KiB
Zonemaster - Change management
Scope
This document outlines how the any changes to the software during the technical maintenance period will be classified and the process to implement these changes.
Input for change
Change requests can come from anywhere such as the users mailinglist, the steering committee or the development team. The change requests could be classified into two broad categories:
- Minor change
- Major change
Minor change
The nature of minor change requests are explained in the following subsection:
Bug Fixing
Any bug fixes, the team or any user discovers should be published in the GitHub issue tracker.
Not all issues in the tracker are bugs, and not all reported bugs are software bugs, but can be protocol errors in DNS, or user or documentation errors.
Bug fixes are included in minor releases. See the version numbering policy document for documentation on version numbers for releases.
Minor Changes
Minor changes are new features, changes or deprecated functionality that do not break backwards compatibility, neither force any user to change or update their environment that currently runs the software.
Minor changes are included in minor releases. See the version numbering policy document for documentation on version numbers for releases.
Major changes
Any change and specification that requires changes in the software architecture, an API change or new major features could be classified under the category "Major change".
Major changes are included in major releases. See the version numbering policy document for documentation on version numbers for releases.
Process to implement the change
Change requests can come from anywhere such as the users mailinglist, the steering committee or the development team.
Minor changes
A "bug fix" or "minor change" should be added as an issue in GitHub. Then the person corresponding is assigned by the release manager or the person who has created the issue. The assigned person should then close the ticket within a specified time as mentioned in the "Key Performance Indicator" (or) update the bug with the time duration on when the bug/minor improvement could be solved (or) comments the reason for not able to solve the bug/minor improvement.
Major changes
Any new development for Zonemaster must follow the strict process where there are formal requirements, specifications for implementing the requirements and then any design and architecture fulfilling the specifications, and finally the implementation and quality assurance. When all this is performed successfully the software package is released using the release process.
Decision on discarding or including changes
Whatever be the type of change request, it should go through the "Issues tracker" in the GitHub project. All requests should be promptly responded to, even if the decision to acknowledge the request is postponed (or) not taken into consideration.
Requirements should then be ranked in importance depending on a number of factors such as complexity, amount of work, risk, architectural changes, relevance to the product and so on.
The decision to include the requirement for the release during the maintenance period will be taken by the development team in consultation with the steering committee.
New requirements that are acknowledged (by the development team and the steering committee) make it to the roadmap and planned for specification and implementation. They are also added to the current set of requirements.