Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
I am just quietly following all the good ideas and solutions that you github experts are coming up with. Many thanks for this! While we are at it, here is another thought: In the revision history I think that it would it be meaningful to have "subheadings" for each version of the conventions document together with its release data. The reason for this is that we are now and then discussing that in a file adhering to CF-1.X there might be a metadata construct that is defined/superseded/invalidated in a more recent version of the conventions, and that this is not a problem as it is known in which version a certain construct is introduced. E.g. something like > > * **Version 1.0, 28 October, 2003** > Initial release. > * **Version 1.1, 17 January, 2008** > 14 June 2004: > Added the section called “Lambert azimuthal equal area”. the section called > "Polar Stereographic" : Added latitude_of_projection_origin map parameter. > 1 July 2004: > 1/ Section 5.7, "Scalar Coordinate Variables" : Added note that use of > scalar coordinate variables inhibits interoperability with COARDS conforming > applications. > 2/ Example 5.13, "Multiple forecasts from a single analysis" : Added > positive attribute to the scalar coordinate p500 to make it unambiguous that > the pressure is a vertical coordinate value. > ... ... > 17 January 2008: > 1/ Preface : Changed text to refer to rules of CF governance, and > provisional status. > 2/ Chapter 4, Coordinate Types , Chapter 5, Coordinate Systems and Domain : > Made changes regarding use of the axis attribute to identify horizontal > coordinate variables. > ~~3/ Changed document version to 1.1.~~ > * **Version 1.2, 4 May, 2008** > 4 May 2008: > 1/ Section 5.6, "Horizontal Coordinate Reference Systems, Grid Mappings, and > Projections", Appendix F, Grid Mappings : Additions and revisions to CF grid > mapping attributes to support the specification of coordinate reference > system properties (Trac ticket #18). > 2/ Table 3.1, "Supported Units" : Corrected Prefix for Factor "1e-2" from > "deci" to "centi". (Trac ticket #25). > ~~3/ Changed document version to 1.2.~~ and so on, but of course properly formatted. This might take some manual work, which should not delay releasing 1.10 before if need be. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1008780218__;Iw!!G2kpM7uM-TzIFchu!iagRwVjflPgUvkwTEN3uLGj_Dy_iQGZr0gQiOyqRYMwY7M5h__jOqArJrCOXAApUuEBLhMBVTcw$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Perhaps my previous comment was a bit obtuse. With regards to @erget's and @davidhassell's comments > [Daniel > wrote](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006644633__;Iw!!G2kpM7uM-TzIFchu!m-BEKDNGskMuc_Oe2W9Abw9PsFrtTgIzNuOlrIIzIA0KvWRrfXFElemlYoDqEWbHGY6CDC8b_TE$ > ): > > Barring that, this can be discovered by pulling up closed PRs and sorting > > by date, then checking what was merged into main between releases - that is > > however more laborious, so labeling the PRs pre-merge would be the most > > expedient in my view. > > That is exactly what I did when applying many of those milestones - and it > was indeed laborious. Labelling them at merge-time would be a great addition > to the workflow. I wanted to point out that this process can and should be automatized using the github api. It is really only a few lines of code (the changelog script I referenced above is less than 200 lines and includes formatting and filtering). With this, the task won't be laborious anymore. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007593004__;Iw!!G2kpM7uM-TzIFchu!m-BEKDNGskMuc_Oe2W9Abw9PsFrtTgIzNuOlrIIzIA0KvWRrfXFElemlYoDqEWbHGY6Cw67emew$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Dear Jonathan, You can see the milestone, but it's easy to miss, as it's not formatted the same as a label:  The proposed "Change agreed" label is still a good idea, in addition to the milestone. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007469405__;Iw!!G2kpM7uM-TzIFchu!ky5eQLERB8oJzQOTQu2EfIrbmm2NkdHA17BA3OuxDvRuA4t4V_DD3Y1NHSwqKA_I8xq_g8zj-qA$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
We could always correct 1.9 using the procedure for errata so that 1.9 remains valid - leaving the error in 1.9 and minting a new release to correct it would be similar to deprecating 1.9, which would be new ground. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007410745__;Iw!!G2kpM7uM-TzIFchu!hnL4EzBzlInfFn7ZOZCN7SvSHpKlGHX0f_ay_5sxkfKUK-6tWHT7CzmdIojNihuq95-wJrmHfvY$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Dear @davidhassell Thanks for explaining about milestones. As a test I have just attributed the [closed issue about lossy compression by coordinate sampling](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327__;!!G2kpM7uM-TzIFchu!jKwQhdcB1F3gJcezSDgXZxVKmnZBKVAz1ut83Xn79F6kDlV_Fu8h3zyKHM8v_P-lgp58GQyNKXk$ ) to milestone 1.9. That is obvious when you open the issue, but you don't see it in the list of issues or when hovering on the issue, so a label saying "Change agreed" would be separately useful still. You can also filter the issues as Daniel showed for PRs. [Filtering the closed issues for the 1.9 milestone](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues?q=is*3Aissue*is*3Aclosed*milestone*3A1.9__;JSslKyU!!G2kpM7uM-TzIFchu!jKwQhdcB1F3gJcezSDgXZxVKmnZBKVAz1ut83Xn79F6kDlV_Fu8h3zyKHM8v_P-lgp586HawF-U$ ) now shows just the one I have tagged. It's OK not to make a special release in order to fix this defect if we're sure there's not much danger of anyone coding `Conventions` as 1.8 instead of 1.9 without thinking about it. Cheers Jonathan -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007408268__;Iw!!G2kpM7uM-TzIFchu!jKwQhdcB1F3gJcezSDgXZxVKmnZBKVAz1ut83Xn79F6kDlV_Fu8h3zyKHM8v_P-lgp58QfEEeXg$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
@davidhassell agree with all your points. I also agree about the issue labels of changes being agreed or not, that would be easy to do and add value. When we consider these process changes agreed, we should document them, e.g. in Rules.md or in the PR templates, in the form of a checklist. They're simple to do but would need easy presentation so that they don't get forgotten. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1007261578__;Iw!!G2kpM7uM-TzIFchu!gtcpnk-hOgpXm09GDPhi-17oGQz664bIwNWGLLj_gZx1uTQLMeR9fdJ8aRnr1rzd71RuwuKWkVw$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Hello all, My (current) thoughts on the new release question: I'm not sure about cutting 1.10 to fix just this defect. Given that it can be fixed in the latest CF-1.10 draft, is that not sufficient to tide us over to the whenever CF-1.10 is released? A few years ago we agreed that one release, or perhaps two releases, per year was a good balance; which to me, at least, means that any extra release in the year should be reserved for either getting new functionality out to users with production time constraints, or else correcting a serious error. I'm not sure that this defect (important as it is!) adds new features, nor warrants the "serious" label. I like the idea of per-release history entries, and "(No) change agreed" issue labels. I would find those very useful. [Daniel wrote](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006644633__;Iw!!G2kpM7uM-TzIFchu!hOibaETdBKBrgpir550s20Qgv0K4JPNqTVGMPwPWHbh_TsLOJvVB3rqUEqcGtYbWStY00KX05FY$ ): > Barring that, this can be discovered by pulling up closed PRs and sorting by > date, then checking what was merged into main between releases - that is > however more laborious, so labeling the PRs pre-merge would be the most > expedient in my view. That is exactly what I did when applying many of those milestones - and it was indeed laborious. Labelling them at merge-time would be a great addition to the workflow. Setting a milestone on a PR (or issue) is very similar to setting a label - it's on the right hand panel just below where the label-setting feature is. I have just created a 1.10 milestone (via https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/milestones__;!!G2kpM7uM-TzIFchu!hOibaETdBKBrgpir550s20Qgv0K4JPNqTVGMPwPWHbh_TsLOJvVB3rqUEqcGtYbWStY0SJa4pZs$ ). Thanks, David -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006955695__;Iw!!G2kpM7uM-TzIFchu!hOibaETdBKBrgpir550s20Qgv0K4JPNqTVGMPwPWHbh_TsLOJvVB3rqUEqcGtYbWStY0sY8vyaw$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
I agree, per-release headers in History would be helpful. @JonathanGregory - I like the idea of closing inactive issues after some period of dormancy and adding a "No change agreed" label to those issues. I also like the idea of adding a "Change agreed" label to issues as they are agreed (and PRs merged). -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006764920__;Iw!!G2kpM7uM-TzIFchu!gSsjmfg_GZkiRu3o-z6W_nLiNQBwBB0ZRkc4yr7gJht66UCG7_6D8UdI64jxqFtOweVJ20HAGVE$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
> @JonathanGregory I agree that a per-release entry in History would make sense. OK. If others agree, this is something we could introduce in 1.10, and it might not be too hard to insert those headings for all the previous versions. > What you propose regarding labels would work, although it might be simpler if > we track them by pull requests. ... This has been made easy for 1.9 as shown > by [this > filter](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pulls?q=is*3Apr*is*3Aclosed*sort*3Aupdated-desc*milestone*3A1.9__;JSslKyUrJQ!!G2kpM7uM-TzIFchu!h1cVF0ZY_-rnSXxaKt6O3ektrxVFu9le3PS-9SdJ89aMd1smc48A9OhKLSNWiwFbMoc5PeLCVQk$ > ) showing those PRs that were manually tagged as going into 1.9. ... > Labeling the PRs pre-merge would be the most expedient in my view. Thanks. That is neat. How do you tag the PRs in this way? I agree that it would be sensible to do that as it is agreed that a PR will be merged at the next release. However, this doesn't tag the issues, does it? Therefore I think it would still be useful to add a label to the issue once it's agreed to update the convention, for instance "Change agreed". This label would remain forever, and by following the link in the issue to its PR, tagged in the way you describe, you could find out which version it affected. I would also propose a complementary label "No change agreed", to be applied to any issue which we close because it doesn't seem that it's going to reach a conclusion. Of course any closed issue could be reopened and the label removed. I feel that it's better to close issues than to leave them forever dormant. Do others agree, or am I being tempted by excessive tidiness? -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006751005__;Iw!!G2kpM7uM-TzIFchu!h1cVF0ZY_-rnSXxaKt6O3ektrxVFu9le3PS-9SdJ89aMd1smc48A9OhKLSNWiwFbMoc5UPAXQNc$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
For reference, in ESMValTool we use just the process that @erget described to generate the changelog using [this script](https://urldefense.us/v3/__https://github.com/ESMValGroup/ESMValTool/blob/main/esmvaltool/utils/draft_release_notes.py__;!!G2kpM7uM-TzIFchu!mEdDWp3uFu7z4p9FhhD25ii80KIQFhpsRbJBmtnpWrqdONx9ZPuMEizM_bMYvJyqFiYtzGi4Pa4$ ). We are considering replacing this with one of the many available standard solutions that do a similar thing. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006748698__;Iw!!G2kpM7uM-TzIFchu!mEdDWp3uFu7z4p9FhhD25ii80KIQFhpsRbJBmtnpWrqdONx9ZPuMEizM_bMYvJyqFiYtpVW4UVk$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
@JonathanGregory I agree that a per-release entry in History would make sense. What you propose regarding labels would work, although it might be simpler if we track them by pull requests. This is a common pattern in the software development world. This has been made easy for 1.9 as shown by [this filter](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pulls?q=is*3Apr*is*3Aclosed*sort*3Aupdated-desc*milestone*3A1.9__;JSslKyUrJQ!!G2kpM7uM-TzIFchu!ivMSC2HJq-YCLwK0BeitySBXv3CAIO1p9skWWONzVAEI2DPu_4Wcznuylq7VMXtvkx341r-KSb4$ ) showing those PRs that were manually tagged as going into 1.9. If we were to do that again for 1.10 we would have such an overview, and the PRs would of course link back to their respective issues. Barring that, this can be discovered by pulling up closed PRs and sorting by date, then checking what was merged into `main` between releases - that is however more laborious, so labeling the PRs pre-merge would be the most expedient in my view. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006644633__;Iw!!G2kpM7uM-TzIFchu!ivMSC2HJq-YCLwK0BeitySBXv3CAIO1p9skWWONzVAEI2DPu_4Wcznuylq7VMXtvkx345Y6bHxM$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
Separately, I would like to suggest that when we close issues in this repository which have been agreed to be implemented in the next release, we should add another label that indicates this e.g. "1.9" for all the ones added to the present version. Those new labels can all be the same colour, to conserve the visual spectrum. I think these labels might be useful when looking at the repo subsequently. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006593459__;Iw!!G2kpM7uM-TzIFchu!mjoq12mBpBMW03dfJZ39AaDXxG2Sk-mQb3g7FpDq0OAecBdvP9tL0v74L87yeEQnWsGLPoA4rsE$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
We could put headings in the history section (in `history.adoc`), starting a new one in each new release. Thus, the history section in the present draft would begin with a title something like "Differences between 1.9 and 1.10", and there would be nothing there. Just to be clear, we could write "Nothing yet" underneath, and delete it in the subsequent changes! Does that make sense? -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006591458__;Iw!!G2kpM7uM-TzIFchu!llifoEiYRK0xT7lJ2e_wleg1MDNaRcWnXiNbhChbguJUlZ7cvho0nYTSt2KVAVjmLh7L3vEhZVA$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
@davidhassell ping - thoughts here? (1) is a very good question - is there an easy way to generate such an overview in the absence of updates to the history section of the document? I imagine GitHub would be helpful, and it might be even easier if we use milestones that could be attached to PRs but AFAIK we're not doing that. -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345*issuecomment-1006423070__;Iw!!G2kpM7uM-TzIFchu!nPUC0VMZ9Y8l7dT2INGIm5AClqwSFRGhh1sse06g2VioOaWeo2PqABo4SCiXhG5xTn_r2ZUFeo4$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
[CF-metadata] [cf-convention/cf-conventions] Cutting version 1.10 (Issue #345)
In issue #343 [Jonathan asks](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/343*issuecomment-1005741937__;Iw!!G2kpM7uM-TzIFchu!n8Z5nIZTTWVzomqeuffRYnB6kwOLeb6JQ2nRaVjEwhi98fhRO2TX2457UHavJvolaIIuh1z-tfg$ ) > Is there a reason why we should not release 1.10 with this change as soon as > we've agreed it, and any others agreed since 1.9, and then start preparing > 1.11 for release in the summer? which prompted a couple of thoughts: 1. I was looking for what would be new or changed. But between the revision histories of [v1.9](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html*revhistory__;Iw!!G2kpM7uM-TzIFchu!n8Z5nIZTTWVzomqeuffRYnB6kwOLeb6JQ2nRaVjEwhi98fhRO2TX2457UHavJvolaIIuCqlQSdM$ ) and [draft v1.10](https://urldefense.us/v3/__http://cfconventions.org/cf-conventions/cf-conventions.html*revhistory__;Iw!!G2kpM7uM-TzIFchu!n8Z5nIZTTWVzomqeuffRYnB6kwOLeb6JQ2nRaVjEwhi98fhRO2TX2457UHavJvolaIIuF--X_Gs$ ) there are no changes. Is there another place where one could get an overview of which closed issues are covered by the draft version? --- If not, I think that it would be a useful addition, maybe as a subsection -- "New additions in this draft version" or similar -- after the ordinary revision history. But this should be a separate enhancement request. 2. I was hoping that the [outstanding issue on temperature units](https://urldefense.us/v3/__https://github.com/cf-convention/discuss/issues/101__;!!G2kpM7uM-TzIFchu!n8Z5nIZTTWVzomqeuffRYnB6kwOLeb6JQ2nRaVjEwhi98fhRO2TX2457UHavJvolaIIuTd0wQz4$ ) would be resolved in the next version of the Conventions document. But I imagine there is still some work to be done before this happens, and if there are reasons to release 1.10 before so be it. There is always a new draft version to aim for :-) -- Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/345__;!!G2kpM7uM-TzIFchu!n8Z5nIZTTWVzomqeuffRYnB6kwOLeb6JQ2nRaVjEwhi98fhRO2TX2457UHavJvolaIIuMI-gyZs$ You are receiving this because you are subscribed to this thread. Message ID: This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
