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. > > 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 ? > > 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 ? When code review take place ? > > 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 ? > > 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 ? > > > 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
