Re: Complicated re-distribution of pgjdbc the "open sourceway"

Hola Álvaro,

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..
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:)
_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.
- Have integration branches for all important upstream branches, where a
CI job continously merges upstream and tests whether it is still working.
- Open a pull request in upstream for every commit you have. Give them a
chance to sync up.
- Change only what is absolutely necessary, including not just code, but
also development practices and standards.

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.


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
>