streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ebanks <ryaneba...@gmail.com>
Subject Re: Documentation & Testing
Date Thu, 28 Aug 2014 21:09:00 GMT
Stanton,

I am on board with all of those suggestions.  I know it may take some time
to implement all of them,
but I agree we should start the discussion and start moving that direction.


Hopefully the suggestions I proposed are just the first of many steps to
improving transparency
and quality in this project.

-Ryan Ebanks


On Thu, Aug 28, 2014 at 3:54 PM, Stanton Sievers <ssievers@apache.org>
wrote:

> Hey Ryan,
>
> I agree completely.  I think there a few things that can be done on top of
> what you've proposed that can help make the need more transparent.
>
> Using maven site, we should be able to publish JavaDoc so it is readily
> available for everyone to review and consume.
>
> Again, using maven site, we should be able to publish code coverage
> information to make it apparent where the gaps are and where folks should
> focus their efforts to fill the gap.
>
> I'm not sure if there's a dedicated process for publishing maven site to an
> Apache's project's site, but that would be a good place to start if it
> exists.
>
> Also, at one point CloudBees offered free pull request building for open
> source projects on BuildHive.  This would allow a one-off build to be
> executed and evaluated against the pull request.  If that build reported
> code coverage information, it would help a reviewer establish whether or
> not the level of unit testing is adequate.  Even publishing this
> information as part of our own builds on builds.a.o would be useful.
>
> As a community we should have the discussion about the next steps, but I'm
> hoping these options can get that conversation started.
>
> Thanks for bringing this up.
> -Stanton
>
>
> On Thu, Aug 28, 2014 at 4:18 PM, Ryan Ebanks <ryanebanks@gmail.com> wrote:
>
> > We need to do a better job of Documentation and Testing.  Way too many
> pull
> > requests are getting approved and merged in that contain no documentation
> > and minimal or no testing.  This needs to stop immediately.
> >
> > I know documentation and testing is time consuming and not fun, but we
> > cannot push this off and hope someone will fix it the future.  I am
> > proposing the following minimal guidelines/rules for all future pull
> > requests.
> >
> > *Documentation*
> >     1.) All pull requests contain adequate java docs
> >     2.) Java docs accurately reflect the code and are up to date
> >
> > *Testing*
> >     1.) Test must test more than 'does it throw an exception'. (Most of
> the
> > serializers unit tests do                     exactly this)
> >     For newly added classes
> >         1.) All classes have unit tests and integration tests (when
> > necessary) or it is explicitly stated in            the pull request why
> > that class can't/won't be tested.
> >     For modifications to existing classes
> >         1.) Any method that you touch must have unit tests.  If none
> > currently exist you are responsible         for creating them.
> >
> > If any of these extremely minimal requirements are not met, your pull
> > request will not be evaluated until it meets all of the requirements.
> > *Anyone
> > evaluating a pull request should verify these requirements before +1-ing
> > the request.  All apache committers should verify that these requirements
> > are met before merging requests too. *
> >
> > These basic steps will drastically improve our code base, and make it
> > easier for the project to gain new contributors.
> >
> > Sincerely,
> >
> > Ryan Ebanks
> >
>

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