metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject Re: [DISCUSS] Contributions with multiple authors and requisite modifications to the development guide
Date Fri, 27 Jan 2017 22:50:40 GMT
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 <dlyle65535@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 <cestella@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
> >
>

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