You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Sandeep Moré <mo...@gmail.com> on 2022/01/21 17:12:06 UTC
[DISCUSS] Feature branch for Webshell feature
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
Re: [DISCUSS] Feature branch for Webshell feature
Posted by Phil Zampino <pz...@apache.org>.
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é <mo...@gmail.com> 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
>
Re: [DISCUSS] Feature branch for Webshell feature
Posted by larry mccay <lm...@apache.org>.
Good deal!
@Lu Liu <ll...@gmail.com> - thank you for starting this work in your
PR and look forward to your continued contributions on the branch!
Let's come up with a process and workflow for working in feature branches
that will:
1. encourage it to close and merge to main without being tempted to work
there forever making merge too difficult
2. a description of a workflow from github that will allow contributors to
the branch work efficiently
3. guidelines to achieve reviews on PRs to the branch and for reviewing and
testing the whole for merge to main
On Mon, Jan 24, 2022 at 3:47 PM Sandeep Moré <mo...@gmail.com> wrote:
> Folks,
> We have a new branch "webshell" with commit history from PR
> https://github.com/apache/knox/pull/477
> let me know if anyone has questions or concerns.
>
> Best,
> Sandeep
>
>
> On Fri, Jan 21, 2022 at 2:24 PM Sandeep Moré <mo...@gmail.com>
> wrote:
>
> > 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 <lm...@apache.org> 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é <mo...@gmail.com>
> >> 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
> >> >
> >>
> >
>
Re: [DISCUSS] Feature branch for Webshell feature
Posted by Sandeep Moré <mo...@gmail.com>.
Folks,
We have a new branch "webshell" with commit history from PR
https://github.com/apache/knox/pull/477
let me know if anyone has questions or concerns.
Best,
Sandeep
On Fri, Jan 21, 2022 at 2:24 PM Sandeep Moré <mo...@gmail.com> wrote:
> 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 <lm...@apache.org> 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é <mo...@gmail.com>
>> 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
>> >
>>
>
Re: [DISCUSS] Feature branch for Webshell feature
Posted by Sandeep Moré <mo...@gmail.com>.
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 <lm...@apache.org> 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é <mo...@gmail.com>
> 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
> >
>
Re: [DISCUSS] Feature branch for Webshell feature
Posted by larry mccay <lm...@apache.org>.
+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é <mo...@gmail.com> 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
>