I don't think we've been great about backporting correctness issues. This is one example which comes to mind (not to point fingers, just the one I know of immediately):
https://issues.apache.org/jira/browse/SPARK-23207 we also let another related issue slide for quite a while: https://issues.apache.org/jira/browse/SPARK-23243 it turns out that issue was actually extremely tricky, so its not because it got totally ignored -- but on the other hand, maybe it didn't really get quite the attention it deserved. Using the jira label is good -- should we also have a message to dev, with [CORRECTNESS-BUG] or something in the subject line when an issue like this is discovered, to raise the profile? (I realize you could get the same info from jira, but with so much jira volume, maybe its worth an extra mode.) > Do we need more committers? Fewer new features? More conservative releases? Less work on X to work on this? this is a good question. More committers would be good to take on the volume of things to be done, but the flipside of this is that we need to make sure committers can do thorough reviews in the first place to prevent these types of bugs, and respond to them when they show up. But its also worth noting this bug was *not* introduced by somebody inexperienced -- its been around for a long time, and lots of experienced devs have managed to overlook it: https://github.com/apache/spark/commit/7d9cc9214bd06495f6838e355331dd 2b5f1f7407 Really, I'd like to see committers (and folks that want to be committers) realize they sometimes have to set aside their feature work to take on the these more important things, even if it means their features slip a release. In practice, this means fewer new features. So I do think we should be working to bring on more committers, but we have to make sure we're not losing sight of these things. On Mon, Aug 13, 2018 at 9:03 AM, Sean Owen <sro...@gmail.com> wrote: > I doubt the question is whether people want to take such issues seriously > -- all else equal, of course everyone does. > > A JIRA label plus place in the release notes sounds like a good concrete > step that isn't happening consistently now. That's a clear flag that at > least one person believes issue X is a blocker. > > Is this about specific JIRAs? I think it's more useful to illustrate in > the context of specific issues. For example I haven't been following JIRAs > well, and don't know what is being contested here. > > I share frustration that Somebody should be working on Important Things, > but don't think the difference between getting those done and not done is > reminding people that Important Things need doing. What's the cause that > leads to concrete corrective action? > > Do we need more committers? Fewer new features? More conservative > releases? Less work on X to work on this? > > Lastly you raise an important question as an aside, one we haven't > answered: when does a branch go inactive? I am sure 2.0.x is inactive, de > facto, along with all 1.x. I think 2.1.x is inactive too. Should we put any > rough guidance in place? a branch is maintained for 12-18 months? > > > > > On Mon, Aug 13, 2018 at 8:45 AM Tom Graves <tgraves...@yahoo.com.invalid> > wrote: > >> Hello all, >> >> I've noticed some inconsistencies in the way we are handling data >> loss/correctness issues. I think we need to take these very seriously as >> they >> could be causing businesses real money and impacting real decisions and >> business logic. I would like to discuss how we can make sure these are >> handled consistently and with urgency going forward. >> >> A few things I would like to propose are below. Most of these are up to >> the developers and committers to ensure happen so want to know what >> everyone thinks and if people have other ideas? >> >> - label any correctness/data loss jira with "correctness" >> - jira marked as blocker by default if someone suspects a corruption/loss >> issue >> - Make sure description is clear about when it occurs and impact to the >> user. >> - ensure its back ported to all active branches >> - See if we can have a separate section in the release notes for these >> >> >> Thanks, >> Tom Graves >> >
