Probably the discussion here about Improvement Jira tickets and the "Affects Version" field: https://github.com/apache/spark/pull/27534#issuecomment-588416416
On Wed, Apr 1, 2020 at 9:59 PM Hyukjin Kwon <gurwls...@gmail.com> 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 <mri...@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 <sro...@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.opensou...@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-unsubscr...@spark.apache.org >>> >>>
