> 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.
>Be concrete Vladimir. Who is going to merge this and who is going to
>revert that later.
Fixes are merged by committers. Is that what you are asking?
> 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.
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.
>, 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?
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.
>And I don't think preprocessing in Java is an answer.
Don't go to implementation details until you have requirements at hand.
I think all you are asking can be implemented with no problems.
On the other hand, I am not sure I understand your requirements, so I
do not want to guess it.
>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.
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.
No tests -- no commits here.
Agreed?
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.
[1]: http://shipilev.net/blog/2015/black-magic-method-dispatch/
Vladimir