Should we try to get a complete draft of What's New by b1?
Not to specifically pick on Eric V. Smith, but yesterday a co-worker came to me asking about `KW_ONLY` for dataclasses and wanting to provide feedback ( https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY). I said we had reached RC and so it was pretty much too late; the alphas and betas are when one should provide feedback. But then I realized you wouldn't even know about this new feature unless you read What's New ... and that's when I found out this new feature isn't mentioned (yet). As of right now the only dataclass feature documented in the What's New is something about slots ( https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses). So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
Yes, I think we should get it done by b1. For some reason it never occurred to me to add this to What's New. Someone just reported this on bpo this week. I'll try and get a PR together this week. Eric (who doesn't feel picked on!) On 8/11/2021 2:35 PM, Brett Cannon wrote:
Not to specifically pick on Eric V. Smith, but yesterday a co-worker came to me asking about `KW_ONLY` for dataclasses and wanting to provide feedback (https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY <https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY>). I said we had reached RC and so it was pretty much too late; the alphas and betas are when one should provide feedback.
But then I realized you wouldn't even know about this new feature unless you read What's New ... and that's when I found out this new feature isn't mentioned (yet). As of right now the only dataclass feature documented in the What's New is something about slots (https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses <https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses>).
So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YTXDZRAV... Code of Conduct: http://python.org/psf/codeofconduct/
11.08.21 21:35, Brett Cannon пише:
So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
I think that What's New should be updated as soon as possible, immediately after the addition of the feature. I started contributing to Python after reading What's New for one of early alphas of 3.3 (and the questioned feature was changed later). There were other examples, when features were advertised in alphas, but were changed after getting a feedback before betas.
On a broader note, how does the deployment pipeline for documentation work? It seems to me that for branches that are in pre-release (3.10) or active development (3.11), the documentation should be continuously deployed, while deployment of changes to earlier documentation should follow minor releases for those versions. Sorry this question is naive -- I don't know how it works currently. Would it be possible to set something like this up? On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
11.08.21 21:35, Brett Cannon пише:
So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
I think that What's New should be updated as soon as possible, immediately after the addition of the feature. I started contributing to Python after reading What's New for one of early alphas of 3.3 (and the questioned feature was changed later). There were other examples, when features were advertised in alphas, but were changed after getting a feedback before betas.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3... Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries <jdevries3133@gmail.com> wrote:
On a broader note, how does the deployment pipeline for documentation work? It seems to me that for branches that are in pre-release (3.10) or active development (3.11), the documentation should be continuously deployed, while deployment of changes to earlier documentation should follow minor releases for those versions.
Sorry this question is naive -- I don't know how it works currently. Would it be possible to set something like this up?
If you look at the version picker on docs.python.org you will see that we already have the docs for 3.10 and 3.11 available. I don't know if they are updated per release right now or per commit. -Brett
On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
11.08.21 21:35, Brett Cannon пише:
So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
I think that What's New should be updated as soon as possible, immediately after the addition of the feature. I started contributing to Python after reading What's New for one of early alphas of 3.3 (and the questioned feature was changed later). There were other examples, when features were advertised in alphas, but were changed after getting a feedback before betas.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V7E6UQPH... Code of Conduct: http://python.org/psf/codeofconduct/
If you look at the version picker on docs.python.org you will see that we already have the docs for 3.10 and 3.11 available. I don't know if they are updated per release right now or per commit.
I understand that they are available options. To clarify my suggestion, I think that 3.11 should be updated on a per commit basis (continuous deployment); including updating the what's new pages continuously. If that is not done already, I'm curious if it is been looked into before, and whether it might be possible to set things up like this? I was originally thinking that 3.10 documentation should be deployed continuously as well, but on further thought I realized that that would put the beta releases out of sync with the documentation which obviously does not make any sense. Maybe we could add a new tab to the version picker called 3.10/HEAD or similar. Maybe there's another solution? Either way, continuous deployment of documentation for 3.11 (or whatever version cpython/HEAD is at any given time) seems like it should be the norm if it isn't already. If that is already the case, I'm sorry for the noise! I still think that continuous deployment of documentation on the head of the beta or alpha release branches is worth considering, maybe with a different label on docs.python.org like "cpython/3.10@latest" or similar. On Thu, Aug 12, 2021, 12:46 PM Brett Cannon <brett@python.org> wrote:
On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries <jdevries3133@gmail.com> wrote:
On a broader note, how does the deployment pipeline for documentation work? It seems to me that for branches that are in pre-release (3.10) or active development (3.11), the documentation should be continuously deployed, while deployment of changes to earlier documentation should follow minor releases for those versions.
Sorry this question is naive -- I don't know how it works currently. Would it be possible to set something like this up?
If you look at the version picker on docs.python.org you will see that we already have the docs for 3.10 and 3.11 available. I don't know if they are updated per release right now or per commit.
-Brett
On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
11.08.21 21:35, Brett Cannon пише:
So my question is whether we want to push to be more diligent about updating What's New by b1 so people can provide feedback during the betas beyond just reporting breaking changes?
I think that What's New should be updated as soon as possible, immediately after the addition of the feature. I started contributing to Python after reading What's New for one of early alphas of 3.3 (and the questioned feature was changed later). There were other examples, when features were advertised in alphas, but were changed after getting a feedback before betas.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RQQ2QEV3... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V7E6UQPH... Code of Conduct: http://python.org/psf/codeofconduct/
On Aug 12, 2021, at 12:58, Jack DeVries <jdevries3133@gmail.com> wrote:
If you look at the version picker on docs.python.org you will see that we already have the docs for 3.10 and 3.11 available. I don't know if they are updated per release right now or per commit.
I understand that they are available options. To clarify my suggestion, I think that 3.11 should be updated on a per commit basis (continuous deployment); including updating the what's new pages continuously. If that is not done already, I'm curious if it is been looked into before, and whether it might be possible to set things up like this?
This is mainly from memory so some of the details may be incorrect but it's pretty close. The Python docs on python.org come in various formats - on-line HTML and various downloadable formats - and in English as well as various translated versions. It takes multiple hours on a dedicated virtual server to build the complete set of doc products, so updates are done on different cycles. The complete set of document products in all languages for branches either in feature development (currently 3.11), pre-release (3.10), or bugfix (3.9) status, are built and published every 24 hours. In addition, the on-line English html versions for these branches are re-built and published every 3 hours. Docs for security-fix branches (3.8, 3.7, 3.6) are generally only re-built when new releases are made. We also produce archived copies of the documentation current as of each release (https://www.python.org/doc/versions/). Julien Palard is the release team documentation expert who manages the doc build and translation processes, along with the PSF IT team headed by Ee Durbin. There is some information (not quite up-to-date) in the Dev Guide. The infrastructure code is primarily in https://github.com/python/docsbuild-scripts and https://github.com/python/psf-salt. -- Ned Deily nad@python.org -- []
participants (5)
-
Brett Cannon -
Eric V. Smith -
Jack DeVries -
Ned Deily -
Serhiy Storchaka