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

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@postgresintl.com
> www.postgresintl.com