metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject [DISCUSS] Contributions with multiple authors and requisite modifications to the development guide
Date Fri, 27 Jan 2017 22:44:04 GMT
It is important for every contribution to attribute the author, our git log
is a legal papertrail for attribution.  As a consequence of that, I
recommend the Development Guidelines section 1.2 be amended to the
following (bolded change):

Everyone is encouraged to review open pull requests. We only ask that you
try and think carefully, ask questions and are excellent to one another.
Code review is our opportunity to share knowledge, design ideas and make
friends.  The instructions on how to checkout a patch for review can be
found here <https://github.com/nickwallen/metron-commit-stuff>.

When reviewing a patch try to keep each of these concepts in mind:



   - Is the proposed change being made in the correct place? Is it a fix in
   a backend when it should be in the primitives?  In Kafka vs Storm?
   - What is the change being proposed?  Is it based on Community
   recognized issues?
   - Do we want this feature or is the bug they’re fixing really a bug?
   - Does the change do what the author claims?
   - Are there sufficient tests?
   - Has it been documented?
   - Will this change introduce new bugs?
   - *Does this contribution have a single author?*


*If the contribution does not have a single author, please ask that the
contribution be separated into multiple separate pull requests (one per
author with their contributions) that may have (non-cyclical) dependencies,
each following the same standard naming convention of JIRA: JIRA
Description (e.g. METRON-123: Foo all the Bars).*

Also, please review if the submitter correctly flagged impacts to the
following (if exist):

   - System Configuration Changes
      - Metron Configuration
      - Metron Component Configuration (sensors, etc)
      - Tech Stack Configuration (Storm, Hbase, etc)
   - Environmental Changes
      - Helper Shell Scripts
      - RPM Packaging
      - Ansible, Ambari, AWS, Docker
   - Documentation Impacts
      - Changes to Wiki Documentation
      - Revisions in Tutorials
      - Developer Guide
      - Expansions in readme's
   - Changes to System Interfaces
      - Stellar Shell
      - REST APIs
      - Etc...


Thoughts?  Better way to handle this scenario while still maintaining
unambiguous authorship?

Casey

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message