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

[Gennady Azarenkov <gazarenkov@xxxxxxxxxxx>]

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