Thanks Larry and Phil, Makes sense, we could simply rebase the feature branch periodically and keep it in sync (as Phil pointed out - which would be what we do with the fork currently).
Thanks for the inputs! On Fri, Jan 21, 2022 at 1:32 PM larry mccay <[email protected]> wrote: > +1 to the feature branch plan in general! > > I am -0 on double commits to the feature branch from master. > It seems to me that syncing the feature branch is going to be more or less > what is happening in the forks now but the other benefits to having a > central feature branch here still add significant value. > > Having to do the sync is a pain but I don't think we should make it easy to > keep a feature branch. > Maybe that same argument can be used for justifying double commits though. > :) > > Hadoop has feature branches as an optional part of their official process. > We can consider the flow detailed in [1] and there may be other details > that I will look for. > > 1. https://cwiki.apache.org/confluence/display/HADOOP2/HowToCommit > > On Fri, Jan 21, 2022 at 12:12 PM Sandeep Moré <[email protected]> > wrote: > > > All, > > I would like to get community input on the process of merging Webshell > > feature to master. > > > > *Problem*: > > 1. We would like to get this feature in by 2.0 but also would like to > make > > sure we get a proper reviews for this feature. > > 2. Given the size of the feature, keeping it up to date with recent > commits > > (rebasing) is getting problematic. > > 3. It appears that this feature will require collaboration from multiple > > developers so having the feature in local repo is not ideal. > > > > *Proposal*: > > Size and scope of this feature justifies creating a feature branch. The > > idea is to create a feature branch in Apache Knox repo for this feature > > (e,g, Webshell). Merge the existing PR fork ( > > https://github.com/apache/knox/pull/477) to this branch so multiple > > developers can contribute to it with their own PRs (fixes/tasks). Doing > > this will make sure we attribute code correctly to the developers who > > contributed it and simplify the development process. > > > > Also, until this feature branch is active we would encourage (prefer, > > really) developers to double commit to this feature branch and to master > > branch. I understand this is not ideal but I am hoping we can bear the > pain > > for a short time until we release the feature. > > > > Any thoughts and ideas would be greatly welcomed. > > > > Best, > > Sandeep > > >
