Re: Step towards being able to build on Linux (Pull request #435)

>I'm asking you - as Java hacker - how this is
>_normally_ done.

Maven profile. See [1].
I do not understand why should I repeat that again and again.
I hope this time it would make the trick.

>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.

Frankly speaking, I've no idea how that is usually managed.
It looks like pgjdbc does not force to sign CLAs when accepting patches.

I'm not sure why you pay so much attention to osgi while completely
ignore the fact that pgjdbc includes lots of contributions (from
random people) itself.

The osgi jars in question are licensed under Apache 2.0.
jcp is Apache 2.0 as well.

>Thats your opinion, or project status?

That is my opinion. It seems to be in line with project development
for the recent year. I'm one of the committers if that matters you.

>So we are going to support only
>those architectures which are in the CI github provides?

Of course not. However, we do search for the possibilities to improve
testing coverage of pgjdbc (see [2]).
Current setup indeed limits us a lot. For instance, Travis job does
not test SSL. So we are having big troubles with that (lots of issues
from end-users). I does not mean we throw out SSL code. It just does
mean we are extra careful not to touch that code if that is possible.

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

I do not want to stretch that, but I wonder if you call "sql statement
inside a java code" a "software binary blob" "which can be executed in
backend" and "infect the machine via integer overflow or whatever".
I mean: what if I convert osgi.jar into a java file into a form of
some select statements? Would it heal your case?

>Pavel sent you an approach.  Except the testsuite issue?

Yes. Without a testcase I cannot understand what that commit is trying
to accomplish.

>See above. .. revert != unexpectedly.

revert == unexpectedly.
I'm pretty sure we play well, and we are not going to explicitly delete that.

See [3] for an "innocent fix" that broke query batching just because
the same value was reused for a bit field.
Once again: a *major feature* was unexpectedly reverted and passed peer-review.

All what I was saying has happened to pgjdbc recently. So I am not
just raising "theoretical problems", but I'm highlighting the exact
way "a feature without testing" is going to have

>Why this can't be tested?

I did not mean "that particular commit cannot be tested".
I meant "if a patch does not include tests, it gets -1 for that".
If a patch does have tests, then it is worth reviewing as usual.
Sometimes, it is hard to add tests. Then the patch can still be
reviewed, however, it requires much more attention.

> Please stop being offensive.

I try to be explicit, so you can understand what I convey easier.
English is not my first language, so please accept my apologies if
that was offensive.
I'm trying to learn from grammar corrections, unfortunately I do not
receive many of them.

[1]: http://stackoverflow.com/a/167284/1261287
[2]: https://github.com/pgjdbc/pgjdbc/issues/461
[3]: https://github.com/pgjdbc/pgjdbc/commit/a6bd36faaedc779f932fa76f52bab9550f0fcd6d

Vladimir