Re: [che-dev] Long-lived Branches / PRs

[Tyler Jewell <tyler@xxxxxxxxxxx>]

My concern is two-fold:

1. Should all long-lived branches that have multiple people collaborate together use branch-PRs?

2. Should branch-PRs have a different policy for acceptance, review and merge into a branch?

There have been a dozen or so branch-PRs that have been made against the openshift branch.  A couple weeks ago, one of these PRs started to make some material changes to the nature of how workspace containers should be configured and set up.  This PR made changes necessary for the openshift branch, but it's not clear that it would be appropriate for the master branch.  

The branch maintainers wanted and opted to merge the branch early wanting to defer analysis for master later on.  I raised some concerns - implying that the openshift branch, which now has a very large set of long-lived changes will have to have a complete review cycle before it is merged into master.  Master maintainers are not able to use the history of branch-PR merges as a record of analysis that means the overall branchis suitable for merge into master.

An example of a simple branch PR (someone asked) was opened this morning - https://github.com/eclipse/che/pull/4750#issuecomment-292935001

So, I think it is good to discuss and determine the role of branch-PRs for long-lived branches, and then the merge + review + documentation requirements for merging branch-PRs.

Tyler Jewell // CEO // tyler@​codenvy.​com // 978.884.5355

On Mon, Apr 10, 2017 at 5:10 AM, Gennady Azarenkov <gazarenkov@xxxxxxxxxxx> wrote:

@Alex

Yes, I understand that PR is a useful mechanism for reviewing and discussion and I probably was not that clear in definitions making my comment.

I agree, let's have WorkInProgress PRs (I would better use dedicated label then [WIP] in its name) and they can be added to "branches" category - i.e. no problem to have a lot of them in contrast PRs which goal is to be merged predictable quickly.

Gennady Azarenkov - @ codenvy.com

On Mon, Apr 10, 2017 at 11:14 AM, Alexander Garagatyi <agaragatyi@xxxxxxxxxxx> wrote:

Sometimes it is needed to get feedback from maintainers/other contributors on design of a feature or improvement. Since the project is complex it can be hard to be sure that you go in correct direction. 

And sharing diff doesn't help in cases when different contributors have different opinions on a PR subject. In this case work-in-progress PRs look helpful to me. 

-----

Alexander Garagatyi | Software Engineer | agaragatyi@​codenvy.​com

On Mon, Apr 10, 2017 at 11:07 AM, Gennady Azarenkov <gazarenkov@xxxxxxxxxxx> wrote:

General note: being a big fan of processes which simplifies routine, communication and coordination, I have some concerns with requests to put unified rules on branches as it may kill innovations. 

Just to add some context to this conversation, I tend to really differentiate between branches and PRs:

- I would not say the long lived branches are the problems *itself*, it is reasonable mechanism for having collaborative development and for keeping sources updated with master (including long-lived case). I would not say other than "good communication" rule should be applied

- I do not think "under development" branches should normally be transformed to PRs. I.e. they become PRs only if author believe they are ready to merge. So, "under development", long-lived PRs are not really desirable and PRs in general can be a subject of more strict rules.

Gennady    

Gennady Azarenkov - @ codenvy.com

On Sun, Apr 9, 2017 at 6:49 PM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote:

This week on the planning call, I would like to discuss our policy and practices for long-lived branches.

A long-lived branch is one where:
1. It spans > 2 releases (more than a month), which triggers frequent rebasing.

2. Has multiple contributors.

3. May be using PRs as a way to coordinate changes to the branch itself.

In some cases, engineers are contributing to long-lived branches directly with commits. We have also had a couple scenarios where PRs are being used to track contributions into the branch itself. Since the PRs are going into a branch that is not master, they have had a different standard of review and acceptance applied.  The longer the branch lives, the potentially harder it will be for that branch to get merged into master.

Another scenario is that we have had some PRs opened which challenges the design of the system - either alters the original design intent, affects the infrastructure, or alters the usability of the system. When these PRs are tied to specifications that were drafted and reviewed, the adoption path is clear. However, if the PRs both introduce the concept and provide an implementation, then it is harder to manage the PR as maintainers wrestle with deciding on whether the alteration is a good change and with the maintainability of the code.

I'd like to use the time on our call to capture any guidelines / rules / processes that should be added into our development workflow standards and wiki.  Maintainers would be responsible for making sure all of our contributors are informed and then follow suit.

Tyler

Tyler Jewell // CEO // tyler@​codenvy.​com // 978.884.5355

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev