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