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 <t...@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.ro...@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" <pra...@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 > >> > >> > >> > > >
