www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lahoda <lah...@gmail.com>
Subject Re: LICENSE and NOTICE file content
Date Tue, 26 Jun 2018 19:11:28 GMT
On Tue, Jun 26, 2018 at 7:28 PM, Alex Harui <aharui@adobe.com.invalid>

> *From: *Jan Lahoda <lahoda@gmail.com>
> *Reply-To: *"legal-discuss@apache.org" <legal-discuss@apache.org>
> *Date: *Tuesday, June 26, 2018 at 1:44 AM
> *To: *"legal-discuss@apache.org" <legal-discuss@apache.org>
> *Subject: *Re: LICENSE and NOTICE file content
> (As the NetBeans has (among others) a library for reading classfiles, I
> guess this discussion also relates to it, and I'd like to share some of my
> thoughts.)
> On Tue, Jun 26, 2018 at 7:15 AM, Alex Harui <aharui@adobe.com.invalid>
> wrote:
> code unless there is some way to solve the “security/safety” goal.  Maybe
> it is good enough to give the file a different suffix so it appears as a
> non-executable file.  But I would probably just have the tool’s source
> package build script download the convenience binary of the upstream test
> source package.
> That is extra overhead for sure, but I don’t think that is ‘impractical’.
> And I still wouldn’t hold up any release for this kind of issue.
> Incrementally make improvements in subsequent releases.  Create a test-data
> source release.  Then adjust the main source package to download the test
> jar.
> I may be too pessimistic, but in my experience when creating a test is
> more complicated, the probability of having a test decreases. And not
> having a test feels like a sub-optimal software engineering practice.
> FTR, I think there are multiple variants to avoid having classfiles in the
> repository, like maybe using jcod (not sure if that's OK or not); at the
> same time, I think having an approach that does not discourage proper
> engineering practices has benefits.
> Lots of things in ASF open source are “more complicated”.  As you noted,
> it takes at least 3 days to make a release.  You can’t just turn to a
> colleague, make a major decision and implement it.   Do these things

I'd like to point out I was not talking about major decisions. I was
talking about a (simple or not) bugfix. And for that bugfix, when one wants
to create a test case (or a set of test cases; which by themselves are
still in the source code), there may be a need to have data over which the
test runs. This test data may resemble some kind of source code, or
classfile, or something else; but it is really a data processed by the
test. Spending days on administrativia to publish a test data package for a
bugfix feels to be a little bit on the heavy side.

> discourage proper engineering practices?  Maybe, but they exist to help
> ensure the “sharing” and “safety”, and as you also mention, there are
> probably variants, or creative ways to not sacrifice integrity of your
> software.

I can imagine quite a few possibilities to avoid having test data classfile
in the repository, but, frankly, none one them feels to me like an obvious
right solution, which would fulfill well all the requirements. (Placing
binary classfiles is not such an obvious right solution either, of course,
but is simpler than the others I can imagine.)

> Hopefully you have a team of folks reviewing commits that would catch that
> a test is missing or use a tool to check that sufficient tests exist.  If a
> bug were found in the test source package, you could put both packages up
> for vote at the same time.
> What doesn’t seem right to me is that you can ship a binary without any
> way to recreate that binary from sources in a way sufficient enough to make
> it useful to others.  That doesn’t seem “open” or “source” to me.

I guess I struggle with what it means to "recreate test data". As an
example, in NetBeans there's a test that the classfile reading library does
not crash when it reads a (broken) classfile produced by a specific (fairly
old) version of JDK. If one had the source code, then it would be possible
to compile the source code, but unless one has the given JDK, that's not
recreating the test data. Current JDKs won't (AFAIK) produce the
problematic classfile, and then the test proves nothing.


> My 2 cents,
> -Alex

View raw message