Projects made by the community #35512
-
Edit: I want to know more about the "second" case - Something which is indirectly related to the project. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 12 replies
-
|
@denelon is there any process through which we can get something like "validated/supported by Microsoft", the community will be more interested in contributing and as a result, we can increase the development process and add new features faster so that people would stop calling official package manager of windows an awful, broken product, etc... |
Beta Was this translation helpful? Give feedback.
-
|
We would need to have anything "supported by Microsoft" moved to the Microsoft organization at GitHub for it to become supported. That's why I've been looking at the work in vedantmgoyal2009/winget-pkgs-automation to see about including it natively in the winget-pkgs repository. I really like the approach taken. We need to thoroughly review everything to see how much can be used "as is" vs. how much needs to be modified. We also have the concerns around who should be able to modify the files used to drive the automation. It's just going to take time and it's likely to take longer than we think. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it would be a better idea since the repository has already many files. Keeping it separate would make it a lot easy to manage the automation and individual package scripts. However, I have no problem in moving the whole repository under the Microsoft GitHub Org. I can simply do "transfer ownership". |
Beta Was this translation helpful? Give feedback.
-
|
@denelon More specifically, I wanted to know if anyone creates something like GitHub Actions, etc... How will that be handled? In the same way, reviewing the code thoroughly and seeing if anything is to be changed and blah blah blah... |
Beta Was this translation helpful? Give feedback.
-
|
Yes, any PR generated needs to be reviewed thoroughly. This holds true even for the core engineering team. When it comes to automation, or any binary delivered automatically to Windows via updates, we have a high bar, and several additional internal requirements. These include having other teams at Microsoft question and validate any concerns. The primary challenge this time of year is the availability of the various teams due to the holiday season. The rhythm of the business tends to slow down in mid to late November and pick up again in mid-January. With open-source projects, we may actually observe the opposite effect during the same time of year. People who are taking time off for the holidays may have a bit more time to tackle something more ambitious than usual because they have more free time. |
Beta Was this translation helpful? Give feedback.
-
|
@denelon I've created a GirHub Actions which developers can use it submit packages to winget. https://github.com/marketplace/actions/winget-releaser Original issue: #1515 Please let me know if there's any possibility to get it supported by Microsoft (a.k.a. moved under Microsoft org). It would be huge achievement for me, and I could attach it in my ECs 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
@vedantmgoyal2009 we've been discussing this for a while. It is work we want to do. I think the changes I've looked at are just naming for some of the key value pairs, and thoughts on how to structure this in the winget-pkgs repository. I think there will be many opinions and considerations to evaluate. I've been thrilled since I saw the work and how closely it aligned with my original vision for automating manifests for packages with new versions. The main challenge is determining the proper timing/sequencing to pull this in and make sure we aren't breaking anyone else's automation. We also need to consider what will happen when we open up the logical "ownership" for the ISV/Publisher who produces a package so they can manage their metadata and get feedback about their user experience as it pertains to install, upgrade, and uninstall. It will also open up the possibility for package level agreements in the community repository. What's an EC? You certainly deserve the credit for design and implementation! This has been a great help for everyone installing packages that are being kept current by automation you built. |
Beta Was this translation helpful? Give feedback.
-
|
@denelon I don't understand what it exactly means. The action uses YamlCreate under the hood. I can move the documentation to the README. Currently, it is at https://bittu.eu.org/docs/wr-intro, since I felt it was easy to maintain it along with documentation of other projects. |
Beta Was this translation helpful? Give feedback.
-
|
The modified YamlCreate isn't under the microsoft organization. I'd be looking at @Trenly to see if it makes sense to have a modified version or to find a way to integrate it into our existing version. |
Beta Was this translation helpful? Give feedback.
-
|
I think we would lean in the direction of supporting wingetcreate as well. Wingetcreate will support enterprise scenarios for REST sources. |
Beta Was this translation helpful? Give feedback.
-
|
That means I'll have to wait until YamlCreate v3.0.0 (with InputObject and Recursion support) is out. It is a work-in-progress. I've planned to switch both Automation and Action to the new https://github.com/Trenly/winget-pkgs/blob/Recursion/Tools/ManageManifests.ps1. For @Trenly's reference: the modified YamlCreate is 7-line addition (https://github.com/vedantmgoyal2009/winget-releaser/blob/main/YamlCreate.ps1#L939-L945) and removal of other modes (New Locale, New Package) + the interactive prompts. |
Beta Was this translation helpful? Give feedback.
-
I would say that since it is a modified version, I would be disinclined to support it. If there are bugs in the modification, it would be difficult to say that we will fix them if we don't own the modifications. In terms of finding a way to integrate into the existing version, this is what v3.0 (Recursion) is intended to do. I am still making progress on 3.0, but the logic is much more circular and complex to fully support input objects across all the various fields and scenarios that may make sense for an update. It will be a while before I think I would be ready to call 3.0 ready for testing. If there is a large demand for YamlCreate to natively support being called through a GitHub Action, then I would definitely consider a 2.2.0 release. But, in order to do that I would want to understand exactly which fields will need to be updated as part of it, and I will have to prioritize between that, AppsAndFeaturesEntries, Documentations, and all the other Schema 1.2 fields that aren't currently part of YamlCreate |
Beta Was this translation helpful? Give feedback.
@denelon is there any process through which we can get something like "validated/supported by Microsoft", the community will be more interested in contributing and as a result, we can increase the development process and add new features faster so that people would stop calling official package manager of windows an awful, broken product, etc...