I don't know about apache policy, but I think anything that can't be easily
modified is probably a bad thing to have in the source code. If there is a
binary jar, but there's no way to update the jar to modify the test that
seems like a problem.

Since we have a framework to run tests with old versions and new versions
of geode, I don't see why there should be any reason to check in artifacts
generated by old versions of geode either.

Can you describe the specific tests? I saw Anthony's downvote on the
release, but it's not clear what tests use those artifacts or what they are
for.

-Dan

On Mon, Feb 6, 2017 at 9:28 AM, Kirk Lund <kl...@apache.org> wrote:

> [bump]
>
> I want to see a definitive reference on what's allowed to be in the src of
> an Apache project before we take actions to change any tests that use
> binary resources.
>
> We have unit tests and regression tests that are using binaries (including
> stat files, diskstore files, class files). Jumping through hoops to execute
> a test that requires an old binary that was generated by old geode src
> prior to a bug fix (stats, diskstores, etc) or that needs to compile
> against old geode src (backwards compatibility of user callbacks) seems
> like a huge waste of time and energy.
>
> Please provide more info on list if anyone has issues with what's in geode
> src code.
>
> Thanks,
> Kirk
>
>
> On Wed, Nov 2, 2016 at 1:46 PM, Kirk Lund <kl...@apache.org> wrote:
>
> > I do have a particular case in mind involving stats files that geode
> > creates and reads. The StatArchiveWriter.java class writes out statistic
> > archive files for geode, while StatArchiveReader.java reads them in.
> >
> > There have been a few bugs causing the stats files to be corrupted in
> some
> > way. My goal has been to fix the StatArchiveWriter to prevent any
> > corruption, but also fix the StatArchiveReader to self-correct where
> > possible or provide better error handling if self-correction is not
> > possible.
> >
> > The result is that we have a couple regression tests under
> > geode-core/src/test/java with corresponding corrupted statistic archive
> > files under geode-core/src/test/resources.
> >
> > Example: I currently have a review posted for GEODE-2013 https://reviews
> .
> > apache.org/r/53402 with these files:
> >
> > geode-core/src/main/java/org/apache/geode/internal/
> > statistics/StatArchiveReader.java
> > geode-core/src/test/java/org/apache/geode/internal/statistics/
> > StatArchiveWithMissingResourceTypeRegressionTest.java
> > geode-core/src/test/resources/org/apache/geode/internal/statistics/
> > StatArchiveWithMissingResourceTypeRegressionTest.gfs
> >
> > The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
> > small (253 bytes on Mac). After fixing the source of the problem in
> > StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better
> error
> > messaging to the user if they try to read an older stats file that was
> > written before GEODE-2012 was fixed.
> >
> > Thanks,
> > Kirk
> >
> > On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> >> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund <kl...@apache.org> wrote:
> >> > I'd like to read up on what's allowed and disallowed regarding file
> >> types
> >> > in Apache source code. Does anyone have any links to get me started?
> >>
> >> The only distinction that ASF makes is binaries vs. source files. The
> >> source
> >> code that ASF releases has to be comprised of files that can be called
> >> source (under a reasonable definition of source). The only requirement
> >> for source files is that they MUST be usable without leveraging
> commercial
> >> tools. Other than that -- anything goes.
> >>
> >> Are you asking with a particular example in mind or just asking a
> >> hypothetical?
> >>
> >> Thanks,
> >> Roman.
> >>
> >
> >
>

Reply via email to