subject:"\[VOTE\] Release Apache Groovy 2.4.4\-incubating"

That’s why it would be great to have Justin write up a “This is how I test
a release” page somewhere that explains how he goes about it.  Mentors and
release managers should be able to generate the same data sets and try to
interpret it in the same way early in the release process.  You still may
not catch everything Justin will, but hopefully you will catch enough that
any issues found can be rolled to the next release.

-Alex

On 7/17/15, 12:28 AM, Cédric Champeau cedric.champ...@gmail.com wrote:

Thanks Justin. We had read that document, but even reading the binary
section, it wasn't clear that source and binary LN had to be
different. I would suggest to update the page to make it clear that
These additional dependencies must be accounted for in LICENSE and
NOTICE. doesn't mean that the LICENSE and NOTICE files need to be
updated to include those additional dependencies, but that *separate*
LN files *must* be issued including these additional dependencies.

2015-07-17 1:02 GMT+02:00 Justin Mclean justinmcl...@me.com:
 Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...

 The “tools” I use generally make a bit of noise and require some
interpretation / filtering so I’m not sure they could be automated
cleanly. One thing rat might be able to do that I don’t think it
currently does is detect files containing more than one license header.

 Best advice I can give is follow this guide [1] and use it when
reviewing releases.

 Thanks,
 Justin

 1. http://www.apache.org/dev/licensing-howto.html
 -
 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: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating



On 7/17/15, 3:09 AM, Emmanuel Lécharny elecha...@gmail.com wrote:

that would not change anything. What makes things complicated is
 points of human interaction in the middle of the release process. That
 won't be different with a better tuned CI
I'm puzzled. Cédric said in a previous mail that before being an Apache
podling, releasing was just a matter of a couple of hours and very few
human interaction. What makes it so more complex in an Apache
environement ?

From my personal experience, before Apache you could ship anything you
want and if someone found an IP issue, you would fix it after you shipped.
 At Apache, the rules are more stringent (no binaries, LN in jars), and
you get shamed for not catching stuff when there is no clear process for
catching that stuff.

In the end, it is necessary since clean IP is important to Apache and your
customers, but it isn’t efficient while you go through the cleaning up
process, especially in the incubator if your mentors don’t apply the same
level of scrutiny that will occur when the greater IPMC does its scrutiny.
 Our mentors never scrutinized our binaries and we are only now as a TLP
cleaning those up.

And if folks are interested in other stories about release process
inefficiency, I will write to some Cordova folks off-list and ask them to
add their thoughts to this thread.

-Alex


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau


 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem

First of all, the fact of rolling back a release already takes time.
There's much more involved than a couple of artifacts uploaded on
dist.apache.org. We are very picky at quality, and a release is issued
from a CI server, which automates all tasks that are subject to human
errors. It involves creating a release branch, tagging, uploading
Maven artifacts to Artifactory, uploading the distribution to Bintray,
synchronizing to Maven Central, etc... What we did for the new Apache
release process is cut this into small steps that introduce potential
human errors. And basically, we have staging areas for the
source/distribution artifacts (what you vote on), and staging area for
the complete set of artifacts (Groovy produces more than 270 jar
artifacts). Rolling back, as I said, implies several steps, including
closing those staging repos, removing the tags, branches, ... And due
to some restrictions of the Apache infrastructure, we have a complex
setup (we need to push the tags on personal branches from GitHub, then
push them to Apache Git, as explained in our release document [1]).

So, rolling back a release is not cheap. And then, you have to release
again. And releasing, for the same reasons, is far from being cheap. I
am the first one really annoyed by this as the release manager,
because as I explained when joining Apache, I spent numerous hours
polishing the Groovy release process, and releasing was a single click
button. I could release 2 branches of Groovy in a couple of hours.
*That* was cheap. For this release, it took me several hours and a lot
of manual steps are involved. I know most of you are used to release
from your own computers. That simplifies things a little, but that's
not a guarantee of quality, in the sense that human errors are
possible: you could release from a local source tree which is not
exactly what the source reference is (so produce a correct source zip
but that would differ from what the real source is), you could have
dependencies in your local Maven repo which wouldn't be found
otherwise (caching problem), you could build on a non-approved JDK
(our CI builds do it from JDKs which were approved to be bug-free by
the team, in particular with invokedynamic...), ... We don't want to
do that.

In addition, fixing this LN issue is not cheap either. First of all,
we were not aware that the source and binary versions had to be
different (and it seems that our mentors missed it for the first RC we
tried). Second, we are still working on the issue, because we want to
avoid being downvoted again, so it implies a lot of new sanity checks.
Paul is doing that, but that's all on personal time of a distributed
team, so no, we wouldn't have released in time. And there were already
changes to the codebase after the rc was issued (development doesn't
stop during voting), so either we would have to fork the RC branch,
release from it and add new burden to our release process, or we would
have to revote for everything including sources.

Last but not least, I would also say that none of us was aware that a
shortened vote period was possible. And since at Apache, everybody
seem to have an opinion on everything, we would have taken the risk of
being downvoted for not giving enough time to vote. That said, given
that our vote on dev@ passed because we gave enough time to our
voters. With 24h voting period we wwouldn't have had enough votes.
Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
should vote. Otherwise it means that the artifacts that were voted on
dev@ are different from those voted on general@. And that's a bad
thing IMHO.

To my mind, incubating is about learning how this works, and I think
we're doing a reasonable job in that area. If you put the entry level
too high, then you just discourage people to contribute.


 I just don't understand why you didn't entertain that as an option. Personally
 I would've made myself available to cast my vote under very compressed
 schedule if you actually ASKED for it.

 Not releasing would not have been serious, and we could have missed
 the short timeframe we have given the vacations of the team.
 It's also unfair because we took *very seriously* the comments for the
 first attempt of the release, a few weeks ago, and fixed *all of them*
 (and did even more than what you asked us to do).
 So I think our community deserved that release more than having the
 perfect LN files (especially because as we said, the License file
 contains more, but not less, than required), and as
 Paul said, all jars produces *do* have them.

 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

 I sincerely hope my

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau

Thanks Justin. We had read that document, but even reading the binary
section, it wasn't clear that source and binary LN had to be
different. I would suggest to update the page to make it clear that
These additional dependencies must be accounted for in LICENSE and
NOTICE. doesn't mean that the LICENSE and NOTICE files need to be
updated to include those additional dependencies, but that *separate*
LN files *must* be issued including these additional dependencies.

2015-07-17 1:02 GMT+02:00 Justin Mclean justinmcl...@me.com:
 Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...

 The “tools” I use generally make a bit of noise and require some 
 interpretation / filtering so I’m not sure they could be automated cleanly. 
 One thing rat might be able to do that I don’t think it currently does is 
 detect files containing more than one license header.

 Best advice I can give is follow this guide [1] and use it when reviewing 
 releases.

 Thanks,
 Justin

 1. http://www.apache.org/dev/licensing-howto.html
 -
 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: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 17/07/15 01:02, Justin Mclean a écrit :
 Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...
 The “tools” I use generally make a bit of noise and require some 
 interpretation / filtering so I’m not sure they could be automated cleanly. 
 One thing rat might be able to do that I don’t think it currently does is 
 detect files containing more than one license header.

 Best advice I can give is follow this guide [1] and use it when reviewing 
 releases.

Thank Justin !


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 17/07/15 09:21, Cédric Champeau a écrit :
 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem
 First of all, the fact of rolling back a release already takes time.
 There's much more involved than a couple of artifacts uploaded on
 dist.apache.org. We are very picky at quality, and a release is issued
 from a CI server, which automates all tasks that are subject to human
 errors. It involves creating a release branch, tagging, uploading
 Maven artifacts to Artifactory, uploading the distribution to Bintray,
 synchronizing to Maven Central, etc... What we did for the new Apache
 release process is cut this into small steps that introduce potential
 human errors. And basically, we have staging areas for the
 source/distribution artifacts (what you vote on), and staging area for
 the complete set of artifacts (Groovy produces more than 270 jar
 artifacts). Rolling back, as I said, implies several steps, including
 closing those staging repos, removing the tags, branches, ... And due
 to some restrictions of the Apache infrastructure, we have a complex
 setup (we need to push the tags on personal branches from GitHub, then
 push them to Apache Git, as explained in our release document [1]).

 So, rolling back a release is not cheap. And then, you have to release
 again. And releasing, for the same reasons, is far from being cheap. I
 am the first one really annoyed by this as the release manager,
 because as I explained when joining Apache, I spent numerous hours
 polishing the Groovy release process, and releasing was a single click
 button. I could release 2 branches of Groovy in a couple of hours.
 *That* was cheap. For this release, it took me several hours and a lot
 of manual steps are involved. I know most of you are used to release
 from your own computers. That simplifies things a little, but that's
 not a guarantee of quality, in the sense that human errors are
 possible: you could release from a local source tree which is not
 exactly what the source reference is (so produce a correct source zip
 but that would differ from what the real source is), you could have
 dependencies in your local Maven repo which wouldn't be found
 otherwise (caching problem), you could build on a non-approved JDK
 (our CI builds do it from JDKs which were approved to be bug-free by
 the team, in particular with invokedynamic...), ... We don't want to
 do that.

 In addition, fixing this LN issue is not cheap either. First of all,
 we were not aware that the source and binary versions had to be
 different (and it seems that our mentors missed it for the first RC we
 tried). Second, we are still working on the issue, because we want to
 avoid being downvoted again, so it implies a lot of new sanity checks.
 Paul is doing that, but that's all on personal time of a distributed
 team, so no, we wouldn't have released in time. And there were already
 changes to the codebase after the rc was issued (development doesn't
 stop during voting), so either we would have to fork the RC branch,
 release from it and add new burden to our release process, or we would
 have to revote for everything including sources.

 Last but not least, I would also say that none of us was aware that a
 shortened vote period was possible. And since at Apache, everybody
 seem to have an opinion on everything, we would have taken the risk of
 being downvoted for not giving enough time to vote. That said, given
 that our vote on dev@ passed because we gave enough time to our
 voters. With 24h voting period we wwouldn't have had enough votes.
 Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
 should vote. Otherwise it means that the artifacts that were voted on
 dev@ are different from those voted on general@. And that's a bad
 thing IMHO.

 To my mind, incubating is about learning how this works, and I think
 we're doing a reasonable job in that area. If you put the entry level
 too high, then you just discourage people to contribute.

ALl of this makes perfect sense to me.

Now, I'm a bit scared : why the hell can't we make it easier to cut a
release at Apache for this project ? I mean, the infrastructure should
not be a limitation here : we do have a CI, we most certainly can tune
it to fit Groovy.

I suggest we discuss this matter instead of arguing about why this
release was not perfect (we all agreed on that already) The critical
point is that it should not take hours to cut a release nor to rollback
it. That would be a constructive discussion.

I'd like to remember everyone that each project is quite able to define
the way they do things, as soon as they fits in the Apache process,
which is not that rigid. At this point, we may dedicate some time with
mentors, someone from infra and obviously the

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 17/07/15 09:28, Cédric Champeau a écrit :
 Thanks Justin. We had read that document, but even reading the binary
 section, it wasn't clear that source and binary LN had to be
 different. 

Guiding Principle :

The |LICENSE| and |NOTICE| files must *exactly* represent the contents
of the distribution they reside in.



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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau

Realizing I forgot the link to the release doc (WIP):
http://groovy-lang.org/wiki/incubation-release-process.html

2015-07-17 9:31 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:
 Le 17/07/15 09:21, Cédric Champeau a écrit :
 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem
 First of all, the fact of rolling back a release already takes time.
 There's much more involved than a couple of artifacts uploaded on
 dist.apache.org. We are very picky at quality, and a release is issued
 from a CI server, which automates all tasks that are subject to human
 errors. It involves creating a release branch, tagging, uploading
 Maven artifacts to Artifactory, uploading the distribution to Bintray,
 synchronizing to Maven Central, etc... What we did for the new Apache
 release process is cut this into small steps that introduce potential
 human errors. And basically, we have staging areas for the
 source/distribution artifacts (what you vote on), and staging area for
 the complete set of artifacts (Groovy produces more than 270 jar
 artifacts). Rolling back, as I said, implies several steps, including
 closing those staging repos, removing the tags, branches, ... And due
 to some restrictions of the Apache infrastructure, we have a complex
 setup (we need to push the tags on personal branches from GitHub, then
 push them to Apache Git, as explained in our release document [1]).

 So, rolling back a release is not cheap. And then, you have to release
 again. And releasing, for the same reasons, is far from being cheap. I
 am the first one really annoyed by this as the release manager,
 because as I explained when joining Apache, I spent numerous hours
 polishing the Groovy release process, and releasing was a single click
 button. I could release 2 branches of Groovy in a couple of hours.
 *That* was cheap. For this release, it took me several hours and a lot
 of manual steps are involved. I know most of you are used to release
 from your own computers. That simplifies things a little, but that's
 not a guarantee of quality, in the sense that human errors are
 possible: you could release from a local source tree which is not
 exactly what the source reference is (so produce a correct source zip
 but that would differ from what the real source is), you could have
 dependencies in your local Maven repo which wouldn't be found
 otherwise (caching problem), you could build on a non-approved JDK
 (our CI builds do it from JDKs which were approved to be bug-free by
 the team, in particular with invokedynamic...), ... We don't want to
 do that.

 In addition, fixing this LN issue is not cheap either. First of all,
 we were not aware that the source and binary versions had to be
 different (and it seems that our mentors missed it for the first RC we
 tried). Second, we are still working on the issue, because we want to
 avoid being downvoted again, so it implies a lot of new sanity checks.
 Paul is doing that, but that's all on personal time of a distributed
 team, so no, we wouldn't have released in time. And there were already
 changes to the codebase after the rc was issued (development doesn't
 stop during voting), so either we would have to fork the RC branch,
 release from it and add new burden to our release process, or we would
 have to revote for everything including sources.

 Last but not least, I would also say that none of us was aware that a
 shortened vote period was possible. And since at Apache, everybody
 seem to have an opinion on everything, we would have taken the risk of
 being downvoted for not giving enough time to vote. That said, given
 that our vote on dev@ passed because we gave enough time to our
 voters. With 24h voting period we wwouldn't have had enough votes.
 Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
 should vote. Otherwise it means that the artifacts that were voted on
 dev@ are different from those voted on general@. And that's a bad
 thing IMHO.

 To my mind, incubating is about learning how this works, and I think
 we're doing a reasonable job in that area. If you put the entry level
 too high, then you just discourage people to contribute.

 ALl of this makes perfect sense to me.

 Now, I'm a bit scared : why the hell can't we make it easier to cut a
 release at Apache for this project ? I mean, the infrastructure should
 not be a limitation here : we do have a CI, we most certainly can tune
 it to fit Groovy.

 I suggest we discuss this matter instead of arguing about why this
 release was not perfect (we all agreed on that already) The critical
 point is that it should not take hours to cut a release nor to rollback
 it. That would be a constructive discussion.

 I'd like to remember everyone that each project is quite able to

Re: [VOTE] Release Apache Groovy 2.4.4-incubating



On 7/17/15, 3:05 AM, Paul King pa...@asert.com.au wrote:

On 13/07/2015 10:12 PM, Justin Mclean wrote:
 [...snip...]
 - Short form of bundled licenses are preferred to long version
 [...snip...]

One thing I forgot to ask. What does short form mean? We can have
a URL link to the license text? Or something else?

IIRC, from [1], instead of copying whole licenses into your LICENSE file,
you can use something like:

  This product bundles SuperWidget 1.2.3, which is available under a
  3-clause BSD license.  For details, see deps/superwidget/.


and have the license downloaded and bundled with the bits where possible.

-Alex

[1] http://www.apache.org/dev/licensing-howto.html


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating



On 7/17/15, 7:05 AM, Guillaume Laforge glafo...@gmail.com wrote:

On Fri, Jul 17, 2015 at 3:59 PM, Alex Harui aha...@adobe.com wrote:

 [...]
 And if folks are interested in other stories about release process
 inefficiency, I will write to some Cordova folks off-list and ask them
to
 add their thoughts to this thread.


Hmm this might be interesting, to see if there are some commonalities
between theirs and our problems with our now sub-par release process.
Apache, for me, should thrive for the best release quality process, but
we've had to regress in that area to comply with the Apache expectations
(with the various manual steps, etc), and I'm hopeful we can further
improve such process for more automation, less human intervention, shorter
release times, etc.

I don’t know how IP checking was done in the past for Groovy, but I don’t
know of a way to automate comparing the format of Apache LN against the
contents of the packages, so I’ve resigned myself to some level of human
involvement.  I just hope those with the best techniques for finding
issues will share them.

It was pointed out to me that this is a pretty big list, so instead of
having the Cordova folks join this thread and re-hash the past
discussions, I’ll supply a link to a public archive of one thread.  There
are a couple of other threads on non-public lists.  And you can probably
drop in on the Cordova dev list and have them get involved on your dev
list.

http://s.apache.org/kvO


-Alex

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Paul King


On 17/07/2015 8:09 PM, Emmanuel Lécharny wrote:

Le 17/07/15 12:02, Jochen Theodorou a écrit :

Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
[...]

Now, I'm a bit scared : why the hell can't we make it easier to cut a
release at Apache for this project ? I mean, the infrastructure should
not be a limitation here : we do have a CI, we most certainly can tune
it to fit Groovy.


that would not change anything. What makes things complicated is
points of human interaction in the middle of the release process. That
won't be different with a better tuned CI

I'm puzzled. Cédric said in a previous mail that before being an Apache
podling, releasing was just a matter of a couple of hours and very few
human interaction. What makes it so more complex in an Apache environement ?


Cédric already explained in other emails and in his release process
documentation some of the nitty gritty details so I won't repeat that.
The tl;dr version is that we had a fully automated process that took
care of many of the tricky aspects of a Groovy release (we have to
build on recent JDK versions to bake in invoke dynamic behavior but
still run on old JDK versions and avoid the many JDK versions with
early buggy invoke dynamic support). Our previous setup used
machines (outside ASF) and software (Team City) that don't fit the
Apache mold. We have broken our original process into pieces so that
we can stop it (e.g. for voting) half-way through and so that we have
artifacts that we can potentially feed back into existing Apache
processes. Over time we could retrofit more of the pieces that don't
fit the current mold into more Apache friendly variants but we aren't
in a position to down tools for three months and change everything now.
Our users expect new features and new releases and we must balance
the time we spend on sideways or backwards movements on the
infrastructure side of things.

Cheers, Paul.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Jochen Theodorou


Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
[...]

Now, I'm a bit scared : why the hell can't we make it easier to cut a
release at Apache for this project ? I mean, the infrastructure should
not be a limitation here : we do have a CI, we most certainly can tune
it to fit Groovy.


that would not change anything. What makes things complicated is points 
of human interaction in the middle of the release process. That won't be 
different with a better tuned CI


[...]

I'd like to remember everyone that each project is quite able to define
the way they do things, as soon as they fits in the Apache process,
which is not that rigid.


Not as rigid... on this list it has been made clear, that anything that 
is even remotely something like a release is to be handled as such. 
Furthermore, it was made clear, that third parties are supposed to be 
prevented to provide their own releases, even if it means to use the 
brand to force things. Even maven central is seen as evil in that sense. 
And of course any apache member is not allowed to do some kind f release 
on its own. This is just to give an example of the things that accompany 
the process. And those are rigid already.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Paul King


On 13/07/2015 10:12 PM, Justin Mclean wrote:

[...snip...]
- Short form of bundled licenses are preferred to long version
[...snip...]


One thing I forgot to ask. What does short form mean? We can have
a URL link to the license text? Or something else?

Thanks, Paul.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 17/07/15 12:02, Jochen Theodorou a écrit :
 Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
 [...]
 Now, I'm a bit scared : why the hell can't we make it easier to cut a
 release at Apache for this project ? I mean, the infrastructure should
 not be a limitation here : we do have a CI, we most certainly can tune
 it to fit Groovy.

 that would not change anything. What makes things complicated is
 points of human interaction in the middle of the release process. That
 won't be different with a better tuned CI
I'm puzzled. Cédric said in a previous mail that before being an Apache
podling, releasing was just a matter of a couple of hours and very few
human interaction. What makes it so more complex in an Apache environement ?



 [...]
 I'd like to remember everyone that each project is quite able to define
 the way they do things, as soon as they fits in the Apache process,
 which is not that rigid.

 Not as rigid... on this list it has been made clear, that anything
 that is even remotely something like a release is to be handled as
 such. Furthermore, it was made clear, that third parties are supposed
 to be prevented to provide their own releases, even if it means to use
 the brand to force things. Even maven central is seen as evil in that
 sense. And of course any apache member is not allowed to do some kind
 f release on its own. This is just to give an example of the things
 that accompany the process. And those are rigid already.

Let me be clear : I'm cutting releases for years on Apache projects. The
process is quite simple :
- I use Maven *locally*. When the release is completed, I just have to
close the staging repository on Nexus, and push the packages on dist.
Nothing that can't be done automatically, except closing the repository
- last, not least, I stage the release on nexus.

Tell me what's different for Groovy, that requires much more manual
processing ?



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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Guillaume Laforge

I'm particularly interested in the build / release aspect here. What were
the Cordova struggles.
For the LN, that's indeed a human task that has to be done once (plus some
Rat  automated checks)
What I'd like is to be able to automate the release as much as possible,
with the least error prone human interaction.
Le 17 juil. 2015 18:21, Alex Harui aha...@adobe.com a écrit :



 On 7/17/15, 7:05 AM, Guillaume Laforge glafo...@gmail.com wrote:

 On Fri, Jul 17, 2015 at 3:59 PM, Alex Harui aha...@adobe.com wrote:
 
  [...]
  And if folks are interested in other stories about release process
  inefficiency, I will write to some Cordova folks off-list and ask them
 to
  add their thoughts to this thread.
 
 
 Hmm this might be interesting, to see if there are some commonalities
 between theirs and our problems with our now sub-par release process.
 Apache, for me, should thrive for the best release quality process, but
 we've had to regress in that area to comply with the Apache expectations
 (with the various manual steps, etc), and I'm hopeful we can further
 improve such process for more automation, less human intervention, shorter
 release times, etc.

 I don’t know how IP checking was done in the past for Groovy, but I don’t
 know of a way to automate comparing the format of Apache LN against the
 contents of the packages, so I’ve resigned myself to some level of human
 involvement.  I just hope those with the best techniques for finding
 issues will share them.

 It was pointed out to me that this is a pretty big list, so instead of
 having the Cordova folks join this thread and re-hash the past
 discussions, I’ll supply a link to a public archive of one thread.  There
 are a couple of other threads on non-public lists.  And you can probably
 drop in on the Cordova dev list and have them get involved on your dev
 list.

 http://s.apache.org/kvO


 -Alex

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Jochen Theodorou


Am 16.07.2015 18:49, schrieb Roman Shaposhnik:

On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com wrote:

Le 16/07/15 10:41, Justin Mclean a écrit :

Hi,


This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
binding votes.

If you read carefully I think you find there were 3 -1 votes on the binary 
releases.


True. I -1 the binary release. Interesting case : should we release if
we have as many -1 than +1 ?


Personally, I'm disappointed in the podling for not taking
care of feedback that seems really easy to take care of.


but not in time, because the apache process is too slow. What so you 
prefer? A unfixed zero-day vulnerability reported against an apache 
project, or a podling release which is not 100% according to strict 
apache views. We are not a TLP yet after all.


And this release is a special case.

That security fix is the only reason why we did want release ASAP. We 
own it to the community to be able to react to such things fast. And I 
really would not like to explain to our users that we could not do a 
release, because of a minor issue. If the apache process would not be so 
slow, we would of course have made it different. But waiting another 6 
days, while some will be in holidays already, would have been a problem.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread jan i

On Thursday, July 16, 2015, Jochen Theodorou blackd...@gmx.org wrote:

 Am 16.07.2015 18:49, schrieb Roman Shaposhnik:

 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com
 wrote:

 Le 16/07/15 10:41, Justin Mclean a écrit :

 Hi,

  This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.

 If you read carefully I think you find there were 3 -1 votes on the
 binary releases.


 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?


 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.


 but not in time, because the apache process is too slow. What so you
 prefer? A unfixed zero-day vulnerability reported against an apache
 project, or a podling release which is not 100% according to strict apache
 views. We are not a TLP yet after all.

 And this release is a special case.

 That security fix is the only reason why we did want release ASAP. We own
 it to the community to be able to react to such things fast. And I really
 would not like to explain to our users that we could not do a release,
 because of a minor issue. If the apache process would not be so slow, we
 would of course have made it different. But waiting another 6 days, while
 some will be in holidays already, would have been a problem.

Security problems must be dealt with as fast as possible even if it means
twisting the apache process.

rgds
jan i


 bye blackdrag

 --
 Jochen blackdrag Theodorou
 blog: http://blackdragsview.blogspot.com/


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



-- 
Sent from My iPad, sorry for any misspellings.

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 16/07/15 18:49, Roman Shaposhnik a écrit :
 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.
 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?
 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.

I'm not.

They are dealing with a zero-day exploit, and it was clearly explained
on the private mailing list.

That some missing  and incorrect NL were detected after the release has
been cut is unfortunate (or fortunate, considering taht it has been
detected), but this is know known and will be addressed. IMO,
considering that a new release will occur soon, for which patches will
be applied to fix those incorrect NL is good enough to vote this release.

I seriously *wish* that all the other Apache projects are as respectful
to the requirements regarding NL, and I must say that, having been
through Seb scrutinity (thanks, Seb, btw), my own projects were not
perfect despite many releases that have been cut in the past.

I find it a but tough to say you are disapointed, because they *have*
considered the pros and cons of releasing now vs postponing to get the
NL fixed.


 I'll change my vote to -0 to avoid sucha  dead lock :-)

 I expect the groovy podling to cut a release asap that fixes the NL issues.
 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

I think they are doing it right, so far. My  remark was more for the
record than anything else.






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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 16/07/15 19:48, Daniel Gruno a écrit :
 Can someone show me where in the bylaws this dreaded and apparently
 mandatory 72+ hour window is?
 When last I looked, it was the preferred thing to do in most
 circumstances, it was not _MANDATED BY LAW_.

Nobody said that. However, I like it when a pdoling absorbed the
information that a vote must be hold for 72 h : that means they
understand how it works.

That being said, you are right : those 72 h can be bypassed when required.


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

[RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
binding votes. Despite the negative votes, we will release and fix the L/N
files in the next release and try to clarify the README. It is very
important to get this 2.4.4 release out ASAP.

Thanks to all voters!

2015-07-13 10:33 GMT+02:00 Cédric Champeau cedric.champ...@gmail.com:

Hi all!

The Apache Groovy PPMC has successfully voted the release of Apache Groovy
2.4.4-incubating [1], with 6 +1 binding votes, one +1 non binding, no
0 votes and one -1 vote (see the explanation below). We are now asking
the IPMC to vote it too. Since it is our first release under the Apache
Software Foundation umbrella, let me give a few more details:

- this release is our second attempt to release Apache Groovy 2.4.4. The
first vote failed, mainly because our documentation was licensed under
Creative Commons by-sa. The issue has been mitigated with the community, we
have voted to relicense it under AL2.0 and approvals for all contributors
of the documentation have been tracked on a JIRA ticket (see below).
- since our pre-Apache era, all files have been modified to include the
normalized AL2.0 license headers. Files which couldn't be modified, such as
test files which must not include any header, have been excluded from Rat
checks.
- We have updated our build to use the Gradle license check plugin, then
Apache Rat plugin
- All jars have been removed from the source distribution, including those
which were used in tests (they are now generated by the build itself)
- Added the DISCLAIMER file, updated the LICENSE and NOTICE files
- Added a section on the README to indicate how to bootstrap Gradle, since
the Apache policy forbids to include the Gradle wrapper. It's worth noting
that Andrés actually missed that when he voted -1, meaning he thought the
wrapper was missing and that we couldn't build from source.
- We updated our release process for Apache (obviously), which already
required a noticeable amount of work. We have in particular worked with the
folks at JFrog to mitigate the problems we faced in automation (our
previous release process only required a single click...).

During the vote, the following points have been raised:

- the gradle.properties file doesn't contain the license header. This is
actually a glitch due to our automation process: builds are triggered from
the CI server which automates the update of the properties file. During
that process, the license header is lost. The consequence is that running
Rat from the source zip will fail with a warning on that file. However,
it is not critical since this file doesn't contain any IP, just version
number and VM parameters. We will fix this in the next release, by either
excluding the file from the Rat checks, or working with JFrog so that their
plugin reincludes the header file. This problem is the main reason for the
-1 vote we had from Andrés. In case of doubt, one can verify that it's
really the CI server which removed the license by checking this commit
(716b0b1bd5) which belongs to the REL_BRANCH_2_4_4 release branch.
- The incubating suffix (2.4.4-incubating) is only used on the source
zip. This is *intentional*. Groovy has a long history already, and our
users woudn't understand that newer releases include -incubating in the
version number. So the Maven artifacts, in particular, do not include
-incubating, which will greatly simplify upgrading and version conflict
resolution.
- Similarily, the directory that is created doesn't include apache- in
the file name. Some tools widely used in the community like GVM expect a
particular layout that would break if we changed that.

To summarize:

Vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvm%3DzDNCxpOua3LQ1ZNo62Aq40QZM7SJwgER5MfkArWrTeA%40mail.gmail.com%3E
Result of vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvmn1yEMMz_ZaCL5QqqUtQJdgd0NNcy8v7BVY8Lt4Uog0Zg%40mail.gmail.com%3E
Relicensing of the documentation tracking:
https://issues.apache.org/jira/browse/GROOVY-7470
Vote for relicensing the docs:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvm%3DMfajQuMxoZJmpLe%2B4W22a_MDY_dC4W%2BNMWiakEEOyNg%40mail.gmail.com%3E
Result of vote for relicensing the docs:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvmkQyOEk3ofOrnTHfnvTKO5xECY87hKAGf5pD%2BuePyA8UA%40mail.gmail.com%3E

The changelog for this release can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123version=12331941

Tag for the release:
https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=commit;h=716b0b1bd56eeab04e4441eecc91c2cd8bfda8b6

https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2

The artifacts to be voted on are located

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

2015-07-16 10:41 GMT+02:00 Justin Mclean jus...@classsoftware.com:

 Hi,

  This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
  binding votes.

 If you read carefully I think you find there were 3 -1 votes on the binary
 releases.


Agreed for binaries. However AFAIK, what Apache legally cares about is
sources.



  It is very important to get this 2.4.4 release out ASAP.

 Given that the changes were not major and could of been quickly fixed I
 don't see the the need for the rush but no issue either way a long as they
 are fixed in the next release and before graduation.


There's a rush that has been discussed on private@. The reason will soon be
disclosed.. And given the 2x72h voting period, it was very problematic. And
honestly, too long since our community had an update of Groovy. Before we
joined Apache, releasing took a couple of hours, and releasing another
version was cheap. It's far from being the case anymore.



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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

True. I -1 the binary release. Interesting case : should we release if
we have as many -1 than +1 ?

I'll change my vote to -0 to avoid sucha  dead lock :-)

I expect the groovy podling to cut a release asap that fixes the NL issues.


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Justin Mclean

Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.

If you read carefully I think you find there were 3 -1 votes on the binary 
releases.

 It is very important to get this 2.4.4 release out ASAP.

Given that the changes were not major and could of been quickly fixed I don't 
see the the need for the rush but no issue either way a long as they are fixed 
in the next release and before graduation. 

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

2015-07-16 18:49 GMT+02:00 Roman Shaposhnik ro...@shaposhnik.org:
 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?

 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.


Again, saying we don't take this seriously is at best an error and
honestly unfair. We take it very seriously and I am very disappointed
that you think we don't.
If you look at the commits, you will see that we started fixing those
issues *before* the release vote was finished. We *deserved* a release
for the community and *it was critical*. The
reasons why were explained on private@, and we could *not* afford
another 2x72 voting period + 24h mitigation period, that could also
potentially fail the IPMC vote (yes, because despite
the fact that we fixed all issues reported for our first trial, the
second had undetected errors too). Also, why having rules for votes if
you don't follow them? Like it or not, it passed the vote.

Not releasing would not have been serious, and we could have missed
the short timeframe we have given the vacations of the team.
It's also unfair because we took *very seriously* the comments for the
first attempt of the release, a few weeks ago, and fixed *all of them*
(and did even more than what you asked us to do).
So I think our community deserved that release more than having the
perfect LN files (especially because as we said, the License file
contains more, but not less, than required), and as
Paul said, all jars produces *do* have them.

 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

I sincerely hope my position is understood this time.

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Roman Shaposhnik

On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?

Personally, I'm disappointed in the podling for not taking
care of feedback that seems really easy to take care of.

 I'll change my vote to -0 to avoid sucha  dead lock :-)

 I expect the groovy podling to cut a release asap that fixes the NL issues.

That's my strong expectation as well. If we're doing this whole
mentoring thing -- lets do it right.

Thanks,
Roman.

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Marvin Humphrey

On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
cedric.champ...@gmail.com wrote:

 Like it or not, it passed the vote.

Given the logistics of rolling another RC (even with a shortened
window) and the urgency of the release due to security issues, I think
this was a decent outcome.

That said, contended release votes are extremely rare at Apache, and
the release contains some licensing glitches which would ordinarily
merit a respin in my judgment. I considered voting +1 but in the end
decided to abstain.

 (especially because as we said, the License file
 contains more, but not less, than required),

This is not quite the case.

There were some bundled dependencies whose licenses were not noted in
the top-level LICENSE file. This is a licensing documentation bug,
rather than a licensing error -- it does not make distribution
illegal, but it might lead to a downstream consumer failing to uphold
the conditions of the omitted licenses. For example, they may fail to
give proper attribution in a binary redistribution.

Additionally, in the case of normalize.css (hidden inside
stylesheet.css) and FileNameCompleter.groovy, an Apache header was
added inappropriately to files containing BSD-licensed and
MIT-licensed content.  Assuming that the content of those files has
never been licensed under the ALv2, this is a licensing error, and it
is a judgment call as to whether a reasonable consumer would interpret
that header as a mistake.

 and as
 Paul said, all jars produces *do* have them.

Indeed -- I only spot checked, but that's what I saw as well.

Marvin Humphrey

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Alex Harui

IMO, what would really help would be a step-by-step guide to examining a
release for L  N issues.  Justin explained part of his technique in this
thread already.  The person creating the release artifacts should have a
decent chance at finding these issues before opening any vote thread.

-Alex

On 7/16/15, 11:28 AM, Marvin Humphrey mar...@rectangular.com wrote:

On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
cedric.champ...@gmail.com wrote:

 Like it or not, it passed the vote.

Given the logistics of rolling another RC (even with a shortened
window) and the urgency of the release due to security issues, I think
this was a decent outcome.

That said, contended release votes are extremely rare at Apache, and
the release contains some licensing glitches which would ordinarily
merit a respin in my judgment. I considered voting +1 but in the end
decided to abstain.

 (especially because as we said, the License file
 contains more, but not less, than required),

This is not quite the case.

There were some bundled dependencies whose licenses were not noted in
the top-level LICENSE file. This is a licensing documentation bug,
rather than a licensing error -- it does not make distribution
illegal, but it might lead to a downstream consumer failing to uphold
the conditions of the omitted licenses. For example, they may fail to
give proper attribution in a binary redistribution.

Additionally, in the case of normalize.css (hidden inside
stylesheet.css) and FileNameCompleter.groovy, an Apache header was
added inappropriately to files containing BSD-licensed and
MIT-licensed content.  Assuming that the content of those files has
never been licensed under the ALv2, this is a licensing error, and it
is a judgment call as to whether a reasonable consumer would interpret
that header as a mistake.

 and as
 Paul said, all jars produces *do* have them.

Indeed -- I only spot checked, but that's what I saw as well.

Marvin Humphrey

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Le 16/07/15 20:43, Alex Harui a écrit :
 IMO, what would really help would be a step-by-step guide to examining a
 release for L  N issues.  Justin explained part of his technique in this
 thread already.  The person creating the release artifacts should have a
 decent chance at finding these issues before opening any vote thread.

+1 ! And adding such a tool into rat or whatever would be extremely
helpful, too...


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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Roman Shaposhnik

Hi Cédric,

let me start with saying that I do appreciate your personal efforts
and the Groovy podling efforts in general. You guys are really
on-boarding quite well and are one of the easiest podling to mentor.

What I felt disappointed about is not that you produced a release
with LN issues, but rather that you seems to have denied yourself
an opportunity to do it right based on incorrect assumptions. See bellow:

This email is not meant to block your RC (as it wasn't the case
with my original vote) but rather to try and refute some of those incorrect
assumptions.

On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
cedric.champ...@gmail.com wrote:
 2015-07-16 18:49 GMT+02:00 Roman Shaposhnik ro...@shaposhnik.org:
 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?

 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.


 Again, saying we don't take this seriously is at best an error and
 honestly unfair.

 We take it very seriously and I am very disappointed
 that you think we don't.

Lets be clear, what I was referring to is this: the identified LN issue
is a non-code change that has no implication to the stability of your
release whatsoever. Hence manually fixing it, re-spinning the RC and
calling a shortened (12-24h) vote doesn't seem to present a problem.

I just don't understand why you didn't entertain that as an option. Personally
I would've made myself available to cast my vote under very compressed
schedule if you actually ASKED for it.

 Not releasing would not have been serious, and we could have missed
 the short timeframe we have given the vacations of the team.
 It's also unfair because we took *very seriously* the comments for the
 first attempt of the release, a few weeks ago, and fixed *all of them*
 (and did even more than what you asked us to do).
 So I think our community deserved that release more than having the
 perfect LN files (especially because as we said, the License file
 contains more, but not less, than required), and as
 Paul said, all jars produces *do* have them.

 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

 I sincerely hope my position is understood this time.

Then, perhaps, following up with the dot release once the current one
is out, would be a way to go. Dot releases are cheap and easy and
having a releases that is actually squeaky clean from the IP perspective
is what Incubation is partially about.

Thanks,
Roman.

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

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Justin Mclean

Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...

The “tools” I use generally make a bit of noise and require some interpretation 
/ filtering so I’m not sure they could be automated cleanly. One thing rat 
might be able to do that I don’t think it currently does is detect files 
containing more than one license header.

Best advice I can give is follow this guide [1] and use it when reviewing 
releases.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-14 Thread Marvin Humphrey

On Mon, Jul 13, 2015 at 10:43 PM, Jochen Theodorou blackd...@gmx.org wrote:

 ok, but there is no harm in listing allergens that are not actually in
 there. So why can't we have a single NOTICE/LICENSE file that covers both
 cases? Is it not possible to say something that the binary distribution will
 additionally include this and that? Having to have two distinct files looks
 unnecessarily complex to me

Previous discussion (with links to previous discussion before that):

http://s.apache.org/LTD
http://s.apache.org/AV4

(Perhaps one day Apache will adopt SPDX: http://spdx.org)

Marvin Humphrey

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-14 Thread Alex Harui



On 7/13/15, 10:43 PM, Jochen Theodorou blackd...@gmx.org wrote:

Am 14.07.2015 07:26, schrieb Alex Harui:


 On 7/13/15, 10:05 PM, Jochen Theodorou blackd...@gmx.org wrote:

 then source and binary distribution have to have different
 NOTICE/LICENSE files?

 Yep, I think of it as the list of allergens in the package.  If you use
 peanut oil to cook the raw ingredients, you’d better tell the consumer.

ok, but there is no harm in listing allergens that are not actually in
there.

Hmm. I don’t agree with that.  I’ll bet food labelers are required to be
accurate.

 So why can't we have a single NOTICE/LICENSE file that covers
both cases? Is it not possible to say something that the binary
distribution will additionally include this and that? Having to have two
distinct files looks unnecessarily complex to me

I think more than one project “assembles” the L  N files as part of the
build.  You can often append the additional binary package information to
the source package’s L  N.  I don’t know if any project is permitted to
ship an L  N in the source package that delineates what things are only
in the binary package.  People with more experience will answer that.

-Alex

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-14 Thread Jim Jagielski

+1 (binding)

 On Jul 13, 2015, at 10:23 AM, Emmanuel Lécharny elecha...@gmail.com wrote:
 
 Hi,
 
 my +1 (Binding), for the source package.
 
 Addressing Justin's issues :
 
 There *are* issues, but considering the security issue fixed in this
 release, I'd rather have this version out.
 
 - The build scripts are failing because there are Windows file (^M at
 the end of ech line). Removing them let you build the project. This has
 to be fixed, though.
 - NOTICE : not critical, IMO, but need to be fixed.
 - LICENSE : I can't find the normalize.css file. The MIT  BSD license
 should be added into LICENSE. The not bundled licenses should be removed.
 
 All in all, there are issues, that need to be addressed, and I expect
 them to be fixed in the next release.
 
 Regarding the binary package, it has to contain the NL files. I have
 not checked it, because they are by-product, but that was a mistake
 (obviously, people will use them instead of using the sources). I would
 -1 the binary package as of today.
 
 Thanks !
 
 Le 13/07/15 14:12, Justin Mclean a écrit :
 Hi,
 
 -1 (binding) as LICENSE and NOTICE have issues, included files which have 
 Apache header when they are licensed under other terms, and binary 
 connivence files are missing required files (i.e. DISCLAIMER, LICENSE and 
 NOTICE) Note that the binary LICENSE and NOTICE file are very likely 
 different to the the source LICENSE and NOTICE files.
 
 For the source release I checked:
 - signatures ok but should be signed by apache.org address
 - hashes good
 - DISCLAIMER exists
 - LICENSE and NOTICE have issues (see below)
 - No unexpected binaries in source release
 - All source files have Apache header
 - Probably my setup/config but unable to compile from source and get this 
 error:
 
 FAILURE: Build failed with an exception.
 * Where:
 Script 
 '/Users/justinmclean/Downloads/ApacheGroovy/groovy-2.4.4/gradle/asciidoctor.gradle'
  line: 19
 * What went wrong:
 A problem occurred evaluating script.
 Could not create task of type 'AsciidoctorTask'.
 LICENSE and NOTICE issues:
 - NOTICE contains items that are not required (as they are not bundled) and 
 it’s not in usual format
 - LICENSE is missing:
  - MIT licensed asciidoctor.org see /src/spec/assets/css/style.css
  - MIT licensed normalize.css (in two places)
  - BSD licensed FileNameCompleter.groovy which also has an Apache header
 - LICENSE also contains several licenses/items that are not bundled and so 
 shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
 Multiverse 
 
 For binary releases:
 - All are missing DISCLAIMER, LICENSE and NOTICE
 
 Other issues:
 - release candidate not in correct place
 - not signed by apache.org address
 - Short form of bundled licenses are preferred to long version
 - all zips unzip to same directory
 
 Thanks,
 Justin
 -
 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
 


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

No particular reason but avoiding putting on dist artifacts that maybe
downvoted, so the idea is to put the artifacts there once they've been
voted. Consider people.a.o as a staging repo for those artifacts.

2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

 HI,

  The artifacts to be voted on are located here:
  http://people.apache.org/~cchampeau/groovy/


 Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

 Consider people.a.o as a staging repo for those artifacts.

Which is the wrong place to place release candidates and has been for several 
years.

Justin


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating


Changed. Thanks for pointing it out!

With regards,
Daniel.

On 2015-07-13 13:51, Cédric Champeau wrote:

Here: http://www.apache.org/dev/release.html#host-rc



2015-07-13 13:48 GMT+02:00 Daniel Gruno humbed...@apache.org:


Where is this documentation? If it is stated anywhere that
people.apache.org is an acceptable place for RCs, it is clearly wrong and
needs fixing.

With regards,
Daniel.


On 2015-07-13 13:43, Gianmarco De Francisci Morales wrote:


It would be good to update the piece of documentation that suggests to put
RC on personal space on p.a.o.

--
Gianmarco

On 13 July 2015 at 13:55, Cédric Champeau cedric.champ...@gmail.com
wrote:

  Right. Will make sure to use it next time.

2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

  Hi Cédric,

The whole point of the /dev/ branch on dist is for putting release
candidates to be voted on.
Once a release is approved, it is then moved to the /release/ branch.
people.apache.org really should not be used for this, especially as
that
machine will probably disappear in the not-too-distant future.

With regards,
Daniel.


On 2015-07-13 12:49, Cédric Champeau wrote:

  No particular reason but avoiding putting on dist artifacts that

maybe
downvoted, so the idea is to put the artifacts there once they've been
voted. Consider people.a.o as a staging repo for those artifacts.

2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

   HI,


   The artifacts to be voted on are located here:


http://people.apache.org/~cchampeau/groovy/

  Is there any reason the artefacts are not available here: [1]

https://dist.apache.org/repos/dist/dev/incubator/groovy

Thanks,
Justin

1. http://www.apache.org/dev/release.html#host-rc

-
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




-
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] Release Apache Groovy 2.4.4-incubating

Here: http://www.apache.org/dev/release.html#host-rc



2015-07-13 13:48 GMT+02:00 Daniel Gruno humbed...@apache.org:

 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong and
 needs fixing.

 With regards,
 Daniel.


 On 2015-07-13 13:43, Gianmarco De Francisci Morales wrote:

 It would be good to update the piece of documentation that suggests to put
 RC on personal space on p.a.o.

 --
 Gianmarco

 On 13 July 2015 at 13:55, Cédric Champeau cedric.champ...@gmail.com
 wrote:

  Right. Will make sure to use it next time.

 2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

  Hi Cédric,
 The whole point of the /dev/ branch on dist is for putting release
 candidates to be voted on.
 Once a release is approved, it is then moved to the /release/ branch.
 people.apache.org really should not be used for this, especially as
 that
 machine will probably disappear in the not-too-distant future.

 With regards,
 Daniel.


 On 2015-07-13 12:49, Cédric Champeau wrote:

  No particular reason but avoiding putting on dist artifacts that
 maybe
 downvoted, so the idea is to put the artifacts there once they've been
 voted. Consider people.a.o as a staging repo for those artifacts.

 2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

   HI,

   The artifacts to be voted on are located here:

 http://people.apache.org/~cchampeau/groovy/

  Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

 -
 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




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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

-1 (binding) as LICENSE and NOTICE have issues, included files which have 
Apache header when they are licensed under other terms, and binary connivence 
files are missing required files (i.e. DISCLAIMER, LICENSE and NOTICE) Note 
that the binary LICENSE and NOTICE file are very likely different to the the 
source LICENSE and NOTICE files.

For the source release I checked:
- signatures ok but should be signed by apache.org address
- hashes good
- DISCLAIMER exists
- LICENSE and NOTICE have issues (see below)
- No unexpected binaries in source release
- All source files have Apache header
- Probably my setup/config but unable to compile from source and get this error:

FAILURE: Build failed with an exception.
* Where:
Script 
'/Users/justinmclean/Downloads/ApacheGroovy/groovy-2.4.4/gradle/asciidoctor.gradle'
 line: 19
* What went wrong:
A problem occurred evaluating script.
 Could not create task of type 'AsciidoctorTask'.

 LICENSE and NOTICE issues:
- NOTICE contains items that are not required (as they are not bundled) and 
it’s not in usual format
- LICENSE is missing:
- MIT licensed asciidoctor.org see /src/spec/assets/css/style.css
- MIT licensed normalize.css (in two places)
- BSD licensed FileNameCompleter.groovy which also has an Apache header
- LICENSE also contains several licenses/items that are not bundled and so 
shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
Multiverse 

For binary releases:
- All are missing DISCLAIMER, LICENSE and NOTICE

Other issues:
- release candidate not in correct place
- not signed by apache.org address
- Short form of bundled licenses are preferred to long version
- all zips unzip to same directory

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Gianmarco De Francisci Morales

It would be good to update the piece of documentation that suggests to put
RC on personal space on p.a.o.

--
Gianmarco

On 13 July 2015 at 13:55, Cédric Champeau cedric.champ...@gmail.com wrote:

 Right. Will make sure to use it next time.

 2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

  Hi Cédric,
  The whole point of the /dev/ branch on dist is for putting release
  candidates to be voted on.
  Once a release is approved, it is then moved to the /release/ branch.
  people.apache.org really should not be used for this, especially as that
  machine will probably disappear in the not-too-distant future.
 
  With regards,
  Daniel.
 
 
  On 2015-07-13 12:49, Cédric Champeau wrote:
 
  No particular reason but avoiding putting on dist artifacts that maybe
  downvoted, so the idea is to put the artifacts there once they've been
  voted. Consider people.a.o as a staging repo for those artifacts.
 
  2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:
 
   HI,
 
   The artifacts to be voted on are located here:
  http://people.apache.org/~cchampeau/groovy/
 
 
  Is there any reason the artefacts are not available here: [1]
  https://dist.apache.org/repos/dist/dev/incubator/groovy
 
  Thanks,
  Justin
 
  1. http://www.apache.org/dev/release.html#host-rc
 
  -
  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] Release Apache Groovy 2.4.4-incubating

Where is this documentation? If it is stated anywhere that 
people.apache.org is an acceptable place for RCs, it is clearly wrong 
and needs fixing.


With regards,
Daniel.

On 2015-07-13 13:43, Gianmarco De Francisci Morales wrote:

It would be good to update the piece of documentation that suggests to put
RC on personal space on p.a.o.

--
Gianmarco

On 13 July 2015 at 13:55, Cédric Champeau cedric.champ...@gmail.com wrote:


Right. Will make sure to use it next time.

2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:


Hi Cédric,
The whole point of the /dev/ branch on dist is for putting release
candidates to be voted on.
Once a release is approved, it is then moved to the /release/ branch.
people.apache.org really should not be used for this, especially as that
machine will probably disappear in the not-too-distant future.

With regards,
Daniel.


On 2015-07-13 12:49, Cédric Champeau wrote:


No particular reason but avoiding putting on dist artifacts that maybe
downvoted, so the idea is to put the artifacts there once they've been
voted. Consider people.a.o as a staging repo for those artifacts.

2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

  HI,

  The artifacts to be voted on are located here:

http://people.apache.org/~cchampeau/groovy/


Is there any reason the artefacts are not available here: [1]
https://dist.apache.org/repos/dist/dev/incubator/groovy

Thanks,
Justin

1. http://www.apache.org/dev/release.html#host-rc

-
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





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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating


Hi Cédric,
The whole point of the /dev/ branch on dist is for putting release 
candidates to be voted on.

Once a release is approved, it is then moved to the /release/ branch.
people.apache.org really should not be used for this, especially as that 
machine will probably disappear in the not-too-distant future.


With regards,
Daniel.

On 2015-07-13 12:49, Cédric Champeau wrote:

No particular reason but avoiding putting on dist artifacts that maybe
downvoted, so the idea is to put the artifacts there once they've been
voted. Consider people.a.o as a staging repo for those artifacts.

2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:


HI,


The artifacts to be voted on are located here:
http://people.apache.org/~cchampeau/groovy/


Is there any reason the artefacts are not available here: [1]
https://dist.apache.org/repos/dist/dev/incubator/groovy

Thanks,
Justin

1. http://www.apache.org/dev/release.html#host-rc

-
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] Release Apache Groovy 2.4.4-incubating

Right. Will make sure to use it next time.

2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

 Hi Cédric,
 The whole point of the /dev/ branch on dist is for putting release
 candidates to be voted on.
 Once a release is approved, it is then moved to the /release/ branch.
 people.apache.org really should not be used for this, especially as that
 machine will probably disappear in the not-too-distant future.

 With regards,
 Daniel.


 On 2015-07-13 12:49, Cédric Champeau wrote:

 No particular reason but avoiding putting on dist artifacts that maybe
 downvoted, so the idea is to put the artifacts there once they've been
 voted. Consider people.a.o as a staging repo for those artifacts.

 2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

  HI,

  The artifacts to be voted on are located here:
 http://people.apache.org/~cchampeau/groovy/


 Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

 -
 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] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Andrew Bayer

Argh, I forgot to vote over on the podling thread, so hey, I'll vote now!

RAT check passed, signatures check out, tags check out, could build from
source package.

+1 binding, IPMC, mentor.

On Mon, Jul 13, 2015 at 10:33 AM, Cédric Champeau cedric.champ...@gmail.com
wrote:

Hi all!

During the vote, the following points have been raised:

To summarize:

Vote on dev list:

http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvm%3DzDNCxpOua3LQ1ZNo62Aq40QZM7SJwgER5MfkArWrTeA%40mail.gmail.com%3E
Result of vote on dev list:

http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvmn1yEMMz_ZaCL5QqqUtQJdgd0NNcy8v7BVY8Lt4Uog0Zg%40mail.gmail.com%3E
Relicensing of the documentation tracking:
https://issues.apache.org/jira/browse/GROOVY-7470
Vote for relicensing the docs:

http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvm%3DMfajQuMxoZJmpLe%2B4W22a_MDY_dC4W%2BNMWiakEEOyNg%40mail.gmail.com%3E
Result of vote for relicensing the docs:

http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvmkQyOEk3ofOrnTHfnvTKO5xECY87hKAGf5pD%2BuePyA8UA%40mail.gmail.com%3E

The changelog for this release can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123version=12331941

Tag for the release:

https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=commit;h=716b0b1bd56eeab04e4441eecc91c2cd8bfda8b6

https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2

The artifacts to be voted on are located here:
http://people.apache.org/~cchampeau/groovy/

Release

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

HI,

 The artifacts to be voted on are located here:
 http://people.apache.org/~cchampeau/groovy/


Is there any reason the artefacts are not available here: [1]
https://dist.apache.org/repos/dist/dev/incubator/groovy

Thanks,
Justin

1. http://www.apache.org/dev/release.html#host-rc

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Jochen Theodorou


Am 13.07.2015 23:00, schrieb Justin Mclean:

Hi,


We don't bundle the source from any of those libraries true, but we do generate 
sources as part of our build using ANTLR and we do bundle the class files from 
the ANLTR and ASM projects in some of our jars and we do bundle the jars from 
some of those projects in some of our binary zips. So, only use of source files 
is important for NOTICE/LICENSE or would we need slightly different versions of 
those files in different places?


Yes only refer to what is bundled [1] and yes the NOTICE/LICENSE files would 
need to be different [2].

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
2. http://www.apache.org/dev/licensing-howto.html#binary



then source and binary distribution have to have different 
NOTICE/LICENSE files?


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Alex Harui



On 7/13/15, 10:05 PM, Jochen Theodorou blackd...@gmx.org wrote:

then source and binary distribution have to have different
NOTICE/LICENSE files?

Yep, I think of it as the list of allergens in the package.  If you use
peanut oil to cook the raw ingredients, you’d better tell the consumer.

-Alex

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Jochen Theodorou


Am 14.07.2015 07:26, schrieb Alex Harui:



On 7/13/15, 10:05 PM, Jochen Theodorou blackd...@gmx.org wrote:


then source and binary distribution have to have different
NOTICE/LICENSE files?


Yep, I think of it as the list of allergens in the package.  If you use
peanut oil to cook the raw ingredients, you’d better tell the consumer.


ok, but there is no harm in listing allergens that are not actually in 
there. So why can't we have a single NOTICE/LICENSE file that covers 
both cases? Is it not possible to say something that the binary 
distribution will additionally include this and that? Having to have two 
distinct files looks unnecessarily complex to me


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Le 13/07/15 16:09, Cédric Champeau a écrit :
 2015-07-13 16:03 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:

 Le 13/07/15 13:48, Daniel Gruno a écrit :
 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong
 and needs fixing.
 It's not written, it's a common usage for almost all of the projects,
 AFAICT. It's good to know that it's not the right place for such packages.

 It *was* written a couple of hours ago:
 Projects typically use http://people.apache.org/~${RM}/** or the newer /dev
 tree of the dist repository https://dist.apache.org/repos/dist/dev or the
 staging features of repository.apache.org to host release candidates posted
 for developer testing/voting (prior to being, potentially, formally blessed
 as a GA release).

 Now this has just been changed :)

Jurst FTR, dist.a.o exists for 3 years now (AFAIR) and for those of us
who cut releases for a decade (I can't believe I have spent 10 years on
an apache project...), people.a.o was the place to store such packages.
At this point, I think there were some missing communication (which
could be both side : either the message was not transmitted, or not read ;-)

I strongly suggest that every PMC should be reminded !

Thanks Daniel.


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Le 13/07/15 13:48, Daniel Gruno a écrit :
 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong
 and needs fixing.

It's not written, it's a common usage for almost all of the projects,
AFAICT. It's good to know that it's not the right place for such packages.

What's the alternative ?


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

my +1 (Binding), for the source package.

Addressing Justin's issues :

There *are* issues, but considering the security issue fixed in this
release, I'd rather have this version out.

- The build scripts are failing because there are Windows file (^M at
the end of ech line). Removing them let you build the project. This has
to be fixed, though.
- NOTICE : not critical, IMO, but need to be fixed.
- LICENSE : I can't find the normalize.css file. The MIT  BSD license
should be added into LICENSE. The not bundled licenses should be removed.

All in all, there are issues, that need to be addressed, and I expect
them to be fixed in the next release.

Regarding the binary package, it has to contain the NL files. I have
not checked it, because they are by-product, but that was a mistake
(obviously, people will use them instead of using the sources). I would
-1 the binary package as of today.

Thanks !

Le 13/07/15 14:12, Justin Mclean a écrit :
 Hi,

 -1 (binding) as LICENSE and NOTICE have issues, included files which have 
 Apache header when they are licensed under other terms, and binary connivence 
 files are missing required files (i.e. DISCLAIMER, LICENSE and NOTICE) Note 
 that the binary LICENSE and NOTICE file are very likely different to the the 
 source LICENSE and NOTICE files.

 For the source release I checked:
 - signatures ok but should be signed by apache.org address
 - hashes good
 - DISCLAIMER exists
 - LICENSE and NOTICE have issues (see below)
 - No unexpected binaries in source release
 - All source files have Apache header
 - Probably my setup/config but unable to compile from source and get this 
 error:

 FAILURE: Build failed with an exception.
 * Where:
 Script 
 '/Users/justinmclean/Downloads/ApacheGroovy/groovy-2.4.4/gradle/asciidoctor.gradle'
  line: 19
 * What went wrong:
 A problem occurred evaluating script.
 Could not create task of type 'AsciidoctorTask'.
  LICENSE and NOTICE issues:
 - NOTICE contains items that are not required (as they are not bundled) and 
 it’s not in usual format
 - LICENSE is missing:
   - MIT licensed asciidoctor.org see /src/spec/assets/css/style.css
   - MIT licensed normalize.css (in two places)
   - BSD licensed FileNameCompleter.groovy which also has an Apache header
 - LICENSE also contains several licenses/items that are not bundled and so 
 shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
 Multiverse 

 For binary releases:
 - All are missing DISCLAIMER, LICENSE and NOTICE

 Other issues:
 - release candidate not in correct place
 - not signed by apache.org address
 - Short form of bundled licenses are preferred to long version
 - all zips unzip to same directory

 Thanks,
 Justin
 -
 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] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Paul King


On 13/07/2015 10:12 PM, Justin Mclean wrote:

- NOTICE contains items that are not required (as they are not bundled) and 
it’s not in usual format
- LICENSE also contains several licenses/items that are not bundled and so 
shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
Multiverse


We don't bundle the source from any of those libraries true, but we do generate 
sources as part of our build using ANTLR and we do bundle the class files from 
the ANLTR and ASM projects in some of our jars and we do bundle the jars from 
some of those projects in some of our binary zips. So, only use of source files 
is important for NOTICE/LICENSE or would we need slightly different versions of 
those files in different places?


For binary releases:
- All are missing DISCLAIMER, LICENSE and NOTICE


These are all in the meta-inf directory within all the produced jars but agreed 
should be in the root of the zips (already true for src zip) as well.

Cheers, Paul.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 16:03 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:

 Le 13/07/15 13:48, Daniel Gruno a écrit :
  Where is this documentation? If it is stated anywhere that
  people.apache.org is an acceptable place for RCs, it is clearly wrong
  and needs fixing.

 It's not written, it's a common usage for almost all of the projects,
 AFAICT. It's good to know that it's not the right place for such packages.

 It *was* written a couple of hours ago:

Projects typically use http://people.apache.org/~${RM}/** or the newer /dev
tree of the dist repository https://dist.apache.org/repos/dist/dev or the
staging features of repository.apache.org to host release candidates posted
for developer testing/voting (prior to being, potentially, formally blessed
as a GA release).

Now this has just been changed :)


 What's the alternative ?


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

The 'alternative' is dist.apache.org which is the right place to put it, 
since it is revision controlled, which means we'll keep track of what 
exactly was voted on, even after it's been deleted or moved.


With regards,
Daniel.

On 2015-07-13 16:03, Emmanuel Lécharny wrote:

Le 13/07/15 13:48, Daniel Gruno a écrit :

Where is this documentation? If it is stated anywhere that
people.apache.org is an acceptable place for RCs, it is clearly wrong
and needs fixing.

It's not written, it's a common usage for almost all of the projects,
AFAICT. It's good to know that it's not the right place for such packages.

What's the alternative ?


-
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] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Roman Shaposhnik

On Mon, Jul 13, 2015 at 7:27 AM, Emmanuel Lécharny elecha...@gmail.com wrote:
 It *was* written a couple of hours ago:
 Projects typically use http://people.apache.org/~${RM}/** or the newer /dev
 tree of the dist repository https://dist.apache.org/repos/dist/dev or the
 staging features of repository.apache.org to host release candidates posted
 for developer testing/voting (prior to being, potentially, formally blessed
 as a GA release).

 Now this has just been changed :)

 Jurst FTR, dist.a.o exists for 3 years now (AFAIR) and for those of us
 who cut releases for a decade (I can't believe I have spent 10 years on
 an apache project...), people.a.o was the place to store such packages.
 At this point, I think there were some missing communication (which
 could be both side : either the message was not transmitted, or not read ;-)

 I strongly suggest that every PMC should be reminded !

This is a great point! Personally, I keep forgetting about it as well.
That said, to Daniel's point -- I don't think this is a strong requirement,
but indeed a great suggestion to follow.

Thanks,
Roman.

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Roman Shaposhnik

Hi!

first all, I'd like to say that between the last RC that
I reviewed and this one Groovy team has made
huge progress. You guys rock! That said, the IP
hygiene is one of the biggest parts of the curriculum
known as Incubator. For that reason, I can't thank
Justin enough for his thorough review.

As it appears to me his feedback shouldn't be that
difficult to take care of. Once again, I do realize that
RCs keep coming which could be a bit frustrating,
but hopefully the next one will be the last one.

As such, I'm -1 on this RC. Blockers for my vote are
all around LN files. The rest of the feedback, while
super useful, will not be critical for me to change my
vote back to +1.

-1 (binding).

Thanks,
Roman.

On Mon, Jul 13, 2015 at 7:23 AM, Emmanuel Lécharny elecha...@gmail.com wrote:
 Hi,

 my +1 (Binding), for the source package.

 Addressing Justin's issues :

 There *are* issues, but considering the security issue fixed in this
 release, I'd rather have this version out.

 - The build scripts are failing because there are Windows file (^M at
 the end of ech line). Removing them let you build the project. This has
 to be fixed, though.
 - NOTICE : not critical, IMO, but need to be fixed.
 - LICENSE : I can't find the normalize.css file. The MIT  BSD license
 should be added into LICENSE. The not bundled licenses should be removed.

 All in all, there are issues, that need to be addressed, and I expect
 them to be fixed in the next release.

 Regarding the binary package, it has to contain the NL files. I have
 not checked it, because they are by-product, but that was a mistake
 (obviously, people will use them instead of using the sources). I would
 -1 the binary package as of today.

 Thanks !

 Le 13/07/15 14:12, Justin Mclean a écrit :
 Hi,

 -1 (binding) as LICENSE and NOTICE have issues, included files which have 
 Apache header when they are licensed under other terms, and binary 
 connivence files are missing required files (i.e. DISCLAIMER, LICENSE and 
 NOTICE) Note that the binary LICENSE and NOTICE file are very likely 
 different to the the source LICENSE and NOTICE files.

 For the source release I checked:
 - signatures ok but should be signed by apache.org address
 - hashes good
 - DISCLAIMER exists
 - LICENSE and NOTICE have issues (see below)
 - No unexpected binaries in source release
 - All source files have Apache header
 - Probably my setup/config but unable to compile from source and get this 
 error:

 FAILURE: Build failed with an exception.
 * Where:
 Script 
 '/Users/justinmclean/Downloads/ApacheGroovy/groovy-2.4.4/gradle/asciidoctor.gradle'
  line: 19
 * What went wrong:
 A problem occurred evaluating script.
 Could not create task of type 'AsciidoctorTask'.
  LICENSE and NOTICE issues:
 - NOTICE contains items that are not required (as they are not bundled) and 
 it’s not in usual format
 - LICENSE is missing:
   - MIT licensed asciidoctor.org see /src/spec/assets/css/style.css
   - MIT licensed normalize.css (in two places)
   - BSD licensed FileNameCompleter.groovy which also has an Apache header
 - LICENSE also contains several licenses/items that are not bundled and so 
 shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
 Multiverse

 For binary releases:
 - All are missing DISCLAIMER, LICENSE and NOTICE

 Other issues:
 - release candidate not in correct place
 - not signed by apache.org address
 - Short form of bundled licenses are preferred to long version
 - all zips unzip to same directory

 Thanks,
 Justin
 -
 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


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Jochen Theodorou


Am 13.07.2015 16:25, schrieb Paul King:
[...]

For binary releases:
- All are missing DISCLAIMER, LICENSE and NOTICE


These are all in the meta-inf directory within all the produced jars but
agreed should be in the root of the zips (already true for src zip) as
well.


I thought having hose in META-INF for jar files is common practice. At 
least the few apache jars I checked here either have none of those or 
they have them in that directory. What sense does it make to have those 
files in a ja root directory?


by blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

 We don't bundle the source from any of those libraries true, but we do 
 generate sources as part of our build using ANTLR and we do bundle the class 
 files from the ANLTR and ASM projects in some of our jars and we do bundle 
 the jars from some of those projects in some of our binary zips. So, only use 
 of source files is important for NOTICE/LICENSE or would we need slightly 
 different versions of those files in different places?

Yes only refer to what is bundled [1] and yes the NOTICE/LICENSE files would 
need to be different [2].

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
2. http://www.apache.org/dev/licensing-howto.html#binary

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

 - LICENSE : I can't find the normalize.css file.

See:
./subprojects/groovy-docgenerator/src/main/resources/org/codehaus/groovy/tools/stylesheet.css
./subprojects/groovy-groovydoc/src/main/resources/org/codehaus/groovy/tools/groovydoc/gstringTemplates/topLevel/stylesheet.css

It contains this:
normalize.css v2.1.0 | MIT License | git.io/normalize

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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Le 13/07/15 23:21, Justin Mclean a écrit :
 Hi,

 - LICENSE : I can't find the normalize.css file.
 See:
 ./subprojects/groovy-docgenerator/src/main/resources/org/codehaus/groovy/tools/stylesheet.css
 ./subprojects/groovy-groovydoc/src/main/resources/org/codehaus/groovy/tools/groovydoc/gstringTemplates/topLevel/stylesheet.css

 It contains this:
 normalize.css v2.1.0 | MIT License | git.io/normalize

Ah, thanks , I was looking for the file normalize.css...

What tool are you using to find the licenses that are not listed ?



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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Hi,

 What tool are you using to find the licenses that are not listed ?

Noting special, just find + grep. I generally do something like this, piped to 
a couple of grep -v’s to remove noise where needed:
find . -name *.* -exec grep “BSD {} \; -print
find . -name *.* -exec grep “GPL {} \; -print
find . -name *.* -exec grep “MIT {} \; -print
find . -name *.* -exec grep -i “copyright {} \; -print
find . -name *.* -exec grep -i “license {} \; -print

For jars (in binary releases) I usually just use  tar tf *.jar to see what 
inside, the package names point you in the right direction.

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

[VOTE] Release Apache Groovy 2.4.4-incubating