Hello Martin, Some answers below.
Regards Olivier Le 20/05/2016 02:35, Martin Winter a écrit : > > > On 19 May 2016, at 8:51, Olivier Dugeon wrote: > >> Hello Donald, all >> >> I globally agree on the proposal, but have some questions. See Below. >> >> BTW, I will attend next quagga meeting >> >> Regards, >> >> Olivier >> >> Le 19/05/2016 13:47, Donald Sharp a écrit : >>> >>> Adjusted proposal based upon feedback. >>> >>> --------------------- >>> >>> Golden Rule applies to everything we do. >>> >>> A person who Submit’s code cannot be the person who commits it into quagga. >>> Assume that this can be worked out amongst the maintainers. >>> >>> Anyone can ACK/NACK code by sending mail to the submitter and the >>> quagga-dev alias substantiating the basis for dissent. >>> >>> Proposal for going forward: >>> >>> 1. Patch Submitted >>> 1. Automatic testing is being applied to incoming patches on >>> quagga-dev. If testing indicates a failure then the patch must be fixed >>> and resubmitted. >>> >> Does this automatic testing include protocol conformity or just applying >> patch and try to compile ? In case it includes conformity, what's happen >> with future / innovative .. features ? I means implementing extensions that >> are not yet RFC e.g. Segment Routing. How to be sure that the testing will >> not report false failures just because the code is freshen regarding the >> testing tool. > > In my earlier response (which I believe was the base for this), I’ve added an > exception rule for cases when it’s believed that the test itself is > broken/bad or something changes on purpose. But it would have to be a clearly > stated intent. I think for the case of simplicity, Donald left this out and > just assumed a common sense by maintainer to overrule this rule if needed. > > However, specially for new features which may not even be covered by existing > tests, I would expect submitter to give some description on > his own testing - or find someone else who is able to test it before it goes > in. But again, I think common sense and doesn’t need to be > spelled out. Agree. For example, adds some text about interoperability test with commercial router (even virtual firmware like IOX-XRv or Junos vMX) will be of great help. > >>> 1. If Acked goes in immediately to a development branch, by current >>> maintainer. >>> >> Is the submitter got write access on this development branch to rebase / >> update /modify / ... its code easily before it will be merge into the master >> ? > > Can you explain a bit more? > My understanding is that it should be done/ready reviewed and agreed when it > gets accepted into the development branch. Update/Modify later would be a new > patch started at step 1. Well, taken my TE patches as example, Paul create a dedicated lls-te branch on which it apply my patches. Then, exchange with Paul started to modify my original patches. Unfortunately, I can't modify directly the code on the lls-te branch as I have no write access on it. So, I publish a patch of patch of patch ... that was for come of them not applied on the lls-te branch. Then 1.0-xx was release and I spent many effort to completely rebase my original path plus the subsequent modification on this new release. Having a write access should help me to update my patch according to Paul suggestion's as well as save my time when I rebase them. So, even if the patch was reviewed and agreed before going into a development branch, it could take time (several months in my case) before it will be merge into the master. So, update and modification could occur during this period. Working directly into the development branch will save time and reduce effort. > >>> 1. If no-one says anything after 2 weeks, code get’s put into a >>> development branch by one of the current maintainers. >>> 2. If Nacked, dissenter and submitter must publicly work the issue out on >>> the quagga-dev alias, and going back to step 1 after working issue out. >>> 3. If after 2 weeks, from Submittal, dissenter and submitter cannot figure >>> the problem out either Dissenter or Submitter can ask for agenda item to be >>> added to next monthly meeting. If disagreement is large enough a special >>> meeting can be asked for as well. >>> >> Same question as Lou. When, who and how we decide that the development >> branch is merge into the master ? > > I’ve asked for this as well. Donald decided to leave this open to give > maintainers a flexible way. > Personally, I don’t see a clear timeline required in the rules, but a quick > rule if a single maintainer > (the one working on this branch) can make this decision on it’s own or if it > would require more > maintainer/community involvement to make this decision. Here, the risk, like mention previously, is that a patch remains in a development branch for a too long period without a resync of the development branch (it is what's happen with the lls-te branch for me) with the master. Then the difference becomes too huge (again it is my case) and impose a complete re-write of the original patch. So, I would propose 2 improvement to the Donald proposal: a) regular re-sync of the development branch with the master to avoid out of sync b) merge of development branch in a bounded time frame (I let maintainers decide the best value for this period) > >> When code review take place ? > > On the list before it get’s ACKed. An ACK means that you think it’s ready to > go in. Well, for me, this is linked. Looking to what gerrit propose, you review the code, add a '+1 or -1' and the code becomes automatically ACK/NACK depending on its counter and threshold. Even if we not go to gerrit, a similar manual process could be used. Anyone on the quagga-dev list could review the code and send a +1/-1 to the code. Maintainer manage the counter and ACK/NACK is automatically decided when patch reach +3/-3 for example. > >>> Format for Resolution during Meeting: >>> >>> 1. Simple Majority of those attending meeting is required for decision. >>> Decision results can be: Inclusion of the Nak’ed patch, further discussion( >>> step #4 above ), or exclusion of the patch. >>> >> No alternative ? Reworking on the patch for example ? > > I would expect this is done with a NACK and explaining what needs to be > done/changed. Submitter would then resubmit a updated version > (until no more NACKs). The issue is here for NACK’s when there are > fundamental issues, i.e. should this feature go into Quagga, > should we change the functionality or the Submitter disagrees in some other > way with the NACK reason and won’t or can’t change it, > but wants the code in anyway. OK. Better understand now. This also concern patch that not reach threshold (positive or negative) if we adopt '+1/-1' system counter. > >>> 1. Scheduling of a special meeting details must be worked out publicly on >>> quagga-dev alias. >>> 2. A Patch cannot be a meeting topic more than 2 times in a 12 month >>> period. >>> >> Yes and No. Yes as normally the decision solved the problem. And no if the >> decision was to work on the patch before re-submitting it which generate >> more than 2 "Submit/Nack/Discussion/Correction/ReSubmit" cycles are needed >> to achieve an Ack'ed patch ? > > I think you misunderstood the process. Normal NACK is just someone finding a > issue with code and the submitter will just update > and resubmit - and all the ACK/NACK cycle starts again. At least thats the > way I understand it. No need for a Meeting in this case. OK. It is clear now. > > - Martin > >>> On Tue, May 17, 2016 at 11:45 AM, Donald Sharp <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Golden Rule applies to everything we do. >>> >>> A person who Submit’s code cannot be the person who commits it into >>> quagga. Assume that this can be worked out amongst the maintainers. >>> >>> A maintainer can Ack or Nack code he plans to commit. >>> >>> Proposal for going forward: >>> >>> 1. Patch Submitted >>> 2. If Acked goes in immediately to a development branch, by current >>> maintainer. >>> 3. If no-one says anything after 2 weeks, immediately get’s put into a >>> development branch by current maintainer. >>> 4. If Nacked, dissenter and submitter must publicly work the issue >>> out, and going back to step 1 after working issue out. >>> 5. If after 2 weeks, from Submittal, dissenter and submitter cannot >>> figure the problem out either Dissenter or Submitter can ask for agenda >>> item to be added to next monthly meeting. If disagreement is large enough >>> a special meeting can be asked for as well. >>> >>> Format for Resolution during Meeting: >>> >>> 1. Discussion on alias( See #4 ) must be sufficient for Meeting to >>> resolve the issue. Meeting attendees are within their rights to say we >>> can’t make a decision from fact’s presented at the meeting. >>> 2. Simple Majority of those attending meeting is required for >>> decision. If you can’t be bothered to attend then the decision wasn’t >>> important to you. >>> 3. Scheduling of a special meeting details must be worked out publicly >>> on quagga-dev alias. >>> >>> >>> Please discuss this on alias, and we'll finalize in a meeting for 11 am >>> EDT next tuesday. If you are interested in attending please let me know. >>> I'm auto inviting everyone currently on the quagga-dev monthly meeting. >>> >>> donald >>> >>> >>> >>> >>> _______________________________________________ >>> Quagga-dev mailing list >>> [email protected] >>> https://lists.quagga.net/mailman/listinfo/quagga-dev >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
