spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dongjoon Hyun <dongjoon.h...@gmail.com>
Subject Re: Resolving all JIRAs affecting EOL releases
Date Sat, 18 May 2019 03:22:29 GMT
+1, too.

Thank you, Hyukjin!

Bests,
Dongjoon.


On Fri, May 17, 2019 at 9:07 AM Imran Rashid <irashid@cloudera.com.invalid>
wrote:

> +1, thanks for taking this on
>
> On Wed, May 15, 2019 at 7:26 PM Hyukjin Kwon <gurwls223@gmail.com> wrote:
>
>> oh, wait. 'Incomplete' can still make sense in this way then.
>> Yes, I am good with 'Incomplete' too.
>>
>> 2019년 5월 16일 (목) 오전 11:24, Hyukjin Kwon <gurwls223@gmail.com>님이
작성:
>>
>>> 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