On Tuesday 08 of March 2016 14:37:56 Vladimir Sitnikov wrote:
> Pavel>Not modifiable code is vendor-lock-in
>
> org.osgi.enterprise jar is Apache 2.0-licensed.
> Apache 2.0 allows modification of a source code. Surprise.
It is actually not correct, as far as I am aware. The links you provided
so far are results of official build, which puts the sources there by
default. Can we convince upstream to release official tarballs without
the "signature needed" request that disallows you to modify?
> Pavel>I our case, it is IMO no need to test the potentially opt-outed
> Pavel>feature,
>
> You claim to "invent common build denominator feature", then you claim
> "there's no need to test it".
> Are you kidding?
Yes, here is your excuse :) I talked about, or?
You test your full-feature-set you support ATM. That is fine, I do not
plan to stop testing something.
Some people (not you but me!) do want to disable something for themselves,
what exactly do you want to test on it?
But we can probably simulate the situation for you -- we can always do two
builds in upstream CI -- with/without the feature, even though you support
only the first scenario. Do I understand it right this is wanted?
> As per Dave's words: "can you explain why packaging can't be tested"?
> "no need" != "can't" as far as I can understand.
> I think package testing should be rather simple.
It is tested. I don't think you want it upstream as you don't support
packages we re-distribute.
> Pavel> It is not needed to check in upstream
> Pavel>that the opt-out feature works
>
> You seem to ignore the main aim of testing. The tests are there to
> catch unintentional changes.
No. I appreciate testing, be fair please.
You know that there are tests _already_; that would catch the issues we
could potentially add into existing level of your support ... so we can
fix the patches we propose to not do that.
I just say -- don't test that the '--opt-out-waffle' and '--opt-no-osgi',
whatever format it will have. Then you know that "nobody" except for
packagers use those -- and the guys know how to fix this if something
wrong happens...
> If no tests added, any innocent refactoring might break your packaging
> script.
And, again -- don't be afraid here, that is why we are here. You can not
provide packaging scripts for the whole world, it is not upstream
responsibility and no upstream does this.
Pavel