You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by Pramod Immaneni <pr...@datatorrent.com> on 2017/01/27 16:43:13 UTC
[DISCUSS] Policy for patches
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
Re: [DISCUSS] Policy for patches
Posted by Pramod Immaneni <pr...@datatorrent.com>.
You make some fair points, a contributor may not want to submit patches for
all release branches but the community can pick it up as a policy. In many
cases, it might be as simple as the reviewer cherry picking the fix onto
the other branches. In cases where it is not trivial and the reviewer or
somebody in the community cannot help out at that time, we can put in the
backlog till somebody picks it up and possibly use JIRA to track this
backlog.
On Sun, Jan 29, 2017 at 11:22 AM, Thomas Weise <th...@apache.org> wrote:
> The problem with this discussion is that it assumes that a policy could be
> established to apply patches. Any form of contribution to the project is
> volunteer work, so this is a no starter.
>
> For example, if someone contributes a patch, then there is no way to
> enforce contribution of the patch for multiple branches. A contributor may
> do it due to other interests (like the vendor having to support a customer
> on that code base), another contributor may have no such incentive.
> Likewise the committer reviewing the work cannot be forced to repeat the
> same for multiple branches.
>
> I would like to see vendor motivation cleanly separated from community
> concerns.
>
> Perhaps it makes sense to come up with recommendations or guidelines around
> this though. For example there is in general little incentive for the
> community to release from outdated branches or to release code with known
> issues such as CVE. And there is a release process and vote to deal with
> it.
>
> For example, one could recommend to not maintain a minor release branch
> after there have been n (2?) more recent minor or major releases. Or that
> we don't want maintenance releases for minor releases that have security
> issues.
>
> Looking at the current situation, I think that 3.2 and 3.3. could be
> considered obsolete from community perspective (which does not stop a
> vendor to add patches and consume it for their purposes).
>
> Soon (maybe when 3.6 is out?) there should be little reason to maintain 3.4
> (3.5 is backward compatible and users should be incentivised to move up).
>
> I also think that under the current contribution guidelines there is no
> need to remove branches (even when they are fully reflected in tags). See
> apex-core repository.
>
> I do think however that it may be good to clean up the pre ASF branches in
> apex-malhar.
>
> Thomas
>
>
>
> On Fri, Jan 27, 2017 at 11:04 AM, Vlad Rozov <v....@datatorrent.com>
> wrote:
>
> > I prefer to go with the second approach as well.
> >
> > My preference is to go not with a strict end of life policy, but by
> > severity of an issue and complexity of providing fixes for all subsequent
> > releases. In a case a contributor decides to fix a bug in
> > an old release, she will need to provide the fix for many branches. It is
> > unlikely that such work will be done without justification.
> >
> > I am strongly against deleting old branches:
> > - they preserve history.
> > - I am not 100% sure, but it is likely against ASF policy. Any
> > contribution to a project needs to be preserved (including author of a
> > commit).
> > - It does not cost much to have branches in remote git repository and it
> > does not affect git operations
> > - It is not necessary to load all branches into local repository
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 1/27/17 10:16, Sanjay Pujare wrote:
> >
> >> 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" <pr...@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
> >>
> >>
> >>
> >
>
Re: [DISCUSS] Policy for patches
Posted by Thomas Weise <th...@apache.org>.
The problem with this discussion is that it assumes that a policy could be
established to apply patches. Any form of contribution to the project is
volunteer work, so this is a no starter.
For example, if someone contributes a patch, then there is no way to
enforce contribution of the patch for multiple branches. A contributor may
do it due to other interests (like the vendor having to support a customer
on that code base), another contributor may have no such incentive.
Likewise the committer reviewing the work cannot be forced to repeat the
same for multiple branches.
I would like to see vendor motivation cleanly separated from community
concerns.
Perhaps it makes sense to come up with recommendations or guidelines around
this though. For example there is in general little incentive for the
community to release from outdated branches or to release code with known
issues such as CVE. And there is a release process and vote to deal with it.
For example, one could recommend to not maintain a minor release branch
after there have been n (2?) more recent minor or major releases. Or that
we don't want maintenance releases for minor releases that have security
issues.
Looking at the current situation, I think that 3.2 and 3.3. could be
considered obsolete from community perspective (which does not stop a
vendor to add patches and consume it for their purposes).
Soon (maybe when 3.6 is out?) there should be little reason to maintain 3.4
(3.5 is backward compatible and users should be incentivised to move up).
I also think that under the current contribution guidelines there is no
need to remove branches (even when they are fully reflected in tags). See
apex-core repository.
I do think however that it may be good to clean up the pre ASF branches in
apex-malhar.
Thomas
On Fri, Jan 27, 2017 at 11:04 AM, Vlad Rozov <v....@datatorrent.com>
wrote:
> I prefer to go with the second approach as well.
>
> My preference is to go not with a strict end of life policy, but by
> severity of an issue and complexity of providing fixes for all subsequent
> releases. In a case a contributor decides to fix a bug in
> an old release, she will need to provide the fix for many branches. It is
> unlikely that such work will be done without justification.
>
> I am strongly against deleting old branches:
> - they preserve history.
> - I am not 100% sure, but it is likely against ASF policy. Any
> contribution to a project needs to be preserved (including author of a
> commit).
> - It does not cost much to have branches in remote git repository and it
> does not affect git operations
> - It is not necessary to load all branches into local repository
>
> Thank you,
>
> Vlad
>
>
> On 1/27/17 10:16, Sanjay Pujare wrote:
>
>> 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" <pr...@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
>>
>>
>>
>
Re: [DISCUSS] Policy for patches
Posted by Vlad Rozov <v....@datatorrent.com>.
I prefer to go with the second approach as well.
My preference is to go not with a strict end of life policy, but by
severity of an issue and complexity of providing fixes for all
subsequent releases. In a case a contributor decides to fix a bug in
an old release, she will need to provide the fix for many branches. It
is unlikely that such work will be done without justification.
I am strongly against deleting old branches:
- they preserve history.
- I am not 100% sure, but it is likely against ASF policy. Any
contribution to a project needs to be preserved (including author of a
commit).
- It does not cost much to have branches in remote git repository and it
does not affect git operations
- It is not necessary to load all branches into local repository
Thank you,
Vlad
On 1/27/17 10:16, Sanjay Pujare wrote:
> A strong +1 for the second approach for the reasons Pramod mentioned.
>
> Is it also possible to \u201cprune\u201d 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, \u2026 telecom most probably are not being used by anybody.
>
> On 1/27/17, 8:43 AM, "Pramod Immaneni" <pr...@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
>
>
>
Re: [DISCUSS] Policy for patches
Posted by Matt Zhang <ma...@datatorrent.com>.
+1 for 2nd approach. We can omit those frozen branches and maintain only
active branches.
Thanks,
Matt
On Fri, Jan 27, 2017 at 10:16 AM, Sanjay Pujare <sa...@datatorrent.com>
wrote:
> 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" <pr...@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
>
>
>
>
Re: [DISCUSS] Policy for patches
Posted by Sanjay Pujare <sa...@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" <pr...@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