So, then the wording would be: If the contribution does not have a single author, please ask that the contribution be squashed by the author into one commit per author each following the same standard naming convention of: JIRA Description (e.g. METRON-123: Foo all the Bars).
Fair or did I get it wrong? On Fri, Jan 27, 2017 at 5:47 PM, David Lyle <dlyle65...@gmail.com> wrote: > The bolded didn't come through, but I'm guessing it's here: > > *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).* > > I'd recommend against multiple PRs. Creates all kinds of difficulties > reviewing and testing. The changeset should be reviewed and tested as a > single unit. If there is more than one author, simply don't squash. > > -D... > > > On Fri, Jan 27, 2017 at 5:44 PM, Casey Stella <ceste...@gmail.com> wrote: > > > 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 > > >
