I posted the ieee802-ethernet-pon YANG module at this GIT location: https://github.com/mxhaj79/EthernetYang/commit/de02fd8552d75c52c6b58ac4906023895274804c
Since this is the first version of the module, there is very little value for diff from the main branch.
From: Mahesh Jethanandani [mailto:mjethanandani@xxxxxxxxx]
Sent: Thursday, March 16, 2017 12:54 AM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Subject: Re: [802.3_YANG] EPON YANG module (ieee802-ethernet-pon.yang)
In this case, the current published ieee802-ethernet modules should be pushed into the appropriate location. Right now, they are under “experimental/ieee/802.3” and should be under “standard/ieee/802.3” branch down the road. Is that a correct understanding?
That is correct.
I would post then my new model (it is not approved yet) under “standard/ieee/draft” and once it is approved for inclusion, it would be moved to “standard/ieee/802.3” branch. I assume these operations are done by the person in control of the repository
I will create the fork and follow the process you outlined. However, organizationally we (802.3) typically have a more formalized commenting process, and I was wondering how comments from that process and comments on GIT can be merged together into a single commenting & resolution process. Since it has not been attempted before, I was just curious … We can officially resolve comments only at Task Force meetings
Fair enough. If there is a process that works for code, use that. Since git is being used to provide updates, I wanted folks to know that there is a way to get comments, resolve them within git also.
If I look at GitHub this is what it says for IEEE YANG models.
IEEE experimental drafts
(1) The "experimental/ieee" branch is intended for IEEE work that does not yet have a Project Authorization Request (PAR).
(2) The "standard/ieee" branch is intended for approved PARs, for drafts as well as published standards.
If I was to follow this logic, you would use standard/ieee/draft to post your model. You had a model in experimental/ieee directory to begin with.
If you create a repository which is a *fork* of this repository, make the changes, push the model to *your* fork of the repository, and generate a “Pull request”, git generates the diffs for the changes you have made and displays it. For an example, see this link:
Reviewers can at that time select any line and provide comment on the code itself. You in response can update the model, provide updated diffs to address those comments. When everyone is satisfied, the pull request can be accepted, and the model merged into GitHub.
Is this what you were looking for?
I am in the process of developing the YANG module for EPON, as attached. Before this code is posted on GIT, I wanted to share the module for review purposes. This module imports latest ieee802-ethernet-interface.yang and ieee802-ethernet-interface-legacy.yang modules from GIT (saved on 2017/03/15).
Note that the syntax is YANG 1.0 compatible. I did not notice any changes in ieee802-ethernet-interface.yang and ieee802-ethernet-interface-legacy.yang as far as 1.0 and 1.1 syntax is concerned (apart from explicit yang-version 1.1 statement). I am not sure whether the modules should be developed going forward for backward compatibility (1.0 compatible) or not (1.1 onwards). Something to bear in mind going forward …
I would also like to understand *how* we comment on existing modules – given that this is code, it would make most sense to share new proposed updated module and delta from last stable version, or generate delta using some text editors otherwise? I am looking for a suggestion of a commenting process that would work best for people looking at it in detail …