[DISCUSS] Dev Guide and Committer Review Guide additions?

[Otto Fowler <ot...@gmail.com>]

As Metron evolves to include new deployment options, features, and
configurations it is hard and only getting harder for contributors,
committers, and reviewers to understand what the required changes are
across the different areas of the system to correctly and completely
introduce a change or new feature in the system.

We have talked some about the requirements or expectations for submitters
with regards to tests and coverage, coding style, and documentation  but I
don’t think we have enough guidance on deployment or other changes that
need to be considered.  For committers it is pretty much the same, with the
extra stuff around that process.

Right now it seems as a committer I’m counting on others like Nick or Casey
to understand anything that may be missing from a submission when I review
it.  Should there by an Ambari/RPM change?   Does this change the RestAPI?
Does this effect STELLAR Lang/SHELL?  Does it need customer Docker Compose
work?  etc etc.

I think as we grow the community and try to get out of incubation it will
be impractical for us to count on this, and we are even now increasing the
risk of regression or functional gaps ( unrealized ) that will have an
adverse effect on having a stable master.

I think we should discuss if and how we can improve this or the issue of my
sanity ;).

What are the criteria that we need to have submitters and reviewers have in
mind?
* Test
* Doc
** Obsoleting of existing documentation/how-to’s ( even hortonworks posts )
* Performance
** How do we test for performance?
*** Standards
*** Tools and processes
* Deployment
** RPM
  ** Docker
** Ansible
** Ambari
** AWS Script
* Functional
** STELLAR/Shell
** REST api’s
* Dev/review guide
** Does the review / submit guide need to account for it?

Any thoughts?

Re: [DISCUSS] Dev Guide and Committer Review Guide additions?

[Michael Miklavcic <mi...@gmail.com>]

Hi Otto,

You make a great point.

AFA RPM/MPack, we do have some work in the pipeline for streamlining things
a bit with the RPM's and MPack code such that they will be used for
performing the Metron install in the sandbox VM's rather than Ansible. (I'd
search for the public Jiras and post them here, but Jira is down for
maintenance currently.) This should help make it obvious that a change or
new feature requires modifications because they will be in the critical
path to testing.

Documentation is still tricky because we have README files, javadoc, and
the wiki. But in general I think the current approach is to put concrete
functionality docs in the READMEs as much as possible because they can be
tracked and versioned with Git. I think the community has actually been
doing a pretty good job here. The wiki is a little more tricky because
there is typically only one version, which tracks master, not necessarily
the latest stable release.

Mike


On Thu, Jan 12, 2017 at 8:42 AM, Otto Fowler <ot...@gmail.com>
wrote:

> As Metron evolves to include new deployment options, features, and
> configurations it is hard and only getting harder for contributors,
> committers, and reviewers to understand what the required changes are
> across the different areas of the system to correctly and completely
> introduce a change or new feature in the system.
>
> We have talked some about the requirements or expectations for submitters
> with regards to tests and coverage, coding style, and documentation  but I
> don’t think we have enough guidance on deployment or other changes that
> need to be considered.  For committers it is pretty much the same, with the
> extra stuff around that process.
>
> Right now it seems as a committer I’m counting on others like Nick or Casey
> to understand anything that may be missing from a submission when I review
> it.  Should there by an Ambari/RPM change?   Does this change the RestAPI?
> Does this effect STELLAR Lang/SHELL?  Does it need customer Docker Compose
> work?  etc etc.
>
> I think as we grow the community and try to get out of incubation it will
> be impractical for us to count on this, and we are even now increasing the
> risk of regression or functional gaps ( unrealized ) that will have an
> adverse effect on having a stable master.
>
> I think we should discuss if and how we can improve this or the issue of my
> sanity ;).
>
> What are the criteria that we need to have submitters and reviewers have in
> mind?
> * Test
> * Doc
> ** Obsoleting of existing documentation/how-to’s ( even hortonworks posts )
> * Performance
> ** How do we test for performance?
> *** Standards
> *** Tools and processes
> * Deployment
> ** RPM
>   ** Docker
> ** Ansible
> ** Ambari
> ** AWS Script
> * Functional
> ** STELLAR/Shell
> ** REST api’s
> * Dev/review guide
> ** Does the review / submit guide need to account for it?
>
> Any thoughts?
>