Andreas Enge <[email protected]> writes: > Dear team members, > > this message opens the deliberation period for > GCD 006: Updating the package deprecation policy and processes > > After lots of discussions and changes I think we have reached a state > of consensus; thanks to everybody who has taken part in the discussion > and thus helped to improve the proposal. > > The final proposal is attached and also available on Codeberg at the > pull request: > https://codeberg.org/guix/guix-consensus-documents/pulls/12 > > The procedure of GCD 001 says the following: > "Once the final version is published, team members have 14 days to send one > of the following replies on the patch-tracking entry of the GCD: > > - “I support”, meaning that one supports the proposal; > - “I accept”, meaning that one consents to the implementation of the > proposal; > - “I disapprove”, meaning that one opposes the implementation of the > proposal. A team member sending this reply should have made constructive > comments during the discussion period."
I support. One suggestion: the "Removal of building packages" section lists reasons a package may become a removal candidate in prose. An explicit enumeration would make it easier to reference in deprecation PRs: ``` A building package may become a removal candidate when, for instance: - a newer version is already available in Guix; (currently in #104) - the package is unmaintained or has reached end of life upstream; (#105) - the package has known security vulnerabilities left unpatched; (#135) - the package is not adequately maintained in Guix. (#106) ``` This doesn't change the policy, just makes the criteria scannable or at least to have them somewhere thats easy to reference, so we all start with the same vocabulary in a PR review. -- Thanos Apollo ☧ https://thanosapollo.org
signature.asc
Description: PGP signature
