Re: Complicated re-distribution of pgjdbc the "open sourceway" - Mailing list pgsql-jdbc

On 08/03/16 00:49, Árpád Magosányi wrote:
> Hola Álvaro,

     Hi Árpád, thanks for your Spanish salutation :)
>
> Just some observations. We've been there and done that with upstream.
> Maintaining a package with patches this way can easily get to be a big
> burden. At some point it becomes a habit, and the big bad surprise comes
> when you want to upgrade after a period of lazyness..

     That's surely true. However, the suggested patch to maintain
(please see the code when submitted here) is minimal. Indeed, it's not
code per se. It's just removing some sections of the code -and their
dependencies- that while useful upstream do not make sense in Fedora
(like a Windows subsystem).

     Indeed, it makes sense packager's patch mechanism. After all, you
may not need stuff that upstream *does* want to have (like, again,
Windows stuff). But obviously, upstream cannot be forced to dump that stuff.

     I doubt maintaining this kind of patches should become a burden.
They are not growing and/or diverging patches, but rather static and
straightforward to adapt if upstream modifies related files.

> I do not want to have a stand on the underlying conflict. Maybe the
> healthy github pulse and the quick, accepting treatment of #252 are just
> misleading me... 3:)

     I guess you're referring to
https://github.com/pgjdbc/pgjdbc/pull/252 That was ant, and now we're on
maven. Things may or may not be different, but as I have so far seen,
upstream is not considering removing these dependencies as of today, and
that's why a fork has been suggested.

> _If you do think that there will be things which should be permanently
> patched_ , I would recommend the following to keep the gap (hence
> maintenance burden) as small as possible:
> - Use a fork on github.
     Could be a nice way of maintaining it.
> - Have integration branches for all important upstream branches, where a
> CI job continously merges upstream and tests whether it is still working.
     Right.
> - Open a pull request in upstream for every commit you have. Give them a
> chance to sync up.

     As I mentioned, I don't think this will work. The patches that
Fedora requires are considered necessary by upstream, as they make sense
there (but not in Fedora). That's why there's all this discussion ;P

> - Change only what is absolutely necessary, including not just code, but
> also development practices and standards.

     I would keep it to the minimal, for sure.

>
> Side note: My understanding of maven is that you can exactly control
> your direct dependencies in the pom, and you can have a list including
> transitives with the dependency plugin. You can check and abort build if
> an unexpected dependency comes up. So no need to have an inferior build
> system just because dependencies.

     I'm not sure if I got what you mean here, but if you mean ant is an
inferior solution the answer is yes and pgjdbc will not move back to
and, maven is the choice and for good reasons.

     Thanks for your comments,

     Álvaro


--
Álvaro Hernández Tortosa


-----------
8Kdata



>
>
> On 03/07/2016 10:21 PM, Álvaro Hernández Tortosa wrote:
>>      Hi Pavel.
>>
>>      As you are well aware :) we (as in 8Kdata) are packaging ToroDB,
>> java software that relies on pgjdbc. Since we saw that this issue was
>> not moving forward, we investigated the issue on our own.
>>
>>      While as of today the current ToroDB spec that we have is
>> depending on an older version of JDBC --which is highly undesirable--
>> we have also built a simple mean of packaging pgjdbc for Fedora
>> without having to modify upstream.
>>
>>      Since RPM packages allow (and some of them heavily use) patches
>> against upstream, this is easy to accomplish. Having a parent pom is
>> neither a problem --it is packaged as a subpackage (might not be
>> ideal, but hey, it works, and it doesn't harm). All in all, with all
>> the obvious advantages and disadvantages, we have working source code.
>> Rather than a will to patch upstream or fork pgjdbc, we have a working
>> spec that packages pgjdbc, removing (by patching) all the non-foss and
>> windows dependencies and code, and packaging the parent pom too.
>>
>>      I believe iterating over this effort is better than either forking
>> or patching upstream.
>>
>>      I don't have the code, but Matteo (cc'ed), who did this work, will
>> share it tomorrow.
>>
>>      I'd suggest to work on this, which seems to me as a compromise
>> solution, and agree all on this solution, rather than plan longer-term
>> plans that, while ideal for some, aren't for the rest and, and above
>> all, will take significantly more effort. Our main goal is to deliver
>> packaged and foss pgjdbc to the users asap, and here we have an
>> already working solution.
>>
>>      Matteo, please share the code whenever possible.
>>
>>      Cheers,
>>
>>      Álvaro
>>