Thank you for kicking off this discussion. I'm in favor of the feature branch for this work, for all the reasons you've enumerated. So long as we can preserve the existing review questions/comments from the fork, I don't think we need to resolve any of those concerns before moving into a feature branch where those concerns can still be addressed prior to merging the feature branch into master.
As an alternative to the double merge requirement, could the feature branch rather be rebased periodically? I haven't thoroughly thought through whether or not this is actually better. 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 >
