[VOTE] Release Spark 2.4.7 (RC1)

2020-08-06 Thread Prashant Sharma
Please vote on releasing the following candidate as Apache Spark
version 2.4.7.

The vote is open until Aug 9th at 9AM PST and passes if a majority +1 PMC
votes are cast, with a minimum of 3 +1 votes.

[ ] +1 Release this package as Apache Spark 2.4.7
[ ] -1 Do not release this package because ...

To learn more about Apache Spark, please see http://spark.apache.org/

There are currently no issues targeting 2.4.7 (try project = SPARK AND
"Target Version/s" = "2.4.7" AND status in (Open, Reopened, "In Progress"))

The tag to be voted on is v2.4.7-rc1 (commit
dc04bf53fe821b7a07f817966c6c173f3b3788c6):
https://github.com/apache/spark/tree/v2.4.7-rc1

The release files, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/spark/v2.4.7-rc1-bin/

Signatures used for Spark RCs can be found in this file:
https://dist.apache.org/repos/dist/dev/spark/KEYS

The staging repository for this release can be found at:
https://repository.apache.org/content/repositories/orgapachespark-1352/

The documentation corresponding to this release can be found at:
https://dist.apache.org/repos/dist/dev/spark/v2.4.7-rc1-docs/

The list of bug fixes going into 2.4.7 can be found at the following URL:
https://s.apache.org/spark-v2.4.7-rc1

This release is using the release script of the tag v2.4.7-rc1.

FAQ


=
How can I help test this release?
=

If you are a Spark user, you can help us test this release by taking
an existing Spark workload and running on this release candidate, then
reporting any regressions.

If you're working in PySpark you can set up a virtual env and install
the current RC and see if anything important breaks, in the Java/Scala
you can add the staging repository to your projects resolvers and test
with the RC (make sure to clean up the artifact cache before/after so
you don't end up building with an out of date RC going forward).

===
What should happen to JIRA tickets still targeting 2.4.7?
===

The current list of open tickets targeted at 2.4.7 can be found at:
https://issues.apache.org/jira/projects/SPARK and search for "Target
Version/s" = 2.4.7

Committers should look at those and triage. Extremely important bug
fixes, documentation, and API tweaks that impact compatibility should
be worked on immediately. Everything else please retarget to an
appropriate release.

==
But my bug isn't fixed?
==

In order to make timely releases, we will typically not hold the
release unless the bug in question is a regression from the previous
release. That being said, if there is something which is a regression
that has not been correctly targeted please ping me or a committer to
help target the issue.


Re: [VOTE] Release Spark 2.4.7 (RC1)

2020-08-06 Thread Sean Owen
+1 from me. The same as usual. Licenses and sigs look OK, builds and
passes tests on a standard selection of profiles.

On Thu, Aug 6, 2020 at 7:07 AM Prashant Sharma  wrote:
>
> Please vote on releasing the following candidate as Apache Spark version 
> 2.4.7.
>
> The vote is open until Aug 9th at 9AM PST and passes if a majority +1 PMC 
> votes are cast, with a minimum of 3 +1 votes.
>
> [ ] +1 Release this package as Apache Spark 2.4.7
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Spark, please see http://spark.apache.org/
>
> There are currently no issues targeting 2.4.7 (try project = SPARK AND 
> "Target Version/s" = "2.4.7" AND status in (Open, Reopened, "In Progress"))
>
> The tag to be voted on is v2.4.7-rc1 (commit 
> dc04bf53fe821b7a07f817966c6c173f3b3788c6):
> https://github.com/apache/spark/tree/v2.4.7-rc1
>
> The release files, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/spark/v2.4.7-rc1-bin/
>
> Signatures used for Spark RCs can be found in this file:
> https://dist.apache.org/repos/dist/dev/spark/KEYS
>
> The staging repository for this release can be found at:
> https://repository.apache.org/content/repositories/orgapachespark-1352/
>
> The documentation corresponding to this release can be found at:
> https://dist.apache.org/repos/dist/dev/spark/v2.4.7-rc1-docs/
>
> The list of bug fixes going into 2.4.7 can be found at the following URL:
> https://s.apache.org/spark-v2.4.7-rc1
>
> This release is using the release script of the tag v2.4.7-rc1.
>
> FAQ
>
>
> =
> How can I help test this release?
> =
>
> If you are a Spark user, you can help us test this release by taking
> an existing Spark workload and running on this release candidate, then
> reporting any regressions.
>
> If you're working in PySpark you can set up a virtual env and install
> the current RC and see if anything important breaks, in the Java/Scala
> you can add the staging repository to your projects resolvers and test
> with the RC (make sure to clean up the artifact cache before/after so
> you don't end up building with an out of date RC going forward).
>
> ===
> What should happen to JIRA tickets still targeting 2.4.7?
> ===
>
> The current list of open tickets targeted at 2.4.7 can be found at:
> https://issues.apache.org/jira/projects/SPARK and search for "Target 
> Version/s" = 2.4.7
>
> Committers should look at those and triage. Extremely important bug
> fixes, documentation, and API tweaks that impact compatibility should
> be worked on immediately. Everything else please retarget to an
> appropriate release.
>
> ==
> But my bug isn't fixed?
> ==
>
> In order to make timely releases, we will typically not hold the
> release unless the bug in question is a regression from the previous
> release. That being said, if there is something which is a regression
> that has not been correctly targeted please ping me or a committer to
> help target the issue.

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org



Re: Contributing to JIRA Maintenance

2020-08-06 Thread Hyukjin Kwon
I started to get more JIRA notifications which should probably be a good
sign.

Again, thank you so much guys. @Takeshi Yamamuro 
 and @Sean Owen .
Thanks also @Dongjoon Hyun , @Jungtaek Lim
 and @Liang-Chi Hsieh . I
know you guys have been active in JIRA maintenance :-).


I would also like to thank non-committers:

   - Gabor Somogyi
   
   - Jinxin Tang
   
   - Rohit Mishra
   


I will keep monitoring it too.


Thanks.


2020년 8월 1일 (토) 오후 8:05, Hyukjin Kwon 님이 작성:

> Thank you!
>
> On Sat, 1 Aug 2020, 19:31 Takeshi Yamamuro,  wrote:
>
>> Great work and thanks for your JIRA maintenance and this heads-up (sorry
>> for my late reply...)
>> Yea, I noticed that I didn't take much time recently on the JIRA side.
>> So, I will take more care about it from now on for the community's help.
>>
>> On Wed, Jul 29, 2020 at 10:52 AM Hyukjin Kwon 
>> wrote:
>>
>>> Yeah, to contribute to JIRA maintenance, it does not need a lot of codes
>>> given my experience.
>>>
>>> Just to share my own story:
>>> 4 years ago when I was one of contributors, I have been looking for many
>>> other ways around to
>>> contribute to Spark. I noticed Sean was making exceptional
>>> efforts in the JIRA maintenance
>>> contribution - he monitored JIRAs basically 24/7. I started to make
>>> sustained efforts and contributions
>>> there when he asked some help in the dev mailing list. I also did some
>>> code work but my JIRA
>>> maintenance contribution is also one of the important community
>>> activities.
>>> This was appropriately considered and recognised by other PMCs.
>>>
>>> The commit bit. Probably the ideal case is to have contributions in
>>> balance across many
>>> aspects. But If somebody makes a lot of sustained efforts and
>>> contributions to one
>>> aspect, this can be also the case we take into account. Yeah, I think
>>> Shane is a good example.
>>>
>>>
>>> 2020년 7월 29일 (수) 오전 2:57, Rohit Mishra 님이 작성:
>>>
 Thanks Sean for your elaborate and valuable explanation. I will look
 into it from tomorrow and will reach out if required.

 Have a good day.

 Regards,
 Rohit Mishra

 On Tue, 28 Jul 2020 at 11:20 PM, Sean Owen  wrote:

> To help with JIRA, I don't think you need to know a lot about the code
> structure. I think we're talking about more basic triage, like, is it
> a question that should go to the mailing list instead? is there enough
> detail to understand it at all? is it tagged with a few appropriate
> components, does its affected version make sense?  Finding duplicate
> issues is hard but quite valuable if you can identify related issues
> and mark them.
>
> I can also tell you about using the JIRA Client to search for issues
> that don't make much sense, like, open and targeting a released
> version.
>
> Actually I think anyone can modify issues in JIRA, so you don't need
> special permission. You could consult with me or Hyukjin or dev@ after
> making a few changes to check if they're on the right track.
>
> iss...@spark.apache.org (IIRC) gets a copy of all the JIRA emails
> about changes. I don't know if it's that useful to subscribe to.
>
> Documenting the code structure - might be kind of hard in any detail,
> but if you put together a doc that is useful and doesn't require a lot
> of maintenance, that gives a good overview, we could consider adding
> that to the developer docs.
>
>
>
> On Tue, Jul 28, 2020 at 12:16 PM Rohit Mishra <
> rohitmishr1...@gmail.com> wrote:
> >
> > Hello All,
> >
> > I have recently joined the Dev mailing list to help the community.
> Since I am in my attempt to understand the code base before contributing, 
> I
> think looking into Jira maintenance will be a good way to help. I will
> start looking into it. Do I need anyone’s approval?
> >
> > In case I need any help in the beginning can I mail here or there is
> a separate mailing id related to Jira maintenance?
> >
> > Just a trivial question- Do we have any document to give an overview
> of the code structure for newbie like me, I can create one if there isn’t
> any.
> >
> > Thanks,
> > Rohit Mishra
> >
> > On Tue, 28 Jul 2020 at 6:46 PM, Sean Owen  wrote:
> >>
> >> Thanks for doing this - and I will say this is a great way for
> anyone
> >> out there to contribute directly to the project. Issue trackers need
> >> maintenance too. It's not that hard to spot basic problems with
> JIRAs
> >> and request fixes, as a way to engage the reporter usefully.
> >>
> >> I triage PRs but rarely look at JIRAs anymore, just because the
> volume
> >> and no