| Re: [che-dev] Long-lived Branches / PRs |
AngelCheers,FWIW, I don't think a branch on the main repo is ideal, but it seems to be the best option we've got at the moment. Maybe it would help if we labelled Openshift-related PRs with a openshift-specific label, so as to not clutter the list for master? We can discuss more later.The main intention behind using the openshift-connector branch was to develop a new feature within the main codebase (so that all committers can review/comment) while not interfering with the release schedule of mainstream Che. The other options for Openshift integration, as I see it, are 1) to make PRs on master for all changes, or 2) to develop Openshift integration in a fork of Che.For the second option, moving to a proper fork of Che would do nothing to solve the problem of eventual integration while also obscuring the development process and discussions that take place.
For the first option, Openshift integration is not yet at the point where full release makes sense, so we would either be introducing a large support burden with each release, or adding code without release notes that risks causing instability for users who don't want to touch Openshift. It's just not a feature that can be developed over the course of one release cycle. We'd also waste time documenting changes that may be removed in a later commit.On Mon, Apr 10, 2017 at 9:00 AM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote: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-2929 35001 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.On Mon, Apr 10, 2017 at 5:10 AM, Gennady Azarenkov <gazarenkov@xxxxxxxxxxx> wrote:@AlexYes, 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.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.GennadyOn 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_________________
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
_______________________________________________
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