Re: Policy around backporting bug fixes

2015-07-27 Thread Sean Owen
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



Policy around backporting bug fixes

2015-07-24 Thread Patrick Wendell
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