[JMC] Not sure. I’ll try to be more specific to see if we’re talking about the same thing. When I publish a GitHub new release of a draft using Martin Thompson’s Kramdown template I can fill in release notes, and then this kicks off a CI/CD process to publish the draft in DataTracker. I was suggesting the same process could also email the list with a summary of the changes (i.e., the release notes) IFF the authors want this. If they do, they’d enable this step in the CI workflow. [QW]: Yes, send an email to the list to summarize the changes to specific YANG data model draft, this is exact tool you are looking for. One such example you can reference is: https://mailarchive.ietf.org/arch/msg/quic/n-WVLSJBuHx6RoSaBoPrU33ae8s/ Today, we see more and more WGs within IETF to follow open source approach and use this weekly github summary tool to keep track of the status of the draft and open issues of the draft, not just limited to YANG data model draft.
[JMC] Yeah, this works. Though, I was thinking of a more curated “release note” style. [JMC] I think we can accelerate both, Qin. Please forgive me for what I’m about to say, but if we think of this in a more “agile” way, we can do a minimally viable YANG module for a feature and push back on requests to add the kitchen sink. Get that out the door quickly, and then iterate on version 1.1, 2.0, etc. But, authors need to have the responsible AD provide air cover in the IESG and other review processes to avoid scope creep. [QW]: it seems you are talking about YANG 1.1 and YANG 2.0. Sound to have lots of promising with excitement, If that is the case, I think some guidance for AD responsibility and WG Chairs, YANG Doctor’s responsibility should be clearly documented, e.g., what should be done? What should be in the scope? How to prioritize the work. Do you any specific suggestions to this VELOCE document? [JMC] Bad choice of numbers, maybe. No, I was thinking of YANG Semver and module versions. I should have said 1.1.0, 2.0.0, etc. Let me think on some specific text. It will mostly be some form of what I wrote here. I wish there was a way to consolidate these different containers capabilities into a single repository. [JMC] Don’t see why we can’t have a common repo with a Dockerfile we can contribute to. This could be published to an IETF Docker Hub org. [QW] The tools to build tree diagram and validate YANG file and other artifacts are useful and should be integrated into I-D with yang template. However we feel these toolchains we discussed are more designed for xml source file in the local/offline development environment, not suitable For markdown source file or the online Collaborative Environment, In IETF, I see markdown toolchains (https://authors.ietf.org/en/drafting-in-markdown) become more and more popular and have been widely used for I-D development. https://github.com/martinthomson/internet-draft-template https://github.com/IETF-OPS-AD/I-D-with-yang-template/tree/main/yang For online collaboration environment, I am in favor of using markdown template. I see I-D-with-yang-template also support YANG validation and YANG tree diagram generation. [JMC] YANG is popular, and this leads to more inexperienced authors (which is good). Having a comprehensive set of tools that Just Work™ and provide wrapped examples (which are validated) along with tree diagrams, and linted and well-formatted modules will be super helpful to all. [QW]: I think online validation tools set low bars for inexperienced authors, encourage the team to work collaboratively in the real time collaborative working environment also can help facilitate The progress of the work, therefore what I suggest for this VELOCE document, we should make online validation in collaborative working environment mandatory, in the meanwhile, we can support Local validation in case online validation tools doesn’t work or you don’t have connection to the WG github. Here is my proposed change to VELOCE document: https://github.com/mjethanandani/veloce/pull/27 [JMC] A low bar, maybe. But I still see poorly structured, invalid YANG today. At the very least, the YANG that gets checked in should be valid and well-structured. If we can push more automated tests based on 9907, even better! Joe Joe
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
