On Mon, Jun 2, 2014 at 11:48 AM, Rupert Westenthaler < rupert.westentha...@gmail.com> wrote:
> Hi all, > > 1. Regarding versioning: > > For me it is ok to (pre-)release single components of the > 1.0.0-SNAPSHOT branch as soon as they are ready. What I do not like is > to obfuscate this by using 0.99 as version. So I would prefer to use > 1.0.0 or maybe 1.0.0-beta instead. > > > 2. Regarding the release > > + ./releasing/check_staged_release.sh 1006 .. OK > + ./releasing/check_release_matches_tag.sh 1006 /tmp/stanbol-staging/ .. OK > + build is fine > + DEPENDENCIES, NOTICE and LICENSE files are present and do look fine > > So out of my point of view the forged release is OK > > > 3. Regarding the other mentioned issues: > > In fact there where a lot of discussions about this component when it > was introduced first. It is also true that enabling the Java Security > Manager causes issues with a lot of used libraries (especially > Lucene/Solr and Tika) as they do not natively support it. For all > those libraries one need to manually care about security related > things by writing code as described at [1]. > > AFAIK all Stanbol components (including all Enhancement Engines) are > compatible with an enabled Java Security Manager. For new components > issues like that are discovered by the Integration tests - as those > do run with the Security Manager enabled. > > My personal opinion has not changed since the beginning. If someone > wants to restrict access to some Stanbol services he should run a > gateway. I have not come along an use case that requires to do the > user-management within Stanbol. But I accept that others may have such > use cases. So while I personally always exclude the security related > modules form my custom Stanbol launchers (as also Sergio and Rafa > pointed out) I am fine with having such modules around. > > I trust in those users that do use the security features in filing > issues and in the community in fixing the same. This release solving > STANBOL-1094 and STANBOL-1317 is an example of this process. > > To conclude: > > While I am clearly in favor of this release I would like to have a > discussion about the the use version. I am strongly against 0.99. IMO > only 0.13 or 1.0.0 are possible option. Personally I do have a strong > preference for 1.0.0 > Hi Rupert Thank you for your review and your differentiated comments. I have no problem against 1.0.0. That's actually how I started tailoring the release but then I thought it might "politically" easier to get the release through by not using the "big" number. But you're right, the release arises from the 1.0.0-SNAPSHOT trunk version so using this version would be the most logical option. In this case it would howver probably be the best to also release the parent so that the released 1.0.0 versions do not use an older version of the parent than the 1.0.0-SNAPSHOT version. Cheers, Reto > > best > Rupert > > > [1] http://stanbol.apache.org/development/security.html > > On Mon, Jun 2, 2014 at 10:52 AM, Rafa Haro <rh...@apache.org> wrote: > > really ? :-) > > > > El 02/06/14 10:32, Reto Gmür escribió: > > > >> On Mon, Jun 2, 2014 at 9:09 AM, Rafa Haro <rh...@apache.org> wrote: > >> > >>> Hi, > >>> > >>> El 02/06/14 08:35, Sergio Fernández escribió: > >>> > >>> Hi, > >>>> > >>>> is the stuff really tested by a broader community? Personally I've had > >>>> to > >>>> disable it in all my launchers due several issues with other > components. > >>>> So > >>>> I'd like to clarify that before casting my vote. > >>>> > >>> I'm exactly in the same situation than Sergio. I honestly haven't > tested > >>> it because of the problems in the firsts releases of the component. > >> > >> > >> Hi Rafa > >> > >> You voted +1 to the previous release of these components on February > 25th. > >> What testing could you do back then, that you can no longer do now? > >> > >> Cheers, > >> Reto > >> > >> > >>> > >>>> Thanks. > >>>> > >>>> Cheers, > >>>> > >>>> PD: as Andreas pointed, the versioning is also quite confusing... I > >>>> though the community had decided to switch from the old version policy > >>>> (individual per module) to a common one for all modules. > >>>> > >>>> > >>>> On 02/06/14 00:16, Reto Gmür wrote: > >>>> > >>>>> Hi community, > >>>>> > >>>>> Given that the 1.0.0 release might take some more discussion I've > >>>>> tailored > >>>>> a mini-release of two modules. The 0.12 security.core module doesn't > >>>>> work > >>>>> with jersey >= 2.0 because of what I believe to be a bug in Jersey > >>>>> (JERSEY-1926) but a work-around working with all Jersey versions is > >>>>> straight forward and has been in trunk for almost exactly one year. > >>>>> Apart > >>>>> from the patch to work around JERSEY-1926 affecting security.core and > >>>>> authentication.basic the new release also incorporates the code > >>>>> simplification patch provided by Furkan Kamaci (STANBOL-1317). > >>>>> > >>>>> Solved issues: > >>>>> - STANBOL-1094 > >>>>> - STANBOL-1317 > >>>>> > >>>>> SVN-Tag: > >>>>> https://svn.apache.org/repos/asf/stanbol/tags/org.apache. > >>>>> stanbol.commons.security-0.99/ > >>>>> > >>>>> Staging repos > >>>>> https://repository.apache.org/content/repositories/ > >>>>> orgapachestanbol-1006/ > >>>>> > >>>>> Source tarball: > >>>>> http://repository.apache.org/content/repositories/ > >>>>> orgapachestanbol-1006/org/apache/stanbol/org.apache. > >>>>> stanbol.commons.security/0.99/org.apache.stanbol.commons. > >>>>> security-0.99-source-release.tar.gz > >>>>> > >>>>> Detached signature: > >>>>> https://repository.apache.org/content/repositories/ > >>>>> orgapachestanbol-1006/org/apache/stanbol/org.apache. > >>>>> stanbol.commons.security/0.99/org.apache.stanbol.commons. > >>>>> security-0.99-source-release.tar.gz.asc > >>>>> > >>>>> PGP release keys > >>>>> https://dist.apache.org/repos/dist/release/stanbol/KEYS > >>>>> > >>>>> The vote will be open for at least 48 hours. > >>>>> Thanks for reviewing this release and for voting! > >>>>> > >>>>> Cheers, > >>>>> Reto > >>>>> > >>>>> > > > > > > -- > | Rupert Westenthaler rupert.westentha...@gmail.com > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen > | REDLINK.CO > .......................................................................... > | http://redlink.co/ >
