Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[sebb]

On 11 May 2012 16:29, Francesco Chicchiriccò  wrote:
> I've created a 1.0.0-RC1-incubating release, with the following artifacts up
> for a vote:
>
> SVN source tag ( r1335495):
> https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?

> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachesyncope-055/
>
> Source release (checksums and signatures are available at the same
> location):
> https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.tar.gz
> https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.zip
>
> PGP release keys (signed using 273DF287):
> http://www.apache.org/dist/incubator/syncope/KEYS
>
> This has been voted through on the syncope-...@incubator.apache.org mailing
> list [1],
> and now requires a vote on general@incubator.apache.org
>
> Votes already cast (on syncope-dev):
>
> +1 (binding)
> * Francescp Chicchiriccò
> * Massimiliano Perrone
> * Fabio Martelli
> * Simone Tripodi
> * Colm O hEigeartaigh (IPMC member)
>
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Best regards.
>
> [1]
> http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-0-RC1-incubating-5th-attempt-tt5694411.html
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/12/12 1:42 AM, sebb a écrit :

On 11 May 2012 16:29, Francesco Chicchiriccò  wrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts up
for a vote:

SVN source tag ( r1335495):
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?


Depends. As the first vote has been canceled, there was nothing like an 
official RC1.


As noted in the subject, this is the 2nd attempt for RC1.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[sebb]

On 12 May 2012 23:59, Emmanuel Lécharny  wrote:
> Le 5/12/12 1:42 AM, sebb a écrit :
>
>> On 11 May 2012 16:29, Francesco Chicchiriccò  wrote:
>>>
>>> I've created a 1.0.0-RC1-incubating release, with the following artifacts
>>> up
>>> for a vote:
>>>
>>> SVN source tag ( r1335495):
>>>
>>> https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
>>
>> If this is the second attempt, why is it called RC1 ?
>>
>> Surely it should be called RC2 ?
>
>
> Depends. As the first vote has been canceled, there was nothing like an
> official RC1.

RC means Release candidate; if the vote passes, it becomes the release.

> As noted in the subject, this is the 2nd attempt for RC1.

Does not make sense.

The second attempt is the second release candidate, i.e. RC2.

>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 1:03 AM, sebb a écrit :

On 12 May 2012 23:59, Emmanuel Lécharny  wrote:

Le 5/12/12 1:42 AM, sebb a écrit :


On 11 May 2012 16:29, Francesco Chicchiriccòwrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts
up
for a vote:

SVN source tag ( r1335495):

https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?


Depends. As the first vote has been canceled, there was nothing like an
official RC1.

RC means Release candidate; if the vote passes, it becomes the release.


As noted in the subject, this is the 2nd attempt for RC1.

Does not make sense.

The second attempt is the second release candidate, i.e. RC2.
This is not the semantic we are using. A RC is just a relese that we 
expect to become the GA if no major issue is encountered. It's not 
something like an attempt to release.


See 
http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate


The fact that we have to check that a RC is a valid RC against the ASF 
croteria does not impede the numbering scheme we use : we keep trying to 
cut a release, with the same number, until we get it correct. At least, 
that's my opinion, which may not be shared.


In any case, it should not be a blocker...

Thanks !

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Francesco Chicchiriccò]

On 14/05/2012 01:03, sebb wrote:
> On 12 May 2012 23:59, Emmanuel Lécharny  wrote:
>> Le 5/12/12 1:42 AM, sebb a écrit :
>>
>>> On 11 May 2012 16:29, Francesco Chicchiriccò  wrote:
 I've created a 1.0.0-RC1-incubating release, with the following artifacts 
 up for a vote:

 SVN source tag ( r1335495):

 https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
>>> If this is the second attempt, why is it called RC1 ?
>>>
>>> Surely it should be called RC2 ?
>> Depends. As the first vote has been canceled, there was nothing like an 
>> official RC1.
> RC means Release candidate; if the vote passes, it becomes the release.
>> As noted in the subject, this is the 2nd attempt for RC1.
> Does not make sense.
>
> The second attempt is the second release candidate, i.e. RC2.

We agreed on a version scheme where RCi are full releases (from release
process point of view) while not including everything planned on JIRA
for the corresponding version: hence, our 1.0.0-RC1-incubating doesn't
have all fixes planned for 1.0.0-incubating.

In other words, RC1 is referring to the completeness of the code against
the issues, not to the completeness of the release against the release
requirements.

At least, this is how we defined Syncope release numbering scheme;
moreover, it seems to me that every project is defining its own
versioning ([1] [2] [3] for example), and I personally think it's correct.

Release numbers are just labels, after all, isn't it?

Anyway, is there also other IPMC available to check the release to bind
his vote? Thanks!

Regards.

[1] http://httpd.apache.org/dev/release.html
[2] http://commons.apache.org/releases/versioning.html
[3] http://apr.apache.org/versioning.html

-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[sebb]

On 14 May 2012 08:47, Francesco Chicchiriccò  wrote:
> On 14/05/2012 01:03, sebb wrote:
>> On 12 May 2012 23:59, Emmanuel Lécharny  wrote:
>>> Le 5/12/12 1:42 AM, sebb a écrit :
>>>
 On 11 May 2012 16:29, Francesco Chicchiriccò  wrote:
> I've created a 1.0.0-RC1-incubating release, with the following artifacts 
> up for a vote:
>
> SVN source tag ( r1335495):
>
> https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
 If this is the second attempt, why is it called RC1 ?

 Surely it should be called RC2 ?
>>> Depends. As the first vote has been canceled, there was nothing like an 
>>> official RC1.
>> RC means Release candidate; if the vote passes, it becomes the release.
>>> As noted in the subject, this is the 2nd attempt for RC1.
>> Does not make sense.
>>
>> The second attempt is the second release candidate, i.e. RC2.
>
> We agreed on a version scheme where RCi are full releases (from release
> process point of view) while not including everything planned on JIRA
> for the corresponding version: hence, our 1.0.0-RC1-incubating doesn't
> have all fixes planned for 1.0.0-incubating.
>
> In other words, RC1 is referring to the completeness of the code against
> the issues, not to the completeness of the release against the release
> requirements.
>
> At least, this is how we defined Syncope release numbering scheme;
> moreover, it seems to me that every project is defining its own
> versioning ([1] [2] [3] for example), and I personally think it's correct.
>
> Release numbers are just labels, after all, isn't it?

Yes, they are just a convention, but if the convention is not in
general use, then  it is potentially confusing.

Other projects use alphaN / betaN suffixes, or Mnn for milestone releases.

It's particularly confusing that the same SVN tag is used for both
source releases

This release vote uses:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

Previous release vote:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

Tags should ideally be immutable.

Similarly for the source archives - the names are identical:
syncope-root-1.0.0-RC1-incubating-source.zip
syncope-root-1.0.0-RC1-incubating-source.zip

> Anyway, is there also other IPMC available to check the release to bind
> his vote? Thanks!

I think there are some problems with the N&L files in the source archive.

The N&L files are supposed to relate to the actual items included in
the archive; however the N&L in the source archive include references
to binaries which are clearly not included in the archive.

IMO this is wrong, and needs to be corrected.

> Regards.
>
> [1] http://httpd.apache.org/dev/release.html
> [2] http://commons.apache.org/releases/versioning.html
> [3] http://apr.apache.org/versioning.html
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 4:05 PM, sebb a écrit :

On 14 May 2012 08:47, Francesco Chicchiriccò  wrote:

On 14/05/2012 01:03, sebb wrote:

On 12 May 2012 23:59, Emmanuel Lécharny  wrote:

Le 5/12/12 1:42 AM, sebb a écrit :


On 11 May 2012 16:29, Francesco Chicchiriccòwrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts up 
for a vote:

SVN source tag ( r1335495):

https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?

Depends. As the first vote has been canceled, there was nothing like an 
official RC1.

RC means Release candidate; if the vote passes, it becomes the release.

As noted in the subject, this is the 2nd attempt for RC1.

Does not make sense.

The second attempt is the second release candidate, i.e. RC2.

We agreed on a version scheme where RCi are full releases (from release
process point of view) while not including everything planned on JIRA
for the corresponding version: hence, our 1.0.0-RC1-incubating doesn't
have all fixes planned for 1.0.0-incubating.

In other words, RC1 is referring to the completeness of the code against
the issues, not to the completeness of the release against the release
requirements.

At least, this is how we defined Syncope release numbering scheme;
moreover, it seems to me that every project is defining its own
versioning ([1] [2] [3] for example), and I personally think it's correct.

Release numbers are just labels, after all, isn't it?

Yes, they are just a convention, but if the convention is not in
general use, then  it is potentially confusing.

Other projects use alphaN / betaN suffixes, or Mnn for milestone releases.

It's particularly confusing that the same SVN tag is used for both
source releases

This release vote uses:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

Previous release vote:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
A tag is just a name. We don't vote tags, we vote a source package, ie a 
SVN revision number.


The reason we add the number of attempt in the subject is just to avoid 
a possible confusion.




Tags should ideally be immutable.

SVN revisions are immutable.


Similarly for the source archives - the names are identical:
syncope-root-1.0.0-RC1-incubating-source.zip
syncope-root-1.0.0-RC1-incubating-source.zip


Anyway, is there also other IPMC available to check the release to bind
his vote? Thanks!

I think there are some problems with the N&L files in the source archive.

The N&L files are supposed to relate to the actual items included in
the archive; however the N&L in the source archive include references
to binaries which are clearly not included in the archive.
Syncope generates war files, which include those binaries. Using the 
source per se does not give you anything usabe, and those using the war 
files will have those binaries included. Not having the full N&L 
(including for binaries) would be harmfull for users, IMO.


I'll check against some other projects that have the same kind of 
distribution to double check.


Holding my vote atm.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Christian Grobmeier]

Can you please let me know which license XPP uses? I could not find
informatino in NOTICE and did not find a website which helped me. its
necessary to clarify that as xpp3 is in the war file release. Once you
told me, I will give my +1

Release looks ok so far.

I have found files like that:
syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5

here:
https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-build-tools/1.0.0-RC1-incubating/

Personally I think it is not necessary to deliver md5 sums for asc
files. Of course not a blocker.

Other question: the projects I know vote upon a website too. Is this
not the case with Syncope?

Cheers
Christian


On Fri, May 11, 2012 at 5:29 PM, Francesco Chicchiriccò
 wrote:
> I've created a 1.0.0-RC1-incubating release, with the following artifacts up
> for a vote:
>
> SVN source tag ( r1335495):
> https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachesyncope-055/
>
> Source release (checksums and signatures are available at the same
> location):
> https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.tar.gz
> https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.zip
>
> PGP release keys (signed using 273DF287):
> http://www.apache.org/dist/incubator/syncope/KEYS
>
> This has been voted through on the syncope-...@incubator.apache.org mailing
> list [1],
> and now requires a vote on general@incubator.apache.org
>
> Votes already cast (on syncope-dev):
>
> +1 (binding)
> * Francescp Chicchiriccò
> * Massimiliano Perrone
> * Fabio Martelli
> * Simone Tripodi
> * Colm O hEigeartaigh (IPMC member)
>
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Best regards.
>
> [1]
> http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-0-RC1-incubating-5th-attempt-tt5694411.html
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :

Can you please let me know which license XPP uses? I could not find
informatino in NOTICE and did not find a website which helped me. its
necessary to clarify that as xpp3 is in the war file release. Once you
told me, I will give my +1

Clearly missing in the N&L files.


Release looks ok so far.

I have found files like that:
syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5


This is a maven bug. The signature plugin does sign everything, 
including the .asc file, AFAIK.


Other question: the projects I know vote upon a website too. Is this
not the case with Syncope?


Hmmm... Good question. I never voted against any web site on the various 
projects I worked or mentored. Where does it come from ?



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Christian Grobmeier]

On Mon, May 14, 2012 at 7:56 PM, Emmanuel Lécharny  wrote:
> Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :
>
>> Can you please let me know which license XPP uses? I could not find
>> informatino in NOTICE and did not find a website which helped me. its
>> necessary to clarify that as xpp3 is in the war file release. Once you
>> told me, I will give my +1
>
> Clearly missing in the N&L files.

OK. Guess this should be fixed with a new attempt then.

>> Release looks ok so far.
>>
>> I have found files like that:
>> syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5
>
> This is a maven bug. The signature plugin does sign everything, including
> the .asc file, AFAIK.

At Commons usually we delete these files manually. If you don't mind,
its really not an issue. Just wanted to mention it.

>> Other question: the projects I know vote upon a website too. Is this
>> not the case with Syncope?
>
> Hmmm... Good question. I never voted against any web site on the various
> projects I worked or mentored. Where does it come from ?

We include a link to the staged website at Commons and I have done so for log4j.
I just checked the latest Struts vote, we don't include the site there.
Guess its just matter of taste.

Cheers
Christian

>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[sebb]

On 14 May 2012 19:45, Christian Grobmeier  wrote:
> On Mon, May 14, 2012 at 7:56 PM, Emmanuel Lécharny  
> wrote:
>> Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :
>>
>>> Can you please let me know which license XPP uses? I could not find
>>> informatino in NOTICE and did not find a website which helped me. its
>>> necessary to clarify that as xpp3 is in the war file release. Once you
>>> told me, I will give my +1
>>
>> Clearly missing in the N&L files.
>
> OK. Guess this should be fixed with a new attempt then.

But only if the specific archive actually contains XPP.

Yes, this means that the N&L files for the source archive and the
binary archive are different.
But that is required if the binary archive contains additional
"notifiable" items that are not in the source archive.

>>> Release looks ok so far.
>>>
>>> I have found files like that:
>>> syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5
>>
>> This is a maven bug. The signature plugin does sign everything, including
>> the .asc file, AFAIK.
>
> At Commons usually we delete these files manually. If you don't mind,
> its really not an issue. Just wanted to mention it.
>
>>> Other question: the projects I know vote upon a website too. Is this
>>> not the case with Syncope?
>>
>> Hmmm... Good question. I never voted against any web site on the various
>> projects I worked or mentored. Where does it come from ?
>
> We include a link to the staged website at Commons and I have done so for 
> log4j.
> I just checked the latest Struts vote, we don't include the site there.
> Guess its just matter of taste.
>
> Cheers
> Christian
>
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Christian Grobmeier]

On Mon, May 14, 2012 at 11:44 PM, sebb  wrote:
> On 14 May 2012 19:45, Christian Grobmeier  wrote:
>> On Mon, May 14, 2012 at 7:56 PM, Emmanuel Lécharny  
>> wrote:
>>> Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :
>>>
 Can you please let me know which license XPP uses? I could not find
 informatino in NOTICE and did not find a website which helped me. its
 necessary to clarify that as xpp3 is in the war file release. Once you
 told me, I will give my +1
>>>
>>> Clearly missing in the N&L files.
>>
>> OK. Guess this should be fixed with a new attempt then.
>
> But only if the specific archive actually contains XPP.

This file contains xpp3*.jar as mentioned above:

https://repository.apache.org/content/repositories/orgapachesyncope-055/org/apache/syncope/syncope-build-tools/1.0.0-RC1-incubating/syncope-build-tools-1.0.0-RC1-incubating.war

Cheers

>
> Yes, this means that the N&L files for the source archive and the
> binary archive are different.
> But that is required if the binary archive contains additional
> "notifiable" items that are not in the source archive.
>
 Release looks ok so far.

 I have found files like that:
 syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5
>>>
>>> This is a maven bug. The signature plugin does sign everything, including
>>> the .asc file, AFAIK.
>>
>> At Commons usually we delete these files manually. If you don't mind,
>> its really not an issue. Just wanted to mention it.
>>
 Other question: the projects I know vote upon a website too. Is this
 not the case with Syncope?
>>>
>>> Hmmm... Good question. I never voted against any web site on the various
>>> projects I worked or mentored. Where does it come from ?
>>
>> We include a link to the staged website at Commons and I have done so for 
>> log4j.
>> I just checked the latest Struts vote, we don't include the site there.
>> Guess its just matter of taste.
>>
>> Cheers
>> Christian
>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Francesco Chicchiriccò]

On 14/05/2012 20:45, Christian Grobmeier wrote:

On Mon, May 14, 2012 at 7:56 PM, Emmanuel Lécharny  wrote:

Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :


Can you please let me know which license XPP uses? I could not find informatino 
in NOTICE and did not find a website which helped me. its necessary to clarify 
that as xpp3 is in the war file release. Once you told me, I will give my +1

Clearly missing in the N&L files.

OK. Guess this should be fixed with a new attempt then.


Will do ASAP - guess we are trying to beat some record at Syncope: I 
know that Flex made it in seven attempts, we are approaching... ;-)


Jokes apart, we are talking here about XPP3, a transitive dependency of 
XStream which is instead a declared dependency of Syncope (core).
We honestly did not consider at all such dependencies in L&N files, and 
there are quite some: what's the best practice for such cases? I see no 
option but using the maven dependency plugin in order to find all 
transitive dependencies and update L&N files consequently.


Is this correct? Basically, I feel this like breaking the Maven 
dependency resolution...



Release looks ok so far.

I have found files like that:
syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5

This is a maven bug. The signature plugin does sign everything, including
the .asc file, AFAIK.

At Commons usually we delete these files manually. If you don't mind,
its really not an issue. Just wanted to mention it.


Other question: the projects I know vote upon a website too. Is this
not the case with Syncope?

Hmmm... Good question. I never voted against any web site on the various
projects I worked or mentored. Where does it come from ?

We include a link to the staged website at Commons and I have done so for log4j.
I just checked the latest Struts vote, we don't include the site there.
Guess its just matter of taste.


Nice suggestion: we'll take into account for (hopefully) next releases.

Thanks for your support.
Regards.


--
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/15/12 9:31 AM, Francesco Chicchiriccò a écrit :

On 14/05/2012 20:45, Christian Grobmeier wrote:
On Mon, May 14, 2012 at 7:56 PM, Emmanuel 
Lécharny  wrote:

Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :

Can you please let me know which license XPP uses? I could not find 
informatino in NOTICE and did not find a website which helped me. 
its necessary to clarify that as xpp3 is in the war file release. 
Once you told me, I will give my +1

Clearly missing in the N&L files.

OK. Guess this should be fixed with a new attempt then.


Will do ASAP - guess we are trying to beat some record at Syncope: I 
know that Flex made it in seven attempts, we are approaching... ;-)


Jokes apart, we are talking here about XPP3, a transitive dependency 
of XStream which is instead a declared dependency of Syncope (core).
We honestly did not consider at all such dependencies in L&N files, 
and there are quite some: what's the best practice for such cases? I 
see no option but using the maven dependency plugin in order to find 
all transitive dependencies and update L&N files consequently.


Is this correct? Basically, I feel this like breaking the Maven 
dependency resolution...

I must admit I'm a bit puzzled.

IMO, the L&N files should only contain the required licenses and notice 
for deps we are explicitely declaring in the poms, as they are part of 
the build. The fact that the built wars include transitive dependencies 
is a by-product of the build. In other words, if a 3rd party we include 
itself depends on some other libs, then it's this 3rd party L&N files to 
explicitely include the required L&N, not ours.


So XPP is not included by us, and should not be added in the N&L, as I 
initially (wrongly) thought.


Regarding the distinction between sources vs binary N&L files, my 
perception is that we should keep all the required (ie if it's 
explicitely asked by the 3rd party license) 3rd party Licenses, and 
nothing more. I do think we are pretty much ok here. Sebastian, if you 
have some libs that you think should not be present in the N&L files, 
could you name them ?


Thanks !


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Christian Grobmeier]

> Can you please let me know which license XPP uses? I could not find
> informatino in NOTICE and did not find a website which helped me. its
> necessary to clarify that as xpp3 is in the war file release. Once you 
> told
> me, I will give my +1

 Clearly missing in the N&L files.
>>>
>>> OK. Guess this should be fixed with a new attempt then.
>>
>>
>> Will do ASAP - guess we are trying to beat some record at Syncope: I know
>> that Flex made it in seven attempts, we are approaching... ;-)
>>
>> Jokes apart, we are talking here about XPP3, a transitive dependency of
>> XStream which is instead a declared dependency of Syncope (core).
>> We honestly did not consider at all such dependencies in L&N files, and
>> there are quite some: what's the best practice for such cases? I see no
>> option but using the maven dependency plugin in order to find all transitive
>> dependencies and update L&N files consequently.
>>
>> Is this correct? Basically, I feel this like breaking the Maven dependency
>> resolution...
>
> I must admit I'm a bit puzzled.
>
> IMO, the L&N files should only contain the required licenses and notice for
> deps we are explicitely declaring in the poms, as they are part of the
> build. The fact that the built wars include transitive dependencies is a
> by-product of the build. In other words, if a 3rd party we include itself
> depends on some other libs, then it's this 3rd party L&N files to
> explicitely include the required L&N, not ours.

When you put a war file on /dist containing that jar file, you are
releasing it. Imho it does not matter if it is transitive or what else
- at least it must be AL compatible. Others may correct me, but i
think this must be cared of.

> So XPP is not included by us, and should not be added in the N&L, as I
> initially (wrongly) thought.

http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
"All the licenses on all the files to be included within a package
should be included in the LICENSE document. "

It says to me, it does not matter who depends on what, it does only
matter whats inside your war.

Btw, I am still unsure which license XPP has. This is worse, because:
http://www.apache.org/dev/release.html#distribute-other-artifacts
"Again, these artifacts may be distributed only if they contain
LICENSE and NOTICE files"

This means for me, the XPP.jar can only be included in the war file
when it contains a LICENSE or a NOTICE. I just opened it, but there is
no such files. In fact it means I cannot see from the release what
license it actually contains.

Is there a chance you remove XPP or add license information for this artifact?

Cheers,
Christian

> Regarding the distinction between sources vs binary N&L files, my perception
> is that we should keep all the required (ie if it's explicitely asked by the
> 3rd party license) 3rd party Licenses, and nothing more. I do think we are
> pretty much ok here. Sebastian, if you have some libs that you think should
> not be present in the N&L files, could you name them ?


>
> Thanks !
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/15/12 10:34 AM, Christian Grobmeier a écrit :

Can you please let me know which license XPP uses? I could not find
informatino in NOTICE and did not find a website which helped me. its
necessary to clarify that as xpp3 is in the war file release. Once you told
me, I will give my +1

Clearly missing in the N&L files.

OK. Guess this should be fixed with a new attempt then.


Will do ASAP - guess we are trying to beat some record at Syncope: I know
that Flex made it in seven attempts, we are approaching... ;-)

Jokes apart, we are talking here about XPP3, a transitive dependency of
XStream which is instead a declared dependency of Syncope (core).
We honestly did not consider at all such dependencies in L&N files, and
there are quite some: what's the best practice for such cases? I see no
option but using the maven dependency plugin in order to find all transitive
dependencies and update L&N files consequently.

Is this correct? Basically, I feel this like breaking the Maven dependency
resolution...

I must admit I'm a bit puzzled.

IMO, the L&N files should only contain the required licenses and notice for
deps we are explicitely declaring in the poms, as they are part of the
build. The fact that the built wars include transitive dependencies is a
by-product of the build. In other words, if a 3rd party we include itself
depends on some other libs, then it's this 3rd party L&N files to
explicitely include the required L&N, not ours.

When you put a war file on /dist containing that jar file, you are
releasing it. Imho it does not matter if it is transitive or what else
- at least it must be AL compatible. Others may correct me, but i
think this must be cared of.
The point is that we don't vote binaries, we vote sources. Generated 
binaries are just by-products of the build.


That we distribute binaries is just for convenience.

Now, I do think that we should include into the N&L files the licenses 
for 3rd parties we *directly* include, but not those that are 
transivitely included. I may be wrong though. I understand your 
position, too.


It may be worthful to ask beside this thread what is the correct way to 
refer those transitive dependencies...





So XPP is not included by us, and should not be added in the N&L, as I
initially (wrongly) thought.

http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
"All the licenses on all the files to be included within a package
should be included in the LICENSE document. "
But as soon as we include the deps' licenses we include, even if they 
themselves include some 3rd party licenses, my understanding is that 
they already have done the job...


It says to me, it does not matter who depends on what, it does only
matter whats inside your war.

Btw, I am still unsure which license XPP has. This is worse, because:
http://www.apache.org/dev/release.html#distribute-other-artifacts
"Again, these artifacts may be distributed only if they contain
LICENSE and NOTICE files"


See on 
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/, 
unzip the 
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz 
tarball and check the included license.


"Indiana University Extreme! Lab Software License

Version 1.1.1

Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in
   the documentation and/or other materials provided with the distribution.

3. The end-user documentation included with the redistribution, if any,
   must include the following acknowledgment:

  "This product includes software developed by the Indiana University
  Extreme! Lab (http://www.extreme.indiana.edu/)."

Alternately, this acknowledgment may appear in the software itself,
if and wherever such third-party acknowledgments normally appear.

4. The names "Indiana Univeristy" and "Indiana Univeristy Extreme! Lab"
must not be used to endorse or promote products derived from this
software without prior written permission. For written permission,
please contact http://www.extreme.indiana.edu/.

5. Products derived from this software may not use "Indiana Univeristy"
name nor may "Indiana Univeristy" appear in their name, without prior
written permission of the Indiana University."



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Christian Grobmeier]

> The point is that we don't vote binaries, we vote sources. Generated
> binaries are just by-products of the build.
>
> That we distribute binaries is just for convenience.

which does not change anything imho

> Now, I do think that we should include into the N&L files the licenses for
> 3rd parties we *directly* include, but not those that are transivitely
> included. I may be wrong though. I understand your position, too.
>
> It may be worthful to ask beside this thread what is the correct way to
> refer those transitive dependencies...

+1

Did not know there were other positions actually.

>> http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
>> "All the licenses on all the files to be included within a package
>> should be included in the LICENSE document. "
>
> But as soon as we include the deps' licenses we include, even if they
> themselves include some 3rd party licenses, my understanding is that they
> already have done the job...

If they did it it. I have not opened all the files to be honest, but
is this something we can rely on (that they have done their job
proberly)?

>> It says to me, it does not matter who depends on what, it does only
>> matter whats inside your war.
>>
>> Btw, I am still unsure which license XPP has. This is worse, because:
>> http://www.apache.org/dev/release.html#distribute-other-artifacts
>> "Again, these artifacts may be distributed only if they contain
>> LICENSE and NOTICE files"
>
>
> See on
> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
> unzip the
> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
> tarball and check the included license.

Thanks! I opened the jar from the Syncope war, there was no info included.

Is that compatible? "Indiana University Extreme! Lab Software License"
I think its fine, but I am not very good with that boring stuff:
http://apache.org/legal/3party.html

Btw, this phrase is interesting:
"Redistributions in binary form must reproduce the above copyright notice"

This includes the provided war file. There is no copyright notice of
XPP and my guess is the license holders are not interested if we are
having it as transitive lib or not.

Cheers
Christian


> "Indiana University Extreme! Lab Software License
>
> Version 1.1.1
>
> Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
>
> 1. Redistributions of source code must retain the above copyright notice,
>   this list of conditions and the following disclaimer.
>
> 2. Redistributions in binary form must reproduce the above copyright
>   notice, this list of conditions and the following disclaimer in
>   the documentation and/or other materials provided with the distribution.
>
> 3. The end-user documentation included with the redistribution, if any,
>   must include the following acknowledgment:
>
>  "This product includes software developed by the Indiana University
>  Extreme! Lab (http://www.extreme.indiana.edu/)."
>
> Alternately, this acknowledgment may appear in the software itself,
> if and wherever such third-party acknowledgments normally appear.
>
> 4. The names "Indiana Univeristy" and "Indiana Univeristy Extreme! Lab"
> must not be used to endorse or promote products derived from this
> software without prior written permission. For written permission,
> please contact http://www.extreme.indiana.edu/.
>
> 5. Products derived from this software may not use "Indiana Univeristy"
> name nor may "Indiana Univeristy" appear in their name, without prior
> written permission of the Indiana University."
>
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Francesco Chicchiriccò]

Hi all,
as far as I've understood we are quite in an impasse here: is there any
quick way out?

I've performed some more analysis and I've come to the following findings:

1. XPP3 is pulled in by XStream (syncope-core and syncope-console WAR files)

[INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.2:compile
[INFO] |  \- xpp3:xpp3_min:jar:1.1.4c:compile

and by ApacheDS (syncope-build-tools WAR file)

[INFO] +- org.apache.directory.server:apacheds-all:jar:1.5.7:compile
[INFO] |  +- org.apache.directory.shared:shared-ldif:jar:0.9.19:compile
[INFO] |  \-
org.apache.directory.shared:shared-dsml-parser:jar:0.9.19:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile

XStream says that other XML parsers can be used (
http://xstream.codehaus.org/download.html#optional-deps), I don't know
about ApacheDS - but guess Emmanuel does.

2. The following are all the transitive dependencies currently not
mentioned in L&N files:

org.livetribe:livetribe-jsr223:jar:2.0.6
org.mybatis:mybatis:jar:3.0.6
xmlpull:xmlpull:jar:1.1.3.1
xpp3:xpp3_min:jar:1.1.4c / xpp3:xpp3:jar:1.1.4c
aopalliance:aopalliance:jar:1.0
asm:asm:jar:3.3.1
antlr:antlr:jar:2.7.7
dom4j:dom4j:jar:1.6.1
joda-time:joda-time:jar:2.0


Can we found a simple and shared way to assess what is the legal,
correct and complete, content of Syncope L&N files?
Is there any other ASF project distributing WAR files we can check?

If not: what if just include in L&N files all the deps reported above?
Is this harmful in any way?

Please help: we'd really like to cut out first release...

Best regards.

On 15/05/2012 11:36, Christian Grobmeier wrote:
>> The point is that we don't vote binaries, we vote sources. Generated
>> binaries are just by-products of the build.
>>
>> That we distribute binaries is just for convenience.
> which does not change anything imho
>
>> Now, I do think that we should include into the N&L files the licenses for
>> 3rd parties we *directly* include, but not those that are transivitely
>> included. I may be wrong though. I understand your position, too.
>>
>> It may be worthful to ask beside this thread what is the correct way to
>> refer those transitive dependencies...
> +1
>
> Did not know there were other positions actually.
>
>>> http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
>>> "All the licenses on all the files to be included within a package
>>> should be included in the LICENSE document. "
>> But as soon as we include the deps' licenses we include, even if they
>> themselves include some 3rd party licenses, my understanding is that they
>> already have done the job...
> If they did it it. I have not opened all the files to be honest, but
> is this something we can rely on (that they have done their job
> proberly)?
>
>>> It says to me, it does not matter who depends on what, it does only
>>> matter whats inside your war.
>>>
>>> Btw, I am still unsure which license XPP has. This is worse, because:
>>> http://www.apache.org/dev/release.html#distribute-other-artifacts
>>> "Again, these artifacts may be distributed only if they contain
>>> LICENSE and NOTICE files"
>>
>> See on
>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
>> unzip the
>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
>> tarball and check the included license.
> Thanks! I opened the jar from the Syncope war, there was no info included.
>
> Is that compatible? "Indiana University Extreme! Lab Software License"
> I think its fine, but I am not very good with that boring stuff:
> http://apache.org/legal/3party.html
>
> Btw, this phrase is interesting:
> "Redistributions in binary form must reproduce the above copyright notice"
>
> This includes the provided war file. There is no copyright notice of
> XPP and my guess is the license holders are not interested if we are
> having it as transitive lib or not.
-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/16/12 9:45 AM, Francesco Chicchiriccò a écrit :

Hi all,

Hi Francesco

as far as I've understood we are quite in an impasse here: is there any
quick way out?
Thinking twice about the third party components, I came to the 
conclusion that we should include the license of those requiring that it 
should be done, even if we have some transitive dependencies.


The reason is that if a direct 3rd party does not have a N&L containing 
transitive 3rd party, then those direct 3rd party are faulty. But 
because they are faulty does not mean we should also be (transitively) 
faulty !


That also means some of the ASF projects (including ApacheDS I'm working 
on !) have to double check their N&L files, something I'll do asap.


I'll be a bit busy the next 4 days, but I'll try to get a clear decision 
about this problem before next week, as it may impact many other projects.


Thanks !


I've performed some more analysis and I've come to the following findings:

1. XPP3 is pulled in by XStream (syncope-core and syncope-console WAR files)

[INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.2:compile
[INFO] |  \- xpp3:xpp3_min:jar:1.1.4c:compile

and by ApacheDS (syncope-build-tools WAR file)

[INFO] +- org.apache.directory.server:apacheds-all:jar:1.5.7:compile
[INFO] |  +- org.apache.directory.shared:shared-ldif:jar:0.9.19:compile
[INFO] |  \-
org.apache.directory.shared:shared-dsml-parser:jar:0.9.19:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile

XStream says that other XML parsers can be used (
http://xstream.codehaus.org/download.html#optional-deps), I don't know
about ApacheDS - but guess Emmanuel does.

2. The following are all the transitive dependencies currently not
mentioned in L&N files:

org.livetribe:livetribe-jsr223:jar:2.0.6
org.mybatis:mybatis:jar:3.0.6
xmlpull:xmlpull:jar:1.1.3.1
xpp3:xpp3_min:jar:1.1.4c / xpp3:xpp3:jar:1.1.4c
aopalliance:aopalliance:jar:1.0
asm:asm:jar:3.3.1
antlr:antlr:jar:2.7.7
dom4j:dom4j:jar:1.6.1
joda-time:joda-time:jar:2.0


Can we found a simple and shared way to assess what is the legal,
correct and complete, content of Syncope L&N files?
Is there any other ASF project distributing WAR files we can check?

If not: what if just include in L&N files all the deps reported above?
Is this harmful in any way?

Please help: we'd really like to cut out first release...

Best regards.

On 15/05/2012 11:36, Christian Grobmeier wrote:

The point is that we don't vote binaries, we vote sources. Generated
binaries are just by-products of the build.

That we distribute binaries is just for convenience.

which does not change anything imho


Now, I do think that we should include into the N&L files the licenses for
3rd parties we *directly* include, but not those that are transivitely
included. I may be wrong though. I understand your position, too.

It may be worthful to ask beside this thread what is the correct way to
refer those transitive dependencies...

+1

Did not know there were other positions actually.


http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
"All the licenses on all the files to be included within a package
should be included in the LICENSE document. "

But as soon as we include the deps' licenses we include, even if they
themselves include some 3rd party licenses, my understanding is that they
already have done the job...

If they did it it. I have not opened all the files to be honest, but
is this something we can rely on (that they have done their job
proberly)?


It says to me, it does not matter who depends on what, it does only
matter whats inside your war.

Btw, I am still unsure which license XPP has. This is worse, because:
http://www.apache.org/dev/release.html#distribute-other-artifacts
"Again, these artifacts may be distributed only if they contain
LICENSE and NOTICE files"

See on
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
unzip the
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
tarball and check the included license.

Thanks! I opened the jar from the Syncope war, there was no info included.

Is that compatible? "Indiana University Extreme! Lab Software License"
I think its fine, but I am not very good with that boring stuff:
http://apache.org/legal/3party.html

Btw, this phrase is interesting:
"Redistributions in binary form must reproduce the above copyright notice"

This includes the provided war file. There is no copyright notice of
XPP and my guess is the license holders are not interested if we are
having it as transitive lib or not.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Simone Tripodi]

Hi all,

apologize for the lack of participation but I'm in the middle of a
very busy month :S

> Is that compatible? "Indiana University Extreme! Lab Software License"
> I think its fine, but I am not very good with that boring stuff:
> http://apache.org/legal/3party.html

It is, and looks like other ASF projects already include it, such as
Apache Solr[1]. Also Apache Maven uses it as a transitive dependency,
being shipped with the Modello project that generates an XPP parser
for the Maven model.

SO, I'd consider the XPP license issue resolved - of course at Syncope
we need to include it in the LICENSE file contained in the war file
that redistribute it.

Thanks for the feedbacks and sorry once again for the lack of participation

best,
-Simo

[1] 
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200604.mbox/%3cc68e39170604181358p38224f75q352c0bec18ff1...@mail.gmail.com%3E

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, May 15, 2012 at 11:36 AM, Christian Grobmeier
 wrote:
>> The point is that we don't vote binaries, we vote sources. Generated
>> binaries are just by-products of the build.
>>
>> That we distribute binaries is just for convenience.
>
> which does not change anything imho
>
>> Now, I do think that we should include into the N&L files the licenses for
>> 3rd parties we *directly* include, but not those that are transivitely
>> included. I may be wrong though. I understand your position, too.
>>
>> It may be worthful to ask beside this thread what is the correct way to
>> refer those transitive dependencies...
>
> +1
>
> Did not know there were other positions actually.
>
>>> http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
>>> "All the licenses on all the files to be included within a package
>>> should be included in the LICENSE document. "
>>
>> But as soon as we include the deps' licenses we include, even if they
>> themselves include some 3rd party licenses, my understanding is that they
>> already have done the job...
>
> If they did it it. I have not opened all the files to be honest, but
> is this something we can rely on (that they have done their job
> proberly)?
>
>>> It says to me, it does not matter who depends on what, it does only
>>> matter whats inside your war.
>>>
>>> Btw, I am still unsure which license XPP has. This is worse, because:
>>> http://www.apache.org/dev/release.html#distribute-other-artifacts
>>> "Again, these artifacts may be distributed only if they contain
>>> LICENSE and NOTICE files"
>>
>>
>> See on
>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
>> unzip the
>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
>> tarball and check the included license.
>
> Thanks! I opened the jar from the Syncope war, there was no info included.
>
> Is that compatible? "Indiana University Extreme! Lab Software License"
> I think its fine, but I am not very good with that boring stuff:
> http://apache.org/legal/3party.html
>
> Btw, this phrase is interesting:
> "Redistributions in binary form must reproduce the above copyright notice"
>
> This includes the provided war file. There is no copyright notice of
> XPP and my guess is the license holders are not interested if we are
> having it as transitive lib or not.
>
> Cheers
> Christian
>
>
>> "Indiana University Extreme! Lab Software License
>>
>> Version 1.1.1
>>
>> Copyright (c) 2002 Extreme! Lab, Indiana University. All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions
>> are met:
>>
>> 1. Redistributions of source code must retain the above copyright notice,
>>   this list of conditions and the following disclaimer.
>>
>> 2. Redistributions in binary form must reproduce the above copyright
>>   notice, this list of conditions and the following disclaimer in
>>   the documentation and/or other materials provided with the distribution.
>>
>> 3. The end-user documentation included with the redistribution, if any,
>>   must include the following acknowledgment:
>>
>>  "This product includes software developed by the Indiana University
>>  Extreme! Lab (http://www.extreme.indiana.edu/)."
>>
>> Alternately, this acknowledgment may appear in the software itself,
>> if and wherever such third-party acknowledgments normally appear.
>>
>> 4. The names "Indiana Univeristy" and "Indiana Univeristy Extreme! Lab"
>> must not be used to endorse or promote products derived from this
>> software without prior written permission. For written permission,
>> please contact http://www.extreme.indiana.edu/.
>>
>> 5. Products derived from this software may not use "Indiana Univeristy"
>> name nor may "Indiana Univeristy" appear in their name, without prior
>> written permission of the Indiana University."
>>
>>
>>
>>
>> --
>> R

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Simone Tripodi]

Hi again,

after a little research:

> org.livetribe:livetribe-jsr223:jar:2.0.6

ASL2.0 license, see its parent:


> org.mybatis:mybatis:jar:3.0.6

ASL2.0 


> xmlpull:xmlpull:jar:1.1.3.1

Public domain 


> xpp3:xpp3_min:jar:1.1.4c / xpp3:xpp3:jar:1.1.4c

already discussed

> aopalliance:aopalliance:jar:1.0

public domain 


> asm:asm:jar:3.3.1

BSD 

category A 

> antlr:antlr:jar:2.7.7

BSD  category A


> dom4j:dom4j:jar:1.6.1

BSD variant 


Category A as shown as 

> joda-time:joda-time:jar:2.0

ASL2.0

So, at that point, we should just complete the legal files and I
consider the dependency inclusion issue as resolved.

Best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, May 16, 2012 at 9:45 AM, Francesco Chicchiriccò
 wrote:
> Hi all,
> as far as I've understood we are quite in an impasse here: is there any
> quick way out?
>
> I've performed some more analysis and I've come to the following findings:
>
> 1. XPP3 is pulled in by XStream (syncope-core and syncope-console WAR files)
>
> [INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.2:compile
> [INFO] |  \- xpp3:xpp3_min:jar:1.1.4c:compile
>
> and by ApacheDS (syncope-build-tools WAR file)
>
> [INFO] +- org.apache.directory.server:apacheds-all:jar:1.5.7:compile
> [INFO] |  +- org.apache.directory.shared:shared-ldif:jar:0.9.19:compile
> [INFO] |  \-
> org.apache.directory.shared:shared-dsml-parser:jar:0.9.19:compile
> [INFO] |     \- xpp3:xpp3:jar:1.1.4c:compile
>
> XStream says that other XML parsers can be used (
> http://xstream.codehaus.org/download.html#optional-deps), I don't know
> about ApacheDS - but guess Emmanuel does.
>
> 2. The following are all the transitive dependencies currently not
> mentioned in L&N files:
>
> org.livetribe:livetribe-jsr223:jar:2.0.6
> org.mybatis:mybatis:jar:3.0.6
> xmlpull:xmlpull:jar:1.1.3.1
> xpp3:xpp3_min:jar:1.1.4c / xpp3:xpp3:jar:1.1.4c
> aopalliance:aopalliance:jar:1.0
> asm:asm:jar:3.3.1
> antlr:antlr:jar:2.7.7
> dom4j:dom4j:jar:1.6.1
> joda-time:joda-time:jar:2.0
>
>
> Can we found a simple and shared way to assess what is the legal,
> correct and complete, content of Syncope L&N files?
> Is there any other ASF project distributing WAR files we can check?
>
> If not: what if just include in L&N files all the deps reported above?
> Is this harmful in any way?
>
> Please help: we'd really like to cut out first release...
>
> Best regards.
>
> On 15/05/2012 11:36, Christian Grobmeier wrote:
>>> The point is that we don't vote binaries, we vote sources. Generated
>>> binaries are just by-products of the build.
>>>
>>> That we distribute binaries is just for convenience.
>> which does not change anything imho
>>
>>> Now, I do think that we should include into the N&L files the licenses for
>>> 3rd parties we *directly* include, but not those that are transivitely
>>> included. I may be wrong though. I understand your position, too.
>>>
>>> It may be worthful to ask beside this thread what is the correct way to
>>> refer those transitive dependencies...
>> +1
>>
>> Did not know there were other positions actually.
>>
 http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
 "All the licenses on all the files to be included within a package
 should be included in the LICENSE document. "
>>> But as soon as we include the deps' licenses we include, even if they
>>> themselves include some 3rd party licenses, my understanding is that they
>>> already have done the job...
>> If they did it it. I have not opened all the files to be honest, but
>> is this something we can rely on (that they have done their job
>> proberly)?
>>
 It says to me, it does not matter who depends on what, it does only
 matter whats inside your war.

 Btw, I am still unsure which license XPP has. This is worse, because:
 http://www.apache.org/dev/release.html#distribute-other-artifacts
 "Again, these artifacts may be distributed only if they contain
 LICENSE and NOTICE files"
>>>
>>> See on
>>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
>>> unzip the
>>> http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
>>> tarball and check the inc