metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Miklavcic <michael.miklav...@gmail.com>
Subject Re: [DISCUSS] Full-dev role in PR testign
Date Thu, 02 May 2019 00:37:51 GMT
> Our general procedures. Should we not be requiring full-dev on all PRs,
but maybe just asking for a justification why not (e.g. "I don't need
full-dev for this, because I added unit tests here and here and integration
tests for the these components?"). And then a reviewer can request a
full-dev spin up if needed?  Could we stage this rollout (e.g.
metron-platform modules require it, but others don't, etc.?) This'll add
more pressure onto the release phase, so maybe that involves fleshing out a
checklist of critical path items to check.

My impression is that this is already the status quo. But, if we think we
need to be more clear on this, let's put up a vote to change the coding
guidelines and PR checklist. I've done this many times in the past, the
most obvious instances are when I've made doc changes or unit test
modifications because those will not impact full dev. I will own this item.
I think it can probably get rolled in with my dev guideline changes for
architecture diagrams.

> Do we need to improve our docs? Publish Javadocs? After all, if docs are
better, hopefully we'd see less issues introduced and be more confident in
changes coming in.

1. I think we should create Jiras with the end deliverable being that our
private vs public API endpoints are clearly delineated. From there, we
create another round of javadoc - for the public APIs let the javadocs rain
from the heavens to your heart's content. It's for public consumption and
should assist end users. See Mockito, for example -
https://static.javadoc.io/org.mockito/mockito-core/2.27.0/org/mockito/Mockito.html.
For developer docs, I'm of the *extremely strong* opinion that this should
be limited. Emphasize module, package, class, and method naming conventions
over all else. If it doesn't make sense just reading the code, take a
minute to summarize what you're doing and consider refactoring. For
legitimately more complex and necessary code passages, add a note. For
multi-class interactions that provide a larger story arc, add dev docs to
the relevant READMEs. Our use of Zookeeper Curator and its interaction with
our topology config loading is a perfect example of a feature that would
fit this need.
2. I'm an immediate -1 on any documentation that looks like " /** Open the
car door **/ public void openCarDoor() {...}" :-). The code speaks for
itself.
3. Publish javadocs for public APIs, not our internal dev APIs. Let your
fav IDE fill in the gaps for devs.

>  What environment do we even want testing to occur in?
https://github.com/apache/metron/pull/1261 has seen a lot of work, and
getting it across the finish line may help make the dev environment less
onerous, even if still needed.

Full dev until we vote to replace the existing setup and can be confident
that the new approach 1. is stable, 2. takes <= the amount of time to
complete as full dev. I am +1 for migrating towards this approach and think
we should do so when it's dialed in.


On Wed, May 1, 2019 at 8:59 AM Justin Leet <justinjleet@gmail.com> wrote:

> Hi all,
>
> I wanted to start a discussion on something near and dear to all of our
> hearts: The role of full-dev in our testing cycle.
>
> Right now, we require all PRs to have spun up the full-dev environment and
> make sure that things flow through properly. In some cases, this is a
> necessity, and in other cases, it's a fairly large burden on current and
> potential contributors.
>
> So what do we need to do to reduce our dependence on full dev and increase
> our confidence in our CI process?
>
> My initial thoughts on this encompass a few things
> * Increasing our ability to easily write automated tests. In particular, I
> think our integration testing is fairly hard and has some structural issues
> (e.g. our tests spin up components per Test class, not for the overall test
> suite being run, which also increases build times, etc.). How do we make
> this easier and have less boilerplate?  I have one potential idea I'll
> reply to this thread with.
> * Unit tests in general. I'd argue that any area we thing need full-dev
> spun up to be confident in needs more testing. Does anyone have any
> opinions on which areas we have the least confidence in?  Which areas of
> code are people afraid to touch?
> * Our general procedures. Should we not be requiring full-dev on all PRs,
> but maybe just asking for a justification why not (e.g. "I don't need
> full-dev for this, because I added unit tests here and here and integration
> tests for the these components?"). And then a reviewer can request a
> full-dev spin up if needed?  Could we stage this rollout (e.g.
> metron-platform modules require it, but others don't, etc.?) This'll add
> more pressure onto the release phase, so maybe that involves fleshing out a
> checklist of critical path items to check.
> * Do we need to improve our docs? Publish Javadocs? After all, if docs are
> better, hopefully we'd see less issues introduced and be more confident in
> changes coming in.
> * What environment do we even want testing to occur in?
> https://github.com/apache/metron/pull/1261 has seen a lot of work, and
> getting it across the finish line may help make the dev environment less
> onerous, even if still needed.
>

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