chocolatey-community / chocolatey-packages

Chocolatey Community Maintainers Team Packages - packages that are managed and maintained by core community team for community package repository (https://community.chocolatey.org/packages)
https://community.chocolatey.org/profiles/chocolatey-community
Apache License 2.0
447 stars 377 forks source link

Migrating Critical Chocolatey Packages To Chocolatey Community #1904

Closed AdmiringWorm closed 2 months ago

AdmiringWorm commented 2 years ago

Discussed in https://github.com/chocolatey-community/chocolatey-packages/discussions/1898

Originally posted by **pauby** May 30, 2022 I have a proposal that I wanted to discuss with the Community here to find the best way to approach migrating critical Chocolatey packages to this repository. Chocolatey CLI requires specific packages for it's package sources such as`ruby`, `python` and `webpi`. There are also packages that are required for Chocolatey CLI features such as `intunewinappyutil`. And packages required for Chocolatey products such as `nexus` and `jenkins`. Different maintainers are responsible for these packages. To ensure Chocolatey has a secure, trusted and well-defined package management process, we have had some discussions internally and wanted to understand what the Community thought of: * Migrating the packages discussed above to this repository. * The use of the `CODEOWNERS` file ensures that the maintainers best placed to review package changes can do so, providing a trusted and secure process for those critical packages. * Use the automation that already exists in this repository to ensure packages are up-to-date. I see the benefits to the Community as * Members of the Chocolatey Team would be available to help with management of the repository. * Increased number of package maintainers, able to work on packages and review / merge PR's. * The migrated packages would be open-source in this repository, allowing others to get involved in helping to resolve problems and add new features The two important things that I wanted to ensure from this is: * A secure, trusted and well-defined process for managing critical Chocolatey packages. * Increase in the number of Community maintainers working in this repository. I believe this will provide both of those, and I hope that it will encourage other new and experienced maintainers to become involved too. I would really like to see this repository thrive, and I feel this is a good step on that path. Please let me know your thoughts.

The full list of packages that will be migrated are shown below:

Additionally, there is a need to create a new package that will be part of this as well for the following software:

pauby commented 11 months ago

Answering the questions from https://github.com/chocolatey-community/chocolatey-packages/pull/2336#issuecomment-1786991828:

• Replace azcopy package with content of azcopy10 package (and maybe create an azcopy8 package with old content if people still want to use an old version) • Publish azcopy 10.X as azcopy package • "Deprecate" azcopy10 package by putting it as a dependency of azcopy package so people can migrate to it

I think this woudl be a good idea to do. But would be outside of the scope of this issue (which is about migrating critical packages to the Chocolatey Community).

I would be curious as to what @corbob and @AdmiringWorm think about doing this right now rather than migrating in azcopy10 and then doing the work to azcopy?

AdmiringWorm commented 11 months ago

If we down the line wants to create an azcopy8 package, then let us keep the content in the azcopy10 package, and rather change the azcopy to be a meta package that depends on it (similar to how the python packages operates).

jbpaux commented 10 months ago

I honestly think nobody still use azcopy 8 (current azcopy package) and we should replace azcopy10 package to azcopy and in the interim add azcopy as a dependency of azcopy10 so people migrate to it smoothly and in a midterm future delete azcopy10 package. (but maybe out of scope of this issue, sorry)

corbob commented 9 months ago

I'm with @AdmiringWorm on this. If we change things, then azcopy should be a meta package that takes azcopy10 as the dependency. The reason for this in my mind is if version 11 comes out, anyone depending on azcopy would get upgraded, but if they do what they did with 8 vs 10, then this may not be the desired behaviour.

AdmiringWorm commented 2 months ago

All the packages that were meant to be migrated are done, as such I will close this issue now.