From: | Pavel Raiskup <praiskup(at)redhat(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(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 11:13:12 |
Message-ID: | 1889270.knKWB8YHDJ@nb.usersys.redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Tuesday 08 of March 2016 05:32:20 Dave Cramer wrote:
> We can and have accepted patches without test cases as long as an
> argument can be made why they can't be tested.
Good to hear. I've heard something like "no test => no patch, right?!" so
far.
I our case, it is IMO no need to test the potentially opt-outed feature,
which _is_ what is all this about. It is not needed to check in upstream
that the opt-out feature works (because everybody in downstream distro
packaging will take a look at this and do the opt-out). You also don't
need to run CI for Gentoo specific usecases I believe (a lot of options
for many packages). No need to install and test Fedora, we'll do that.
So, I agree -- having higher coverage is better, and if there is something
to test, we can do it. But we need to first discuss what can be changed.
> > 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.
This is _huge untrue_, there is no need to use license for this.
Is the interface so perfect so it can not be made better? In future? I
think this is obvious -- Why you can't prepare compatible and better
interface as concurrent solution? Why we need to wait for anybody?
Somebody just tries to protect its advantage.
Not modifiable code is vendor-lock-in; and that is not good project to
hard-depend on.
> From what I can see they are provided simply to allow you to build packages
> just like this.
Are you sure this is not a crossing the law border?
I'm not going to do this because I haven't "signed the papers" on the web
page as discussed in [1] (probably the correct place to download the
sources from). Downloading of that jar, using it and fixing FTBFS bugs in
that might be illegal. So I can't do 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Sitnikov | 2016-03-08 11:37:56 | Re: Complicated re-distribution of pgjdbc the "open source way" |
Previous Message | Dave Cramer | 2016-03-08 10:32:20 | Re: Complicated re-distribution of pgjdbc the "open source way" |