Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)
От | Vladimir Sitnikov |
---|---|
Тема | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) |
Дата | |
Msg-id | CAB=Je-GOerqHisqFOVPdDOm2Rcrew5oOxMT4tEbT-BuqNcwvBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) (Pavel Raiskup <praiskup@redhat.com>) |
Ответы |
Step towards being able to build on Linux (Pull request #435)
|
Список | pgsql-jdbc |
> 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
В списке pgsql-jdbc по дате отправления: