I took the liberty of adding this to the wiki, where it can change further if needed.
https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-PolicyonBackportingBugFixes On Fri, Jul 24, 2015 at 8:57 PM, Patrick Wendell <pwend...@gmail.com> wrote: > Hi All, > > A few times I've been asked about backporting and when to backport and > not backport fix patches. Since I have managed this for many of the > past releases, I wanted to point out the way I have been thinking > about it. If we have some consensus I can put it on the wiki. > > The trade off when backporting is you get to deliver the fix to people > running older versions (great!), but you risk introducing new or even > worse bugs in maintenance releases (bad!). The decision point is when > you have a bug fix and it's not clear whether it is worth backporting. > > I think the following facets are important to consider: > (a) Backports are an extremely valuable service to the community and > should be considered for any bug fix. > (b) Introducing a new bug in a maintenance release must be avoided at > all costs. It over time would erode confidence in our release process. > (c) Distributions or advanced users can always backport risky patches > on their own, if they see fit. > > For me, the consequence of these is that we should backport in the > following situations: > - Both the bug and the fix are well understood and isolated. Code > being modified is well tested. > - The bug being addressed is high priority to the community. > - The backported fix does not vary widely from the master branch fix. > > We tend to avoid backports in the converse situations: > - The bug or fix are not well understood. For instance, it relates to > interactions between complex components or third party libraries (e.g. > Hadoop libraries). The code is not well tested outside of the > immediate bug being fixed. > - The bug is not clearly a high priority for the community. > - The backported fix is widely different from the master branch fix. > > These are clearly subjective criteria, but ones worth considering. I > am always happy to help advise people on specific patches if they want > a soundingboard to understand whether it makes sense to backport. > > - Patrick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > For additional commands, e-mail: dev-h...@spark.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
