Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Thank you for helping improve the Swift programming language and ecosystem.
@tomerd - It would be nice to include a link to the package registry specification additions in the OP. They were part of the pitch and very informative.
As mentioned in the pitch thread, I am +1 on adding this. It's a very useful thing to add to the package manager and other tools.
I think the async status response and failure responses should be able to include a body, with a list of pending jobs that can be displayed in the UI while the user is waiting. Example.
It may take a bit of time to come up with a good data model for that response, but I think it would be a very, very valuable addition.
I agree. If I were reviewing this proposal for the first time I'd want to see those details.
I've given my feedback earlier on in the process and would like to see this proposal approved. I'd like to see a follow up proposal that standardizes the optional metadata key in the multi-part form request.