Plan MIL-007 and UC-002; AGPL-3.0 default only for a public GitHub project
- MIL-006: the AGPL-3.0 default needs GitHub and a public project - MIL-007: fetch the framework's own submodules (qc); start through a command link; README usage - UC-002 with SSD, DM, OC, SD and DCD; US-001.07 and US-002 - Reconcile the project DM, DCD, dictionary, use case diagram and traceability matrix - Review records RC-022 to RC-028
This commit is contained in:
@@ -10,12 +10,13 @@
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-06 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | [d773fa9] |
|
||||
| 2026-10-07 | Proposed | Jens Tirsvad Nielsen | S02 | AGPL-3.0 default only when GitHub is chosen and the project is public (purpose, resolution order, criterion 3, tasks 1 and 4) | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Decide whether the project's license can be set in `config.env` without weakening the existing behaviour: a license that is set applies with or without GitHub, `none` means no license, an absent key keeps today's rule (AGPL-3.0 only when GitHub is chosen), and a license the Gitea server does not offer stops the run before anything is created.
|
||||
Decide whether the project's license can be set in `config.env` without weakening the existing behaviour: a license that is set applies with or without GitHub, `none` means no license, an absent key gives AGPL-3.0 only when GitHub is chosen and the project is public, and a license the Gitea server does not offer stops the run before anything is created.
|
||||
|
||||
## Deliverable
|
||||
|
||||
@@ -27,7 +28,7 @@ The key (present counts as set, as for the other project details of [MIL-004]; a
|
||||
| --- | --- | --- |
|
||||
| `PROJECT_LICENSE` | the license of the project | a Gitea license key (letters, digits, `.`, `+`, `-`, at most 64 characters), such as `AGPL-3.0` or `MIT`, or `none` |
|
||||
|
||||
The license that applies is resolved in this order: `PROJECT_LICENSE` when set (`none` means no license), otherwise AGPL-3.0 when GitHub is chosen, otherwise none. It is never asked: the key is an optional project detail in `config.env`, not a prompt.
|
||||
The license that applies is resolved in this order: `PROJECT_LICENSE` when set (`none` means no license), otherwise AGPL-3.0 when GitHub is chosen and the project is public, otherwise none. A private project with GitHub therefore gets no license by default. It is never asked: the key is an optional project detail in `config.env`, not a prompt.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
@@ -35,7 +36,7 @@ The license that applies is resolved in this order: `PROJECT_LICENSE` when set (
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | With `PROJECT_LICENSE` set to a license the server offers, the Gitea repository is created with that license, with GitHub and without it, and the plan and summary show it as coming from `config.env` | Tests pass | Another license, none, or no marker |
|
||||
| 2 | `PROJECT_LICENSE=none`: the Gitea repository has no license, also when GitHub is chosen | Tests pass | Any license applied |
|
||||
| 3 | `PROJECT_LICENSE` absent: AGPL-3.0 when GitHub is chosen and none otherwise, exactly as before; the existing tests pass unchanged | Tests pass | Any change of behaviour |
|
||||
| 3 | `PROJECT_LICENSE` absent: AGPL-3.0 when GitHub is chosen and the project is public; none for a private project with GitHub, and none without GitHub; the plan and summary say which rule applied | Tests pass | AGPL-3.0 on a private project, or no AGPL-3.0 on a public project with GitHub |
|
||||
| 4 | An empty or invalid value stops the run before any request to a host, names the key and never falls back to asking | Tests pass | A request made or a prompt shown |
|
||||
| 5 | A license the Gitea server does not offer stops the run before anything is created and names the license | Tests pass | Anything created |
|
||||
| 6 | The license is never asked, with the key set, absent or invalid | Tests pass | Any prompt for it |
|
||||
@@ -71,10 +72,10 @@ The license that applies is resolved in this order: `PROJECT_LICENSE` when set (
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Read and validate `PROJECT_LICENSE` | Add the key to the `config.env` parser and its validator (a license key or `none`; empty refused; errors name the key). Resolve the license that applies into the project request (key set, else AGPL-3.0 with GitHub, else none) and mark it `(from config.env)` in the summary. Never asked. Extensions of step 3 of [UC-001]. | Yes | [UC-001] |
|
||||
| 1 | Read and validate `PROJECT_LICENSE` | Add the key to the `config.env` parser and its validator (a license key or `none`; empty refused; errors name the key). Resolve the license that applies into the project request (key set, else AGPL-3.0 with GitHub and a public project, else none) and mark it `(from config.env)` in the summary. Never asked. Extensions of step 3 of [UC-001]. | Yes | [UC-001] |
|
||||
| 2 | Apply the license on Gitea, independent of GitHub | Generalize the preflight check from the fixed AGPL-3.0 to the license that applies (checked only when one applies); create the repository with it; the plan, the summary and the reuse warning name the license that applies instead of AGPL-3.0; GitHub receives the file through the mirror as before. Extension 4c and step 6 of [UC-001]. | Yes | [UC-001] |
|
||||
| 3 | Document the key | Commented example in `config.env.example`, a row in the README table of project details, and the rule for the license that applies, including `none` and the default. | No | |
|
||||
| 4 | Test every case | Key set (with and without GitHub), `none`, absent, empty, invalid and not offered by the server; never asked; the summary marker; the existing tests unchanged. | No | |
|
||||
| 4 | Test every case | Key set (with and without GitHub), `none`, absent (public and private, with and without GitHub), empty, invalid and not offered by the server; never asked; the summary marker; the existing tests changed only where a private project with GitHub no longer gets AGPL-3.0. | No | |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
# MIL-007 Framework Checklists and Usage
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | MIL-007 |
|
||||
| CrossReference | [BC-001], [US-001], [UC-001], [UC-002] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-07 | Proposed | Jens Tirsvad Nielsen | S02 | Initial version | pending |
|
||||
| 2026-10-07 | Proposed | Jens Tirsvad Nielsen | S02 | Added UC-002 and US-002 (global command); tasks 2 and 3 trace to UC-002 | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Decide whether a new project holds the whole framework, including the `qc` checklists that the framework keeps in its own submodule, and whether a Maintainer can start the script from the folder where the project is to be created, through a global command, with the README saying exactly how.
|
||||
|
||||
## Deliverable
|
||||
|
||||
1. `create-project.sh` that, after adding the `framework` submodule (and when `framework` already exists as that submodule), runs `git submodule update --init --recursive` in the new project, so `framework/qc/` holds the checklists.
|
||||
2. `create-project.sh` that finds its own files when started through a symlink, so a link in a folder on `PATH` works from any directory.
|
||||
3. A README usage section that says: run the script from the folder in which the project is to be created (the default directory is `./<name>` relative to where it is started), keep `config.env` and `.env` in the checkout and point to them with `--config` and `--env` or place them where the script reads them, and make the script global with a worked example (a symlink in a `PATH` folder, with the check that it works), for Linux, macOS and Git Bash on Windows.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
| # | Criterion (objectively checkable) | Go | No-Go |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | After a run, `framework/qc/` in the new project holds the checklist files and `git submodule status --recursive` shows no entry starting with `-` | Tests pass | An empty `qc` |
|
||||
| 2 | A second run on a project whose `qc` is empty fills it and changes nothing else; on a complete project it changes nothing | Tests pass | Anything else changed |
|
||||
| 3 | A failed nested fetch stops the step, reports what exists, names `git submodule update --init --recursive` as the command to run by hand and shows no credential | Tests pass | A credential shown, or the failure not reported |
|
||||
| 4 | A framework without a submodule of its own does not make the step fail | Tests pass | Step fails |
|
||||
| 5 | Started through a symlink in another folder, `create-project.sh --help` works and a run creates the project under the current folder | Tests pass | Files not found, or the project created elsewhere |
|
||||
| 6 | The README example for the global command was run once as written and its check passed | Verified | An example that was not run |
|
||||
| 7 | The README states the folder to start from and where the new project lands, with an example from a folder that is not the checkout | Reviewed by S02 | Missing or unclear |
|
||||
| 8 | All acceptance criteria of US-001.07 and US-002 in [US-001] are met | Verified | Any unmet |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Depends on | Reason |
|
||||
| --- | --- |
|
||||
| [MIL-003] | The framework step and the README already exist |
|
||||
|
||||
## Traceability
|
||||
|
||||
| Business Case objective / KPI / user story | Reference |
|
||||
| --- | --- |
|
||||
| User stories US-001.07 and US-002 | [US-001] |
|
||||
| Objective 5 (the framework submodule) | [BC-001] |
|
||||
| Objective 11 (global command) and success criterion 11 | [BC-001] |
|
||||
| Objective 7 (documentation) | [BC-001] |
|
||||
|
||||
## Ownership
|
||||
|
||||
| Role | Stakeholder ID (SA) |
|
||||
| --- | --- |
|
||||
| Owner | S01 |
|
||||
| Approving reviewer | S02 |
|
||||
|
||||
## Target Date
|
||||
|
||||
2026-12-11 — proposed; the Business Case sets no deadline.
|
||||
|
||||
## Tasks
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Fetch the framework's own submodules | After `git submodule add` of the framework, and on the "already a submodule" path, run `git submodule update --init --recursive` in the new project. A failure stops the step, reports what exists and names the command to run by hand, without a credential. Step 9 and extension 9e of [UC-001]. | Yes | [UC-001] |
|
||||
| 2 | Start through a command link | Resolve `BASH_SOURCE` through links (without requiring `readlink -f`, which macOS lacks) so `SCRIPT_DIR` and `PROJECT_ROOT` point into the checkout, and keep the current folder as the base of the default directory. Errors name the folder or path looked in. Steps 3 to 6 and extensions 4a and 4b of [UC-002]. | Yes | [UC-002] |
|
||||
| 3 | Document the usage | Step 1 and extensions 1a and 3a of [UC-002]. README usage section: start from the folder where the project is to be created, where `config.env` and `.env` are read from, `--config` and `--env`, and the global command with a worked example and its check, for Linux, macOS and Git Bash on Windows. | Yes | [UC-002] |
|
||||
| 4 | Test every case | `qc` filled after a run and after a rerun, nested fetch failure, framework without a submodule, start through a symlink from another folder. | No | |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../business-case.md
|
||||
[US-001]: ../user-stories.md
|
||||
[UC-001]: ../uc-001/uc.md
|
||||
[UC-002]: ../uc-002/uc.md
|
||||
[MIL-003]: ./mil-003-scaffold-and-release.md
|
||||
Reference in New Issue
Block a user