Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

In addition to the guidelines specified . . . all DCAE committers are expected to look at these areas before merging a patch. If any item is not followed, you should reply with a -1 and add comments in appropriate places within the code.

Check the Commitment Message:

  • is the JIRA ticket issue related to this fix?
  • does either the issue or the commitment message properly describe what is being changed and why?

Check the License Blocks and Copyright Lines on all code and documentation files

  • is there a LICENSE.txt file?
  • All code modules should have comments at the beginning that look like:

# ================================================================================
# Copyright (c) 2017-2020 Company1. All rights reserved.
# Copyright (c) 2020 Company2. All rights reserved.
# Copyright (c) 2020 Company3. All rights reserved.
# ================================================================================
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# ============LICENSE_END=========================================================

  • All documentation files should have comments at the beginning that look like:

.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (c) 2017-2020 Company1. All rights reserved.

  • Does it mention the current year for the company doing the modification?
  • Note that there is no separator between Copyright lines by different companies.
  • Note that when a company updates code that was previously copyrighted by them, the date range should be extended as shown.
  • There is no alternate wording for the copyright lines, such as "modifications copyright"

Check for comments in all new code

We should improve the documentation in the code whenever possible. At a minimum, NEW code should be documented.

  • javadocs, pydocs format preferred on all public methods and classes

Check the code

  • Most importantly, does it actually fix what the commitment message says should be fixed?
  • Verify against ONAP code standards found . . .

Check whether the version number should be updated

  • if there is any new feature/enhancement
    • the patch version should be bumped
  • if change is bugfix on prev merged patch, AND if the prevous version is not already released
    • then version change is optional
  • different repos need to have the version number expressed in multiple places
    • document those . . .

Were there -1 on previous patches by another committer or the PTL?

  • This is a FULL STOP.
  • Please DO NOT merge the code until
    • that other committer has given at least a +1 or
    • the PTL says it is okay to +2 anyway (which would be very rare)
  • No labels