Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating Critical Chocolatey Packages To Chocolatey Community #1904

Closed
7 tasks done
AdmiringWorm opened this issue Jun 8, 2022 Discussed in #1898 · 5 comments
Closed
7 tasks done

Migrating Critical Chocolatey Packages To Chocolatey Community #1904

AdmiringWorm opened this issue Jun 8, 2022 Discussed in #1898 · 5 comments
Assignees
Labels
4 - Done Enhancement migration Migration of package from another repository to this one

Comments

@AdmiringWorm
Copy link
Member

AdmiringWorm commented Jun 8, 2022

Discussed in #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 asruby, 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:

@AdmiringWorm AdmiringWorm added Enhancement migration Migration of package from another repository to this one labels Jun 8, 2022
@AdmiringWorm AdmiringWorm changed the title Feedback Requested: Migrating Critical Chocolatey Packages To Chocolatey Community? Migrating Critical Chocolatey Packages To Chocolatey Community Jun 8, 2022
@pauby
Copy link
Member

pauby commented Oct 31, 2023

Answering the questions from #2336 (comment):

• 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
Copy link
Member Author

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
Copy link

jbpaux commented Nov 10, 2023

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
Copy link
Contributor

corbob commented Dec 21, 2023

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - Done Enhancement migration Migration of package from another repository to this one
Projects
None yet
Development

No branches or pull requests

5 participants