streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanton Sievers <>
Subject Re: Documentation & Testing
Date Thu, 28 Aug 2014 20:54:44 GMT
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

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.

On Thu, Aug 28, 2014 at 4:18 PM, Ryan Ebanks <> 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

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