spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Chammas <>
Subject Re: [DISCUSS] filling affected versions on JIRA issue
Date Thu, 02 Apr 2020 02:43:05 GMT
Probably the discussion here about Improvement Jira tickets and the
"Affects Version" field:

On Wed, Apr 1, 2020 at 9:59 PM Hyukjin Kwon <> wrote:

> > 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 <>님이
>> 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 <> 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
>>> <> 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:

View raw message