Cygwin
Get that Linux feeling - on Windows
Trusted Maintainer Policy Guidelines (draft)
Trusted Maintainers
"trusted" maintainers have additional permissions, so they can:
-
Modify the package
maintainer database to handle ITPs, package orphaning, adoption and
removal.
Since they could simply modify that to add themselves as a maintainer for
any package, to save steps they can also:
-
Upload, git push, deploy, vault, etc. all packages (orphaned or not), as if
they were the package maintainer.
Policy Notes
Guidelines for trusted maintainers:
On making changes to the package maintainer database
-
Please keep the list alphabetically sorted (ideally we would have some sort
of pre-update hook to enforce this).
-
You can handle ITAs (of your own or others).
-
You can handle ITPs (of your own or others), which meet the
submission
rules in the Packaging Guide (which perhaps needs to be broken out as
a separate section there).
You are expected to exercise good judgement and due diligence in checking
that the package license is compatible with our project mission, and that
the package content doesn't violate our hosting provider's legal guidelines
(i.e. no content which potentially infringes on patents or trademarks, or
is illegal or offensive).
-
You can handle requests from a maintainer to orphan their package.
-
You can vault versions of an orphaned package which are clearly useless or
obviously broken (e.g. the installation prerequisites have been removed).
(Please ensure the packaging git repo is up to date before doing
this).
-
You can remove an package which has no versions left in the package
repository.
On NMUs (Non-maintainer uploads)
-
Ping on cygwin-apps, Bcc-ing the maintainer, politely asking for an
update...
-
... and wait 7 days. (This step is optional in 'urgent' cases).
On orphaning abandoned packages
-
Ping on cygwin-apps, Bcc-ing the maintainer, politely asking if they intend
to continue as maintainer...
-
... and wait 28 days.
-
If they reply in the negative or don't reply, you can orphan the package.
(It's a good idea to ensure that the packaging repo history is up-to-date
after taking that step).
Since they could simply modify that to add themselves as a maintainer for any package, to save steps they can also:
On making changes to the package maintainer database
- Please keep the list alphabetically sorted (ideally we would have some sort of pre-update hook to enforce this).
- You can handle ITAs (of your own or others).
-
You can handle ITPs (of your own or others), which meet the
submission
rules in the Packaging Guide (which perhaps needs to be broken out as
a separate section there).
You are expected to exercise good judgement and due diligence in checking that the package license is compatible with our project mission, and that the package content doesn't violate our hosting provider's legal guidelines (i.e. no content which potentially infringes on patents or trademarks, or is illegal or offensive). - You can handle requests from a maintainer to orphan their package.
-
You can vault versions of an orphaned package which are clearly useless or
obviously broken (e.g. the installation prerequisites have been removed).
(Please ensure the packaging git repo is up to date before doing this). - You can remove an package which has no versions left in the package repository.
On NMUs (Non-maintainer uploads)
- Ping on cygwin-apps, Bcc-ing the maintainer, politely asking for an update...
- ... and wait 7 days. (This step is optional in 'urgent' cases).
On orphaning abandoned packages
- Ping on cygwin-apps, Bcc-ing the maintainer, politely asking if they intend to continue as maintainer...
- ... and wait 28 days.
-
If they reply in the negative or don't reply, you can orphan the package.
(It's a good idea to ensure that the packaging repo history is up-to-date after taking that step).
... and remember, only use your powers for good!