spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: [DISCUSS] filling affected versions on JIRA issue
Date Thu, 02 Apr 2020 01:11:51 GMT
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.


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
> 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