Step towards being able to build on Linux (Pull request #435) - Mailing list pgsql-jdbc

On Wednesday 20 of January 2016 16:48:17 Vladimir Sitnikov wrote:
> > Each dependency needs to be taken with
> >*serious carefulness* -- case-by-case, is this documented somewhere in
> >pgjdbc code (licence implications)?
>
> I'm not sure what is license clearance status of pgjdbc.

That is unlucky .. who should I ask?  At least adding new dependency is
big issue every committer should take into account.  I'm not sure about
licensing too -- and thats why we can't provide jdbc with osgi support.

> > Will that be after serious discussion?
>
> Fixes are "merged in" provided they have tests for the new functionality.
> That means, "#495 as of now" is NOT going to be merged in.

Thats your opinion, or project status?  So we are going to support only
those architectures which are in the CI github provides?

> What I am saying is people come and go. Do not expect everybody (or
> even a single person) on the list to remember all the peculiarities
> regarding to Fedora builds.

I've told you this about 4 times:  This is not Fedora only.  This is
matter of open source re-distribution model.

> >, but third-party binary software blobs *cannot be used at all*,
>
> Can you define how to tell if a particular *.java or *.xml file is a
> "binary blob" or not?

Yes, we do manual reviews.  By "software binary blob" I meant code (which
can be executed) which may, e.g., infect my machine.

> Vladimir> So, I could understand the requirement of "there should be a build
> Vladimir> parameter that excludes waffle from dependencies".
> Pavel>Do you have documentation for such approach, please?
>
> There is no such feature in pgjdbc yet.

I'm not asking about pgjdbc, I'm asking you - as Java hacker - how this is
_normally_ done.

> >And I don't think preprocessing in Java is an answer.
>
> Don't go to implementation details until you have requirements at hand.

I won't have all requirements to build on my system.

> I think all you are asking can be implemented with no problems.

Pavel sent you an approach.  Except the testsuite issue?

> On the other hand, I am not sure I understand your requirements, so I
> do not want to guess it.

See above^.  Dependencies.

> >This is very poor argument, to call this "issue", please say how much
> >slower it is and why.
>
> One can easily rant on that like You-Know-Who does (see [1])
> The strong argument is: it is extremely easy to forget the "Fedora's
> requirement", and commit some non-relevant change that would
> unexpectedly break Fedora.

See above. .. revert != unexpectedly.

> I'm -1 on committing any changes to pgjdbc that cannot be tested in pgjdbc's CI.
> Well, there might be exceptions, but this particular case is obviously
> not an exception.

Why this can't be tested?  Please stop spreading FUD.  This is the first
time you said you want test-case.

> No tests -- no commits here.
> Agreed?

Please stop being offensive.

> Vladimir> you to present your requirements in a
> Vladimir> clear & testable way
> Pavel>That's what we work towards.
>
> I'm all ears. No kidding.

You are not.  I'll re-read the thread once more.

Pavel