Where should things live?

Empieza revisando las dos ubicaciones propuestas en el issue para las especificaciones y reglas de deb/rpm, incluidos los pros y contras enumerados y el ejemplo de empaquetado de containerd enlazado. Se considera terminado cuando se haya tomado y documentado una decisión sobre la responsabilidad del repositorio, el momento de las actualizaciones, las pruebas, la cobertura de distribuciones y cómo se comunicarán los cambios.

Just a random ticket with a comment I wrote on slack;

I'm still undecided where the specs/rules would live best.

deb/rpm specs and rules in each repository

• PRO it's more "standard"? (people could build from the repo using standard tooling if it's in the expected location)
• PRO repo maintainers can also update the spec/rules if things change in the source/project
• PRO repo maintainers can test packaging before releasing
• CON is that repo maintainers now must update spec/rules if things change in the source/project (and packaging is an expertise not everyone knows all details about)
• CON is that ^^ if fixes are needed for packaging (in the spec/rules), those now require a new release

deb/rpm specs and rules in a central repository

• PRO maintainers with expertise on packaging (and all its quirks) can maintain the specs/rules, applying "best practice" and consistency
• PRO "packaging only" updates to specs/rules can be made independently of project releases (which includes changes to packaging related to "new distros added" or "EOL distros removed"
• CON less standard? (deb and rpm tools work well with specs/rules living together with the source?)
• CON when do we test packaging? We may discover issues after projects did a release.
• CON maintaining the files would become a shared responsibility, and maintainers of the packaging repository may not be notified / may not be aware when things change in project repositories.
• CON less likely to receive contributions
• PRO/CON central place to maintain the list of distros to package for (but could be communicated to the projects in other ways)

TBD how often the specs need updates; might be less complicated for CLI tools, but of course the devil is in the detail; some changes may be distro-specific, not due to changes in the project. Thinking of things like; https://github.com/docker/containerd-packaging/blob/6e368fae00d9e02d7eca6f751416c026516ece98/rpm/containerd.spec#L54-L57

TL;DR; either way makes sense, either way has pros/cons