date:20150717

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

[ANNOUNCE] Apache NiFi 0.2.0-incubating release

2015-07-17 Thread Matt Gilman

Hello

The Apache NiFi team would like to announce the release of Apache NiFi
0.2.0-incubating.

Apache NiFi is an easy to use, powerful, and reliable system to process and
distribute data.  Apache NiFi was made for dataflow.  It supports highly
configurable directed graphs of data routing, transformation, and system
mediation logic.

More details on Apache NiFi can be found here:
http://nifi.incubator.apache.org/

The release artifacts can be downloaded from here:
http://nifi.incubator.apache.org/downloads/

Maven artifacts have been made available here:
https://repository.apache.org/content/repositories/releases/org/apache/nifi/

Release notes available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020version=12332286

Thank you
The Apache NiFi team


DISCLAIMER

Apache NiFi is an effort undergoing incubation at The Apache Software
Foundation (ASF), sponsored by  Apache Incubator. Incubation is required of
all newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.

Re: [VOTE] Apache Ignite 1.3.0 release (RC2)

My -0 wasn't really reflecting on the quality of the release, but was rather
about this long standing issue with broken format of the checksum files (which
was making the validation harder) .

I see that the issue is getting addressed for the next release, hence I'm
changing my vote to

+1 (binding)

Thanks,
Cos

On July 15, 2015 6:51:55 AM PDT, Yakov Zhdanov yzhda...@apache.org wrote:
Hello!

The Apache Ignite PPMC has voted to release Apache Ignite
1.3.0-incubating.
The vote was based on the release candidate and thread described below.
We now request the IPMC to vote on this release.

Apache Ignite 1.3.0 release (RC2) has been accepted with 7 votes for (1
binding vote):

- Branko Cibej (binding)
- Sergey Khisamov
- Nick Tikhonov
- Ira Vasilinets
- Semyon Boikov
- Alex Kuznetsov
- Yakov Zhdanov

and 1 0 vote:

- Cos Boudnik (binding)

We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/incubator/ignite/1.3.0-rc2/

Tag name is
ignite-1.3.0-incubating-rc2

1.3.0 changes:
* Added auto-retries for cache operations in recoverable cases.
* Added integration with Apache YARN.
* Added auto detection and dropping of slow client nodes.
* Fixed several issues with JTA integration.
* Fixed several issues with Hibernate L2 cache.
* Fixed issue with GAR files in source release.
* Stability fixes for TCP discovery SPI.
* Stability fixes for onheap and offheap SQL queries.
* Bug fixes in In-Memory Accelerator For Apache Hadoop.
* Many stability and fault-tolerance fixes.

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.3.0-incubating-rc2

RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.3.0-incubating-rc2

Please start voting.

+1 - to accept Apache Ignite (incubating) 1.3.0
0 - don't care either way
-1 - DO NOT accept Apache Ignite (incubating) 1.3.0 (explain why)

Here is the PPMC vote thread -
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-3-0-Release-RC2-tp1605.html

This vote will go for 72 hours.

--Yakov

Re: [VOTE] Apache Ignite 1.3.0 release (RC2)

My -0 wasn't really reflecting on the quality of the release, but rather an
issue with broken format of the checksum files (which was making the validation
harder) .

I see that the issue is getting addressed for the next release, hence I'm
changing my vote to

+1 (binding)
--
Regards,
Cos

On July 15, 2015 6:51:55 AM PDT, Yakov Zhdanov yzhda...@apache.org wrote:
Hello!

The Apache Ignite PPMC has voted to release Apache Ignite
1.3.0-incubating.
The vote was based on the release candidate and thread described below.
We now request the IPMC to vote on this release.

Apache Ignite 1.3.0 release (RC2) has been accepted with 7 votes for (1
binding vote):

- Branko Cibej (binding)
- Sergey Khisamov
- Nick Tikhonov
- Ira Vasilinets
- Semyon Boikov
- Alex Kuznetsov
- Yakov Zhdanov

and 1 0 vote:

- Cos Boudnik (binding)

We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/incubator/ignite/1.3.0-rc2/

Tag name is
ignite-1.3.0-incubating-rc2

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.3.0-incubating-rc2

RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.3.0-incubating-rc2

Please start voting.

+1 - to accept Apache Ignite (incubating) 1.3.0
0 - don't care either way
-1 - DO NOT accept Apache Ignite (incubating) 1.3.0 (explain why)

Here is the PPMC vote thread -
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-3-0-Release-RC2-tp1605.html

This vote will go for 72 hours.

--Yakov

-
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 NiFi 0.2.0-incubating

2015-07-17 Thread Ryan Hendrickson

Fantastic!  Is this going to hit the download site soon?
https://nifi.incubator.apache.org/download.html

Ryan

On Thu, Jul 16, 2015 at 9:45 AM, Matt Gilman matt.c.gil...@gmail.com
wrote:

 Hello

 The release passes with

 4 +1 (binding) votes
 0 -1 (binding) votes

 Thanks to all who helped make this release possible.

 Here is the IPMC vote thread: http://s.apache.org/wp6

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: [NOTICE] Yetus TLP proposal

2015-07-17 Thread Sean Busbey

On Thu, Jul 16, 2015 at 4:50 PM, Henry Saputra henry.sapu...@gmail.com
wrote:

 What is the notificati...@yetus.apache.org list for?

 - Henry


internal build notifications, commits to git. basically all the automated
message stuff.

-- 
Sean

Re: [NOTICE] Yetus TLP proposal

2015-07-17 Thread Sean Busbey

Have Jun add themselves to the interested contributors section and we'll
get them started.

On Thu, Jul 16, 2015 at 2:13 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 Hi!

 I'd like to nominate Jun Aoki (a committer on Apache Ambari)
 for this project. He's done a lot of integration work with testpatch
 for Amabri and Geode. He's already committer on Ambari and
 thus pretty versed in the Apache Way. What would be the best
 way to consider him?

 Thanks,
 Roman.

 On Sat, Jul 11, 2015 at 10:03 PM, Sean Busbey bus...@cloudera.com wrote:
  Hi Folks!
 
  There's a community going through board resolution to move from within
  Hadoop to form a new TLP named Yetus. Due to a request on a private list
  we've made a incubator proposal summary of the project.
 
  Proposal:
 
  https://wiki.apache.org/incubator/YetusProposal
 
  tl;dr description: Yetus provides libraries and tools that enable
  contribution and release processes for software projects.
 
  The main discussion about the move to TLP is on the common-dev@hadoop
 list.
  There's a link in the proposal's Documentation section for the
  interested. We welcome additional participants.
 
  Additional project discussion will be on the common-dev@hadoop list
 with a
  subject line that inlcudes [Yetus].
 
  --
  Sean

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




-- 
Sean

Apache Usergrid (incubating) v1.0.2 released

2015-07-17 Thread Dave

The Usergrid project is happy to announce that the Usergrid 1.0.2 release
is now available for download.

Apache Usergrid (incubating) is a multi-tenant Backend-as-a-Service (BaaS)
stack for web and mobile applications, based on RESTful APIs. Usergrid
consists of a Java-based web application that persists data to Apache
Cassandra, an HTML5/JavaScript based management portal and a set of SDKs
for JavaScript, iOS, Android, PHP, Java and more.

Usergrid 1.0.2 is a minor release with bug fixes and small improvements.

Bugs fixed

* S3 upload fails on OpenJDK and Java 8 (fixed by JClouds upgrade)
* Asset data deleted when connection to Asset deleted
* Portal stores app password as clear-text

Improvements

* Cassandra key-space names are now configurable

Experimental new features

* ExportAdmins: a new tool to export Admin Users, credentials and
organizations
* ImportAdmins: a new tool to import Admin Users, credentials and
organizations
* Central SSO: Usergrid-Usergrid SSO via new /management/externaltoken
end-point


Here's the full list of JIRA issues resolved:
https://issues.apache.org/jira/issues/?jql=project%3Dusergrid%20and%20fixVersion%3D1.0.2

The release is available at:
http://www.apache.org/dyn/closer.cgi/incubator/usergrid/usergrid-1/v1.0.2

The tag used to create the release with is 1.0.2:
https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=commit;h=1.0.2

The release's Git commit ID is d52427b279306e19c163e89e9d5025760fc0b50a

The MD5 checksum of the release can be found at:
https://dist.apache.org/repos/dist/release/incubator/usergrid/usergrid-1/v1.0.2/apache-usergrid-1.0.2-incubating.tar.gz.md5

The signature of the release can be found at:
https://dist.apache.org/repos/dist/release/incubator/usergrid/usergrid-1/v1.0.2/apache-usergrid-1.0.2-incubating.tar.gz.asc

The GPG key used to sign the release are available at:
https://dist.apache.org/repos/dist/release/incubator/usergrid/KEYS

Re: [ANNOUNCE] Aapche Lens 2.2.0-beta-incubating released

2015-07-17 Thread Greg Stein

Hello, Lens people!

In the future, please ensure that *all* release announcements include the
Incubating Disclaimer in them. Your download page should be updated
(asap) to include the same.

Thanks,
-g

On Thu, Jul 16, 2015 at 11:53 PM, Amareshwari Sriramdasu
amareshw...@apache.org wrote:

Hi all,

The Apache Lens team is proud to announce the release of Apache Lens
2.2.0-beta-incutaing.

Apache Lens provides an Unified Analytics interface. Lens aims to cut the
Data Analytics silos by providing a single view of data across multiple
tiered data stores and optimal execution environment for the analytical
query. It seamlessly integrates Hadoop with traditional data warehouses to
appear like one.

This release includes OLAP features like support for multiple expressions
and union queries, many CLI Improvements, Descriptive error codes,
integrates with Zeppelin and many more bug fixes and simple improvements.

The release artifacts are downloadable from
http://lens.incubator.apache.org/releases/download.html

Maven jar artifacts have also been made available on

https://repository.apache.org/content/repositories/releases/org/apache/lens/

Release notes available at

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329586projectId=12315923

More details on Apache Lens can be found at
http://lens.incubator.apache.org/

Getting started available at
http://lens.incubator.apache.org/lenshome/quick-start.html

We would like to thank all the contributors who made this release possible.

Thanks,
The Apache Lens team

Re: [VOTE] Release Blur version 0.2.4-incubating RC1

2015-07-17 Thread Tim Williams

Thanks for taking the time to review Justin, we appreciate it.

On Fri, Jul 17, 2015 at 8:01 PM, Justin Mclean jus...@classsoftware.com wrote:
Hi,

Sorry but it’s -1 (binding) until the MPL issue can be resolved / explained,
other issues can be fixed next release. For the MPL issue it may be that For
small amounts of source that is directly consumed by the ASF product at
runtime in source form” may apply. [2]

I think we just missed it, based on the example, I don't think we can
use that escape-clause/rationale for its inclusion. We should take it
back to the dev list at this point.

For the source release I checked:
- filename contains incubating
- signatures and hashes good
- DISCLAIMER exists
- LICENSE has minor issues + MPL issue [2]
- NOTICE good
- Some unexpected binaries in source (see below)
- All source file have headers
- Can compile form source?

LiCENSE is missing:
- MIT licensed normalize.css (see
./apache-blur-0.2.4-incubating-src/blur-console/src/main/webapp/public/css/blurconsole.css
+
./apache-blur-0.2.4-incubating-src/blur-console/src/main/webapp/libs/bootstrap/less/normalize.less)
- MIT/BSD licensed polyfill (see ./docs/resources/js/respond.min.js)

There is an issue with
./blur-console/src/main/webapp/libs/tagmanager/tagmanager.js as this is MPL
licensed [2] which is weak copy left and considered a category B license. In
this case it looks like it isn’t been handled correctly as it being included
in source not binary form. I’m not sure how this should be handled given
there is no compiled JS form.

There are a couple of test files that contain compiled code, can this be
produced via the build process?
./blur-core/src/test/resources/org/apache/blur/command/test1/test1.jar
./blur-core/src/test/resources/org/apache/blur/command/test2/test2.jar

Yeah, these were just to drive some tests but I reckon we should craft
another way that ships in source form.

Something a little odd that caught my eye is all of the
./distribution/src/main/resources-hadoop1/notices/*.jar.src files. Is there
any reason for these files to be in the source release? It look that they are
used to generate the binary NOTICE file?

They're sources needed to produce a [valid] binary package so it
seemed reasonable to me include them.

For the binary release you may want to check the LICENSE as it is identical
to the source release [3]. For the binary NOTICE file a minor issue in that
there is no need to repeat This product includes software developed by The
Apache Software Foundation “ [4].

Re compiling from source some instructions in the README would be helpful as
it seems a mvn install in the top directory may not do what is expected. (As
far as I can see it seems to be doing a rat check and nothing else?)

Yeah, we should add something to the README that hints at the
quickstart or profiles: mvn install -Dhadoop2

Thanks again for taking your time...

Thanks,
--tim

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

Re: [VOTE] Apache Ignite 1.3.0 release (RC2)

2015-07-17 Thread Justin Mclean

Hi,

I’ve having little trouble compiling it, but everything else checks out fine. 
Are there instructions anywhere on how to compile/what’s required? I think I’m 
just running into a memory issue.

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 Kylin-0.7.2-incubating

2015-07-17 Thread Justin Mclean

Hi,

+1 binding

I checked:
- release artefact contains incubating
- signatures and md5 hash good
- DISCLAIMER exists
- LICENSE and NOTICE good
- No unexpected binaries in source release
- All source files contain Apache headers
- Can compile from source

Some compile instructions in the README.md would be helpful as MAVEN_OPTS need 
to be set.

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

Re: [VOTE] Release Blur version 0.2.4-incubating RC1

2015-07-17 Thread Justin Mclean

Hi,

There is an issue with
./blur-console/src/main/webapp/libs/tagmanager/tagmanager.js as this is MPL
licensed [2] which is weak copy left and considered a category B license. In
this case it looks like it isn’t been handled correctly as it being included in
source not binary form. I’m not sure how this should be handled given there is
no compiled JS form.

Something a little odd that caught my eye is all of the
./distribution/src/main/resources-hadoop1/notices/*.jar.src files. Is there any
reason for these files to be in the source release? It look that they are used
to generate the binary NOTICE file?

For the binary release you may want to check the LICENSE as it is identical to
the source release [3]. For the binary NOTICE file a minor issue in that there
is no need to repeat This product includes software developed by The Apache
Software Foundation “ [4].

Re compiling from source some instructions in the README would be helpful as it
seems a mvn install in the top directory may not do what is expected. (As far
as I can see it seems to be doing a rat check and nothing else?)

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#alv2-dep
2. http://www.apache.org/legal/resolved.html#category-b
3. http://www.apache.org/dev/licensing-howto.html#binary
4. http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Zeppelin (incubating) 0.5.0-incubating

2015-07-17 Thread Marvin Humphrey

Hi Cos,

Thanks for providing a thoughtfully documented review.

On Fri, Jul 17, 2015 at 2:24 PM, Konstantin Boudnik c...@apache.org wrote:
 +1 (binding)

 Please consider fixing in the next release:
  - sha checksum is formatted in a way that makes automatic validation (with
sha512sum -c ) impossible. Also, it'd be better to make sha512 suffix for
the checksum file. sha is too ambiguous.
  - md5sum file is pretty much useless considering its weak security
properties. Perhaps makes sense to get rid of it?

As of a few months ago, requirements regarding cryptographic sums and
signatures have been codified in a section of the Release Distribution
Policy, curated by VP Infrastructure.

  http://www.apache.org/dev/release-distribution#sigs-and-sums

If you wanted to make a proposal regarding removal of MD5 checksums,
infrastructure-dev@apache is the place to go.

The format required by sha512sum is a bit of a pain to produce on
systems where sha512sum itself is not available.  For a Mac, or any
other system where Perl is present, something like this will work:

perl -MDigest -e '$d = Digest-new(MD5); open $fh, \
, apache-foo-1.2.3.tar.gz or die; $d-addfile($fh); \
print $d-hexdigest; print   apache-foo-1.2.3.tar.gz\n' \
  apache-foo-1.2.3.tar.gz.md5

I'm sure there are other hack invocations possible with other tools.

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 Zeppelin (incubating) 0.5.0-incubating

+1 (binding)

Checked the sha checksum and the signature - Ok.
Built/ran RAT check - Ok. Some tests are failing during the verify phase, but I
guess it doesn't make the release invalid.

Please consider fixing in the next release: 
 - sha checksum is formatted in a way that makes automatic validation (with
   sha512sum -c ) impossible. Also, it'd be better to make sha512 suffix for
   the checksum file. sha is too ambiguous.
 - md5sum file is pretty much useless considering its weak security
   properties. Perhaps makes sense to get rid of it?
 - there are older release artifacts hanging in the dev branch: please get rid
   of the them if they were properly released - it's confusing.

Thanks!
  Cos

P.S. I am not receiving dev@ emails although I am positive I am a part of it ;(

On Fri, Jul 17, 2015 at 12:38PM, moon soo Lee wrote:
 Hi all,
 
 Apache Zeppelin community has voted on following RC to be releaseed
 as official Apache Zeppelin (incubating) 0.5.0-incubating release.
 
 Since this is first release after under Apache Incubator,
 we would like to hear more feedback from incubator community
 and please help to verify and vote our release candidte.
 
 
 Vote on dev list:
 http://mail-archives.apache.org/mod_mbox/incubator-zeppelin-dev/201507.mbox/%3CCALf24sZYNnzyg1teG6vxT6EYMzA+Noj-Qxxg=ni46foecl2...@mail.gmail.com%3E
 
 Result of vote on dev list:
 http://mail-archives.apache.org/mod_mbox/incubator-zeppelin-dev/201507.mbox/%3ccalf24sz9qckkn2a3e+ocxuwkakyhvrwgqbng3oenp2xjzdt...@mail.gmail.com%3E
 
 The commit id is 5f5958a045147e0cf965d8840a55415d298a4e9f:
 https://git-wip-us.apache.org/repos/asf?p=incubator-zeppelin.git;a=commit;h=5f5958a045147e0cf965d8840a55415d298a4e9f
 
 This corresponds to the tag: v0.5.0:
 https://git-wip-us.apache.org/repos/asf?p=incubator-zeppelin.git;a=tag;h=refs/tags/v0.5.0
 
 The release archives (tgz), signature, and checksums are here:
 https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.0-incubating-rc1/
 
 The release candidate consists of the following source distribution archive:
 zeppelin-0.5.0-incubating.tgz
 
 In addition, the following supplementary binary distributions are provided
 for user convenience at the same location:
 zeppelin-0.5.0-incubating-bin-spark-1.3.1_hadoop-2.3.tgz
 zeppelin-0.5.0-incubating-bin-spark-1.4.0_hadoop-2.3.tgz
 
 The maven artifacts are here:
 https://repository.apache.org/content/repositories/orgapachezeppelin-1000/org/apache/zeppelin/
 
 You can find the KEYS file here:
 https://dist.apache.org/repos/dist/release/incubator/zeppelin/KEYS
 
 Release notes available at:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316221version=12329850
 
 Vote will be open for next 72 hours (close at 6am 20/July PDT).
 
 [ ] +1 approve
 [ ] 0 no opinion
 [ ] -1 disapprove (and reason why)
 
 Best regards,

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

Re: [VOTE] Apache Ignite 1.3.0 release (RC2)