apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Zhang <m...@datatorrent.com>
Subject Re: [DISCUSS] Policy for patches
Date Fri, 27 Jan 2017 18:19:59 GMT
+1 for 2nd approach. We can omit those frozen branches and maintain only
active branches.


On Fri, Jan 27, 2017 at 10:16 AM, Sanjay Pujare <sanjay@datatorrent.com>

> A strong +1 for the second approach for the reasons Pramod mentioned.
> Is it also possible to “prune” branches so that we have less of this
> activity of merging fixes across branches? If we can ascertain that a
> certain branch is not used by any user/customer (by asking in the
> community) we should be able to remove it. For example, apex-malhar has
> release-3.6 which is definitely required but 3 year old branches like
> release-0.8.5, release-0.9.0, … telecom most probably are not being used by
> anybody.
> On 1/27/17, 8:43 AM, "Pramod Immaneni" <pramod@datatorrent.com> wrote:
>     Hi,
>     I wanted to bring up the topic of patches for issues discovered in
> older
>     releases and start a discussion to come up with a policy on how to
> apply
>     them.
>     One approach is the patch gets only applied to the release it was
>     discovered in and master. Another approach is it gets applied to all
>     release branches >= discovered release and master. There may be other
>     approaches as well which can come up in this discussion.
>     The advantage of the first approach is that the immediate work is
> limited
>     to a single fix and merge. The second approach requires more work
> initially
>     as the patch needs to get applied to more one or more places.
>     I am tending towards the second approach of applying the fix to all
> release
>     branches >= discovered release, while also having some sort of an end
> of
>     life policy for releases otherwise it might become difficult to manage
> the
>     fixes. The end of life policy would mean that beyond a time period
>     (something reasonable period between 1 - 3 years) after the release is
> made
>     the release branch become frozen and no more fixes are applied to it.
>     Consider the following two problematic scenarios if we apply the fix
> only
>     to the one discovered release.
>        - Let's say tomorrow a new fix needs to be made to a newer release
>        branch (which had existed at the time of the fix) that is dependent
> on the
>        current fix. Before applying the new fix one would need to first
> know to
>        cherry-pick the old fix (may not be trivial to know this) and
> second and
>        more important there could be merge conflicts when cherry-picking.
> At this
>        point, you may be trying to resolve the conflicts where you may not
> be the
>        primary author of the fix and/or the knowledge of the fix is no
> longer
>        fresh in folks minds. This is prone to errors.
>        - Let's call this fix a. Let's say there was another fix b.
> requiring a.
>        to work correctly also on the same release branch but no compile
>        dependencies on a. If in future we have a fix c. that depends on b.
> that
>        needs to be applied on a different release branch both b. and a.
> would need
>        to be cherry picked. It might be easy to figure out b. is needed,
> as c. has
>        a direct dependency to it but would not be easy to determine that
> a. is
>        also needed since that is old knowledge. It will not be easy to
> catch this
>        omission because of no compile errors if a. is not included.
>     Thanks

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message