0ct0pu5/moby
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #47319 from coolljt0725/fix_broken_links

Browse source 
Fix broken links in project
This commit is contained in:
Sebastiaan van Stijn 2024-02-05 09:31:17 +01:00 • committed by GitHub
commit ee3c710f22
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 5 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
project/README.md
View file

@ -11,7 +11,7 @@ If you're a *maintainer* or aspiring maintainer, you should read [MAINTAINERS](.
If you're a *packager* or aspiring packager, you should read [PACKAGERS.md](./PACKAGERS.md).
If you're a maintainer in charge of a *release*, you should read [RELEASE-CHECKLIST.md](./RELEASE-CHECKLIST.md).
If you're a maintainer in charge of a *release*, you should read [RELEASE-PROCESS.md](./RELEASE-PROCESS.md).
## Roadmap

10
project/REVIEWING.md
View file

@ -226,12 +226,10 @@ review session. The goal of that session is to agree on one of the following out
## Milestones
Typically, every merged pull request get shipped naturally with the next release cut from the
`master` branch (either the next minor or major version, as indicated by the
[`VERSION`](https://github.com/docker/docker/blob/master/VERSION) file at the root of the
repository). However, the time-based nature of the release process provides no guarantee that a
given pull request will get merged in time. In other words, all open pull requests are implicitly
considered part of the next minor or major release milestone, and this won't be materialized on
GitHub.
`master` branch (either the next minor or major version). However, the time-based nature of the
release process provides no guarantee that a given pull request will get merged in time. In other
words, all open pull requests are implicitly considered part of the next minor or major release
milestone, and this won't be materialized on GitHub.
A merged pull request must be attached to the milestone corresponding to the release in which it
will be shipped: this is both useful for tracking, and to help the release manager with the