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