spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <gurwls...@gmail.com>
Subject Re: [DISCUSS] filling affected versions on JIRA issue
Date Thu, 02 Apr 2020 01:58:42 GMT
> 2) check with older versions to fill up affects version for bug
I don't agree with this in general. To me usually it's "For the type of
bug, assign one valid version" instead.

> The only place where I can see some amount of investigation being
required would be for security issues or correctness issues.
Yes, I agree.

Yes, was there a particular case or context that motivated this thread?

2020년 4월 2일 (목) 오전 10:24, Mridul Muralidharan <mridul@gmail.com>님이 작성:

>
> I agree with what Sean detailed.
> The only place where I can see some amount of investigation being required
> would be for security issues or correctness issues.
> Knowing the affected versions, particularly if an earlier supported
> version does not have the bug, will help users understand the
> broken/insecure versions.
>
> Regards,
> Mridul
>
>
> On Wed, Apr 1, 2020 at 6:12 PM Sean Owen <srowen@gmail.com> wrote:
>
>> I think we discussed this briefly on a PR.
>>
>> It's not as clear what it means for an Improvement to 'affect a
>> version'. Certainly, an improvement to a feature introduced in 1.2.3
>> can't affect anything earlier, and implicitly affects everything
>> after. It's not wrong to say it affects the latest version, at least.
>> And I believe we require it in JIRA because we can't require an
>> Affects Version for one type of issue but not another. So, just asking
>> people to default to 'latest version' there is no burden.
>>
>> I would not ask someone to figure out all and earliest versions that
>> an Improvement applies to; it just isn't that useful. We aren't
>> generally going to back-port improvements anyway.
>>
>> Even for bugs, we don't really need to know that a bug in master
>> affects 2.4.5, 2.4.4, 2.4.3, ... 2.3.6, 2.3.5, etc. It doesn't hurt to
>> at least say it affects the latest 2.4.x, 2.3.x releases, if known,
>> because it's possible it should be back-ported. Again even where this
>> is significantly more useful, I'm not in favor of telling people they
>> must test the bug report vs previous releases.
>>
>> So, if you're asserting that the current guidance is OK, I generally
>> agree.
>> Is there a particular context where this was questioned? maybe we
>> should examine the particulars of that situation. As in all things,
>> context matters.
>>
>> Sean
>>
>> On Wed, Apr 1, 2020 at 7:34 PM Jungtaek Lim
>> <kabhwan.opensource@gmail.com> wrote:
>> >
>> > Hi devs,
>> >
>> > I know we're busy with making Spark 3.0 be out, but I think the topic
>> is good to discuss at any time and actually be better to be resolved sooner
>> than later.
>> >
>> > In the page "Contributing to Spark", we describe the guide of "affects
>> version" as "For Bugs, assign at least one version that is known to exhibit
>> the problem or need the change".
>> >
>> > For me, that sentence clearly describes minimal requirement of affects
>> version via:
>> >
>> > * For the type of bug, assign one valid version
>> > * For other types, there's no requirement
>> >
>> > but I'm seeing the requests more than the requirement which makes me
>> think there might be different understanding of the sentence. Maybe there's
>> more, but to summarize on such requests:
>> >
>> > 1) add affects version as same as master branch for improvement/new
>> feature
>> > 2) check with older versions to fill up affects version for bug
>> >
>> > I don't see any point on doing 1). It might give some context if we
>> don't update the affect version (so that it can say which version was
>> considered when filing JIRA issue) but we also update the affect version
>> when we bump the master branch, which is no longer informational as the
>> version should have been always the same as master branch.
>> >
>> > I agree it's ideal to do 2) but I think the reason the guide doesn't
>> enforce is that it requires pretty much efforts to check with old versions
>> (sometimes even more than origin work).
>> >
>> > Suppose the happy case we have UT to verify the bugfix which fails
>> without the patch and passes with the patch. To check with older versions
>> we have to checkout the tag, and apply the UT, and "rebuild", and run UT to
>> verify which is pretty much time-consuming. What if there's a conflict
>> indeed? That's still a happy case, and in worse case (there's no such UT)
>> we should do E2E manual verification which I would give up.
>> >
>> > There should have some balance/threshold, and the balance should be the
>> thing the community has a consensus.
>> >
>> > Would like to hear everyone's voice on this.
>> >
>> > Thanks,
>> > Jungtaek Lim (HeartSaVioR)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
>>
>>

Mime
View raw message