[JMC] I personally think “release notes” make for a nice digest.  And, I agree 
that this may be a preference.  That could be an optional part of the CI that 
authors could choose to enable.

[QW] Are you talking about using weekly github digest to keep track of status 
update of Experimental work in a weekly basis.
Suppose you already create WG github to develop or maintain YANG module, what 
you need to do is to add your WG github to ietf-github-services/activity-summary
https://github.com/ietf-github-services/activity-summary/blob/main/mls.json
What else do we need if IETF weekly github digest is not sufficient?

[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.
[14.png]<https://github.com/mjethanandani/veloce/issues/14>
How much guidance should be mandated by this draft? · Issue #14 · 
mjethanandani/veloce<https://github.com/mjethanandani/veloce/issues/14>
github.com<https://github.com/mjethanandani/veloce/issues/14>



The idea of “two years” for a module is rather arbitrary.  As I said before, a 
simple module might otherwise get published in a year.  A more complicated or 
contentious module may take longer.  One thing that might help this experiment 
is to somehow declare that one of its goals is to not make perfect the enemy of 
good.  That is, with YANG Semver/Module Versioning plus a more open source-like 
flow to module development, modules that seem “good enough” can be 
released/RFC’d earlier knowing that revisions can happen quickly.

All this is fine and dandy. The question is how do we enforce this? The only 
reason to put a timeline is that is a measureable quantity. How else do we 
decide the model is “good enough”?

[JMC] You’re right: tough to answer.  One thought I have (based on syslog at 
least) is air cover to have authors say, “no, we’re not going to do this right 
now” when certain requests for features are raised in broader reviews (think 
DISCUSSes).  For example, empower them to say, we’ll fix anything clearly 
broken but if you’re asking to support X, Y, and Z, that can wait.

[QW] One different point I want to make here  is I am not sure we can 
accelerate the progress of a new YANG module experimental work using VELOCE 
process and SCM, comparing with Developing a new YANG module work without 
VELOCE process, the only difference is to move YANG module in a separate IETF 
hosted repository and integrate YANG tools into the repo.

[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.

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.

Joe
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to