spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <gurwls...@gmail.com>
Subject Re: Resolving all JIRAs affecting EOL releases
Date Thu, 16 May 2019 02:24:16 GMT
I actually recently used 'Incomplete'  a bit when the JIRA is basically too
poorly formed (like just copying and pasting an error) ...

I was thinking about 'Unresolved' status or `Auto Closed' too. I double
checked they can be reopen as well after resolution.

[image: Screen Shot 2019-05-16 at 10.35.14 AM.png]
[image: Screen Shot 2019-05-16 at 10.35.39 AM.png]

2019년 5월 16일 (목) 오전 11:04, Sean Owen <srowen@gmail.com>님이 작성:

> Agree, anything without an Affected Version should be old enough to time
> out.
> I might use "Incomplete" or something as the status, as we haven't
> otherwise used that. Maybe that's simpler than a label. But, anything like
> that sounds good.
>
> On Wed, May 15, 2019 at 8:40 PM Hyukjin Kwon <gurwls223@gmail.com> wrote:
>
>> BTW, affected version became a required field (I don't remember when
>> exactly was .. I believe it's around when we work on Spark 2.3):
>>
>> [image: Screen Shot 2019-05-16 at 10.29.50 AM.png]
>>
>> So, including all EOL versions and affected versions not specified will
>> roughly work.
>> Using "Cannot Reproduce" as its status and 'bulk-closed' label makes the
>> best sense to me.
>>
>> Okie. I want to open this roughly for a week before taking an actual
>> action for this. If there's no more feedback, I will do as I said ^ next
>> week.
>>
>>
>> 2019년 5월 15일 (수) 오후 11:33, Josh Rosen <rosenville@gmail.com>님이
작성:
>>
>>> +1 in favor of some sort of JIRA cleanup.
>>>
>>> My only request is that we attach some sort of 'bulk-closed' label to
>>> issues that we close via JIRA filter batch operations (and resolve the
>>> issues as "Timed Out" / "Cannot Reproduce", not "Fixed"). Using a label
>>> makes it easier to audit what was closed, simplifying the process of
>>> identifying and re-opening valid issues caught in our dragnet.
>>>
>>>
>>> On Wed, May 15, 2019 at 7:19 AM Sean Owen <srowen@gmail.com> wrote:
>>>
>>>> I gave up looking through JIRAs a long time ago, so, big respect for
>>>> continuing to try to triage them. I am afraid we're missing a few
>>>> important bug reports in the torrent, but most JIRAs are not
>>>> well-formed, just questions, stale, or simply things that won't be
>>>> added. I do think it's important to reflect that reality, and so I'm
>>>> always in favor of more aggressively closing JIRAs. I think this is
>>>> more standard practice, from projects like TensorFlow/Keras, pandas,
>>>> etc to just automatically drop Issues that don't see activity for N
>>>> days. We won't do that, but, are probably on the other hand far too
>>>> lax in closing them.
>>>>
>>>> Remember that JIRAs stay searchable and can be reopened, so it's not
>>>> like we lose much information.
>>>>
>>>> I'd close anything that hasn't had activity in 2 years (?), as a start.
>>>> I like the idea of closing things that only affect an EOL release,
>>>> but, many items aren't marked, so may need to cast the net wider.
>>>>
>>>> I think only then does it make sense to look at bothering to reproduce
>>>> or evaluate the 1000s that will still remain.
>>>>
>>>> On Wed, May 15, 2019 at 4:25 AM Hyukjin Kwon <gurwls223@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > I would like to propose to resolve all JIRAs that affects EOL
>>>> releases - 2.2 and below. and affected version
>>>> > not specified. I was rather against this way and considered this as
>>>> last resort in roughly 3 years ago
>>>> > when we discussed. Now I think we should go ahead with this. See
>>>> below.
>>>> >
>>>> > I have been talking care of this for so long time almost every day
>>>> those 3 years. The number of JIRAs
>>>> > keeps increasing and it does never go down. Now the number is going
>>>> over 2500 JIRAs.
>>>> > Did you guys know? in JIRA, we can only go through page by page up to
>>>> 1000 items. So, currently we're even
>>>> > having difficulties to go through every JIRA. We should manually
>>>> filter out and check each.
>>>> > The number is going over the manageable size.
>>>> >
>>>> > I am not suggesting this without anything actually trying. This is
>>>> what we have tried within my visibility:
>>>> >
>>>> >   1. In roughly 3 years ago, Sean tried to gather committers and even
>>>> non-committers people to sort
>>>> >     out this number. At that time, we were only able to keep this
>>>> number as is. After we lost this momentum,
>>>> >     it kept increasing back.
>>>> >   2. At least I scanned _all_ the previous JIRAs at least more than
>>>> two times and resolved them. Roughly
>>>> >     once a year. The rest of them are mostly obsolete but not enough
>>>> information to investigate further.
>>>> >   3. I strictly stick to "Contributing to JIRA Maintenance"
>>>> https://spark.apache.org/contributing.html and
>>>> >     resolve JIRAs.
>>>> >   4. Promoting other people to comment on JIRA or actively resolve
>>>> them.
>>>> >
>>>> > One of the facts I realised is the increasing number of committers
>>>> doesn't virtually help this much (although
>>>> > it might be helpful if somebody active in JIRA becomes a committer.)
>>>> >
>>>> > One of the important thing I should note is that, it's now almost
>>>> pretty difficult to reproduce and test the
>>>> > issues found in EOL releases. We should git clone, checkout, build
>>>> and test. And then, see if that issue
>>>> > still exists in upstream, and fix. This is non-trivial overhead.
>>>> >
>>>> > Therefore, I would like to propose resolving _all_ the JIRAs that
>>>> targets EOL releases - 2.2 and below.
>>>> > Please let me know if anyone has some concerns or objections.
>>>> >
>>>> > Thanks.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
>>>>
>>>>

Mime
View raw message