Re: Complicated re-distribution of pgjdbc the "open source way"

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Pavel Raiskup <praiskup(at)redhat(dot)com>
Cc: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org>, hhorak(at)redhat(dot)com, Pavel Kajaba <pkajaba(at)redhat(dot)com>, Andrew Ross <ubuntu(at)rossfamily(dot)co(dot)uk>, doko(at)debian(dot)org, Jesse Jaara <jesse(dot)jaara(at)gmail(dot)com>, ago(at)gentoo(dot)org, Nico Nicolas <nicolas(dot)lecureuil(at)free(dot)fr>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
Subject: Re: Complicated re-distribution of pgjdbc the "open source way"
Date: 2016-03-08 10:32:20
Message-ID: CADK3HH+hGZZFmTigS1W9_fGavRpSgSU-T24AV-UWhSkrkZFXPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 8 March 2016 at 04:33, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:

> On Monday 07 of March 2016 18:31:41 Vladimir Sitnikov wrote:
> > Pavel>what is more important we could do the job _consistently_
> > Pavel>with a lot _less_ packagers effort.
> >
> > I think "testing" is the key answer here to get consistent results.
>
> I am talking about the downstream patching effort -- that should be done
> consistently in all distributions.
>
> > Pavel>* the build would be 1-step process
> > Pavel> Any thoughts?
> >
> > This all reminds me the 14 competing standards (see [1])
> > Do you mean "1-step" as in "1-cpu-instruction"?
> > Is "./build.sh" a "1-step"?
>
> By one step I mean something like './build.sh' in terms of package
> building. That is -- no need to build parent-poms (one-file) package
> before (or build stub package first, add this to repository and then build
> again the full package).
>
> > Pavel> even patches from us to support pure open source build are not
> wanted
> >
> > I'm afraid this ^^ is misleading.
> >
> > Patches are welcome provided they include tests to cover the change.
> > No tests -> no acceptance. It is in line with typical development
> > model, isn't it?
>
> This is *your* easy excuse to not incorporate change ;). 100% coverage is
> a sci-fi, as anybody must agree. What am I going to test on Fedora if I
> patch osgi out? Am I going to test that it does not work? If yes, I'm
> fine to write the patch.
>
> We can and have accepted patches without test cases as long as an argument
can be made
why they can't be tested.

> You refused attempts to post patches which would make some code optional,
> at which point it is not useful to think about testing something.
>
> Other than that, not everything is easily testable in your actual CI.
>
> > Pavel>_Open_ distribution¹
> > Pavel> By FOSS source I mean software which
> > Pavel> _anybody_ can read, study, copy, modify, distribute
> >
> > Can you tell us if org.osgi.enterprise complies with your definition
> > of "open distribution"?
>
> The license refuses you to modify the code, it is *clear vendor lock-in*
> and:

> """
> anybody who cares a bit about open source principles should at least
> be aware of its consequences
> """

This is a red-herring. The whole purpose of osgi is to provide a consistent
interface to allow
loading of software. If you were to modify it, it would fail to be
relevant. Blindly applying OSS
principles does not make sense here.

>
>
Also, your build system should allow us to build without this support.
> That is how everything else works. Can we submit patches for this?
>
> > Just in case you say "no", see [2] (download jar and note that sources
> > are in OSGI-OPT folder) for complete source code that is available
> > under Apache 2.0 license -> you can read, copy, modify and distribute
> > it with no problem.
>
> But as far as I understand, those jars are not original sources -- those
> are products of some build (which automatically adds some license file
> there? or what is automatized? Is it easily re-build-able?).
>

From what I can see they are provided simply to allow you to build packages
just like this.

>
> You are allowed to download original sources, but you can't modify them.
> I stopped the observation here as that is simply not acceptable -- this
> has been discussed in mentioned threads, direct reference is [1]
> (reference by Vitalii).
>

See above

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Pavel Raiskup 2016-03-08 11:13:12 Re: Complicated re-distribution of pgjdbc the "open source way"
Previous Message Pavel Raiskup 2016-03-08 10:30:07 Re: Complicated re-distribution of pgjdbc the "open source way"