Hi, Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > Let me add that there was large disagreement what a bug fix is in the > design team. Hence, any text that talks about 'bug fixes' is ambiguous > and of limited value to achieve consensus. (Or we may find consensus > but then not agree on what we have found consensus on.) > > To be more concrete, I learned that Rob's notion of a bug fix is very > different from my notion of a bug fix. I think it is important for > having a productive discussion to be aware of this. > > For me, a bug fix is rather limited, i.e., fixing something where the > correct intention was clear but the model did not properly capture the > intention correctly, i.e., roughly what we can do with errata in the > IETF. I think Rob understands bug fixes in a much broader sense, > including fixes to what essentially are in my view module design > errors. > > With my narrow definition of bug fixes, bug fixes are essentially > backwards compatible (even if they may violate RFC 7950 rules - but as > long as the original intention was clear, we can be flexible).
I agree with this interpretation of a bug fix. For example fixing incorrect patterns (e.g. errata 3957 that Andy mentioned). /martin > With Rob's notion of bug fixes, we have to handle them as part of the > versioning system since they may be non-backwards compatible. > > /js > > On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote: > > Hi Chris, > > > > > > On 25/10/2018 18:42, Christian Hopps wrote: > > > > > > Hi Rob, > > > > > > We've more privately discussed the bug-fix scenario and I'm sympathetic > > > to it; however, the requirement as written does not restrict itself to > > > fixing module definition bugs (e.g., a pattern or other value > > > constraint) in some small but incompatible way -- instead it's wide open > > > and it will be [ab]used that way. > > I think that everyone on design team agrees that non-backwards-compatible > > changes should be minimized and should really only to used for bug fixes > > where it is anticipated that clients should not be affected. > > > > We want to allow non-backwards-compatible changes at the head of the > > development tree, but again, I think that everyone agrees that keeping it > > backwards compatible where possible is a good goal. > > > > However, I think that there will be cases where a vendor decides that it is > > right for an enhancement or non backwards compatible change to be made to an > > already released module. I agree that this is highly undesirable and an > > abuse of the rules, but I don't believe that whatever versioning scheme we > > come up with will prevent vendors from doing this. So then the question > > becomes: Is it better to pretend that this scenario will never happen, > > design the versioning scheme so that it cannot be expressed, which probably > > just means that clients will not be able to detect when vendors do this by > > cheating the rules! Or is it better to accept that this will sometimes > > occur, provide strong guidance as to why this is bad practice and should be > > avoided, but have a versioning scheme that still allows this to be expressed > > (in a bounded way)? I.e. even if the vendors are doing something that is > > less than ideal, at least the clients can spot where they have done this. > > > > --- > > > > A separate concern that we had about ties this strictly to bug fixes is that > > some one will ask for a definition of a bug fix. The design team tried this > > but we couldn't even agree what a bug fix is, let alone agree with a single > > definition of a bug fix as it related to a YANG module. So our conclusion > > was that perhaps it is better not to tie the requirements themselves to bug > > fix vs enhancement, because the boundary between the two is too vague, and > > module writers will bend the rules. > > > > So I see that the rules should be: > > - backwards compatible bug fix - this is fine. > > - non backwards compatible bug fix - this is fine if it is pragmatically > > expected to not impact any clients, but careful consideration is required if > > it might break clients. > > - backwards compatible enhancement - not ideal, but pragmatically OK. > > - non backwards compatible enhancement - this is bad and should be avoided. > > > > But if we don't want to define the difference between a bug fix vs > > enhancement then I think that you end up with the most general requirement > > being that we do want to allow for non-backwards-compatible changes in > > released modules to accommodate the bug fix scenario, but the expectation > > (and guidance) will be that they should only be used for bug fixes. > > > > > > > > > > For example: > > > > > > > Here is what I am afraid the vendors want here: A developer on > > > > release train X can easily change some data structure and then push > > > > the change into an automated system which generates a new YANG > > > > module definition and revs a version number -- all done! They don't > > > > have to deal with the inertia of making this change in their release > > > > train Y or Z and they don't have to treat modules as a stable API > > > > they are exporting, b/c they now have these new wonderful versions > > > > from this work. Meanwhile we the users now have to deal with N forks > > > > with all the various little incompatible changes random developers > > > > at the company wanted to make without having to coordinate with > > > > their coworkers/other internal teams. Now multiply this by M > > > > vendors. It's a nightmare. It shouldn't be what we are optimizing > > > > for, let alone making a requirement. > > > > > > Regarding enhancements, these are features, and are naturally > > > augmentative. I find it hard to believe we have a pressing > > > need/requirement to support non-backward compatible changes to existing > > > modules in order to support enhancements. > > I agree. It was a backwards compatible enhancement that I was considering. > > > > Thanks, > > Rob > > > > > > > > > > Thanks, > > > Chris. > > > > > > > > > Robert Wilton <rwil...@cisco.com> writes: > > > > > > > Hi Chris, > > > > > > > > I think that there are two things driving this requirement: > > > > > > > > What I regard as the key one, is that we want to be able to support > > > > the software > > > > that we have shipped. In particular, we may need to fix bugs > > > > (perhaps at the > > > > operators request) to a YANG model that has already been released. > > > > I.e. I think > > > > that there are some scenarios, where forking a YANG module, although > > > > undesirable > > > > is the right thing to do to include a fix. I don't believe that > > > > features or > > > > deviations help solve this problem. > > > > The two alternative solutions to being able to fix bugs, neither of > > > > which I > > > > think is pragmatic, that I can think of are: > > > > (i) Vendors ensure that their YANG modules are perfect before they > > > > ship in a > > > > release. > > > > (ii) If a bug is reported, operators are happy to wait until the bug > > > > has been > > > > fixed in the current development release, and will migrate to that > > > > latest > > > > release to pick up the fix. > > > > > > > > The second thing driving this requirement is that vendors sometimes > > > > get asked > > > > for enhancements to existing releases, perhaps because the latest > > > > development > > > > release is too far out, or ask for an enhancement on the current > > > > train to be > > > > back ported to an older release. > > > > > > > > So, aiming to have stable YANG modules, trying a lot harder to avoid > > > > non-backwards-compatible changes, and keeping new functionality to > > > > the head of > > > > the development I completely agree with you on. But I still believe > > > > that there > > > > are some valid scenarios, that should be limited as much as > > > > possible, where it > > > > is necessary to make changes that sometimes break these rules, and > > > > having a > > > > limited scheme that clearly indicates where such breakages have > > > > occurred is > > > > probably better that the status quo of where the modules get > > > > changed, but the > > > > operator doesn't get any useful indication of what type of changes > > > > are being > > > > made. > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 25/10/2018 16:26, Christian Hopps wrote: > > > > > > > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <jcla...@cisco.com> wrote: > > > > > > > > > > > > * New requirement 1.4 for supporting over-arching software releases > > > > > [ I read this as supporting various different module versions > > > > > based on a vendor's different software release trains. If this > > > > > is wrong then the rest of this doesn't apply and I would just > > > > > ask for the text to be update to clarify what it means. ] > > > > > > > > > > How many operators/users have asked for this or indicated it's a > > > > > requirement for them? > > > > > > > > > > What problem is intractable without this requirement being met, > > > > > and what is the cost of this requirement on the actual users? > > > > > > > > > > I have pushed back multiple times on this b/c I believe this > > > > > "requirement" is really being pushed to make it easier for > > > > > vendors (a small affected group) to develop their software at > > > > > the cost of their users (the much larger affected group) who > > > > > would then have to deal with multiple trains of the same module. > > > > > > > > > > > > > > > We already have features and deviations why are they not enough > > > > > to deal with functionality that is present or not in various > > > > > software release/devices? > > > > > > > > > > FWIW I'm not against making it easier to develop software, but > > > > > we have to be mindful if we are just pushing the cost (and > > > > > magnifying it greatly) to other people in the community. > > > > > > > > > > Thanks, > > > > > Chris. > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > . > > > > > > > > > > > . > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
