1. Someone editing a given submodel commits an update to gerrit.
    1. Only the current model editor should be committing updates unless permission is granted by the current editor for someone else to temporarily be the editor to perform some update.
    2. A reasonable message is included in the commit, explaining what was updated.
      1. Given there is only a few characters allowed in the first line of commit, the second line of text should probably be used. 
    3. Generally, a separate commit should be performed for each submodel.   An exception to this would be if the multiple models relate as part of some effort (some cross-model contribution).
    4. IISOMI modeling guidelines must be followed, and reviews must assure that the guidelines are being adhered to before discussion occurs in some working team.
  2. The committer assigns reviewers
    1. At least two reviewers, but more is fine.   Available reviewers are Hui Deng , Xu Yang , Chuyi Guo Kevin Scaggs .
      Note:  Only one +1 is required, regardless of the number of reviewers assigned
    2. The committer must also supply a gendoc output of the submodel (or the relevant portion of the submodel), supplying it to the reviewers to facilitate easier approval.  
      1. Gendoc output to be placed in Model tools \ Papyrus \ Gendoc Files Related to Gerrit Commits
      2. Providing such output will allow for quick reviews, and not require the reviewers to attempt to download the committed files into a papyrus environment for review.
      3. It is assumed that the gendoc output reflects the model / model fragment being updated.
  3. Reviewers
    1. Reviews are done with a 'first come, first serve" approach with a couple of exceptions
      1. The +1 reviewer cannot be from the same company as the editor performing the commit.
      2. If the editor performing the commit is not the regular submodel editor, the regular editor should perform the +2, verify, and merge.
    2. The first available reviewer examines the request, including the gendoc output (2b above) as appropriate, and performs the +1.
    3. The second reviewer (whoever next notices the request) is responsible for performing the +2, verify, and merge.
    4. Keep in mind that commits are part of a "work in progress", not necessarily a finished work.
    5. Reviews should be completed quickly to facilitate further development (suggest 24 hours or less).
    6. For contributions of new material not yet socialized and/or not fully developed, a fairly 'relaxed' review with perhaps some suggestions is very reasonable. 
    7. If a model conflict occurs, the submodel editor decides how to resolve.

Note:  In the past, Deng Hui has carried the burden of merging all commits.   This proposal will relieve him of this burden. 

  • No labels

3 Comments

  1. Chuyi Guo

    Hello, Kevin, thank you for the summary!

    I am trying to supplement details for the reviewer choice with the following situation.

    I think the basic rule is to add the related reviewers.

    1. If the commit just for one domain, should add the editor of the domain to be the reviewer. If currently there has two relevant persons, for example, me and Jessie both have proposals for vnf, then when I have a commit I can add Kevin and Jessie. This also facilitates avoiding conflicts. If the commit is for his or her own domain, then can choose two other reviewers whom the submitter thinks is proper to add.
    2. If the commit covers more than one domain, must add all the relative reviewers. The first one who goes to check it can +1, and the second one +2 and merge. If the 3rd coming one finds problems while the commit has already merged, we can talk about together in the call or by emails, and repair it in the next commit. But for -1 or major problems found before merge, this can not hurry to merge and should be taken seriously.

    For 1e, should this be done manually, or there has some magics for the papyrus operation?

    1. Kevin Scaggs

      Hi Chuyi - I made major revisions per a working session with Jessie.   The proposed process is much simpler.   Let me know what you think!

  2. Chuyi Guo

    Hello Kevin,  great revisions! Thank you.