meson/docs/markdown/Wrap-review-guidelines.md

# Wrap review guidelines

In order to get a package in the Wrap database it must be reviewed and
accepted by someone with admin rights. Here is a list of items to
check in the review. If some item is not met it does not mean that the
package is rejected. What should be done will be determined on a
case-by-case basis. Similarly meeting all these requirements does not
guarantee that the package will get accepted. Use common sense.

## Checklist

Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.

    - [ ] project() has version string
    - [ ] project() has license string
    - [ ] if new project, master has tagged commit as only commit
    - [ ] if new branch, it is branched from master
    - [ ] contains a readme.txt
    - [ ] contains an upstream.wrap file
    - [ ] download link points to authoritative upstream location
    - [ ] wrap repository contains only build system files
    - [ ] merge request is pointed to correct target branch (not master)
    - [ ] wrap works
    - [ ] repo does not have useless top level directory (i.e. libfoobar-1.0.0)
docs: Import the website and wiki and build with hotdoc This allows us to more easily have the documentation in sync with the source code as people will have to document new features etc right at the time where they implement it. 8 years ago			`# Wrap review guidelines`

Rewrapped lines of a few more files. 7 years ago			`In order to get a package in the Wrap database it must be reviewed and`
			`accepted by someone with admin rights. Here is a list of items to`
			`check in the review. If some item is not met it does not mean that the`
			`package is rejected. What should be done will be determined on a`
			`case-by-case basis. Similarly meeting all these requirements does not`
			`guarantee that the package will get accepted. Use common sense.`
docs: Import the website and wiki and build with hotdoc This allows us to more easily have the documentation in sync with the source code as people will have to document new features etc right at the time where they implement it. 8 years ago
docs: Markdown headers don't need trailing hash signs This is a cosmetic change because github seems to interpret those correctly. Nonetheless, it adds unnecessary noise and makes people modifying the pages think it might be needed. See syntax guide at https://guides.github.com/features/mastering-markdown/ 7 years ago			`## Checklist`
docs: Import the website and wiki and build with hotdoc This allows us to more easily have the documentation in sync with the source code as people will have to document new features etc right at the time where they implement it. 8 years ago
doc: Fix several minor typos. 8 years ago			`Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.`
docs: Import the website and wiki and build with hotdoc This allows us to more easily have the documentation in sync with the source code as people will have to document new features etc right at the time where they implement it. 8 years ago
			`- [ ] project() has version string`
			`- [ ] project() has license string`
			`- [ ] if new project, master has tagged commit as only commit`
			`- [ ] if new branch, it is branched from master`
			`- [ ] contains a readme.txt`
			`- [ ] contains an upstream.wrap file`
			`- [ ] download link points to authoritative upstream location`
			`- [ ] wrap repository contains only build system files`
			`- [ ] merge request is pointed to correct target branch (not master)`
			`- [ ] wrap works`
			`- [ ] repo does not have useless top level directory (i.e. libfoobar-1.0.0)`