| Re: [che-dev] che-dev Digest, Vol 28, Issue 7 |
Send che-dev mailing list submissions to
che-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
or, via email, send a message with subject or body 'help' to
che-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
che-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of che-dev digest..."
Today's Topics:
1. Re: Long-lived Branches / PRs (Tyler Jewell)
------------------------------------------------------------ ----------
Message: 1
Date: Mon, 10 Apr 2017 17:07:40 -0700
From: Tyler Jewell <tyler@xxxxxxxxxxx>
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Long-lived Branches / PRs
Message-ID:
<CAMzFgbXTvMrWEGhN7cJH0HemtLfh_k1gap+K_0fy1KmnwWLtmw@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
As a general rule, I agree with Gennady that it is better to have
long-lived branches on the main repository than to have them in a fork,
especially if the intention is for that branch to eventually become part of
the master release cycle. With the long-lived branch in the main
repository, we get to have the record of the git history and maybe more
importantly there is transparency for the community on the full scope of
activity that is happening on the project.
So I think the issue comes down to the nature of PRs. PRs to master have an
increasingly higher standard that must be met prior to merge. PRs to a
long-lived branch reside in (virtually) the same queue as PRs into master,
but have an inconsistent and lower standard. So for repository maintainers
that are studying the backlog of PRs should have a set of guidelines that
they can apply.
If it is commonly agreed that having long-lived branches is good for
transparency and coordination of different teams, then the reverse thinking
can also be applied - are there features that are being developed either in
forks (by committers) or in a long-lived branch where branch PRs are not
currently being used? It's been Codenvy's approach for developers to just
direct-commit to that branch until the entire branch is readied for the
merge into master, and then we end up with a titanic singular PR.
I am indifferent to what the policy should be. I just think that it's time
for the maintainers to agree on a simple set of rules, and then ask all of
the committers to follow the same guidelines.
So I think:
1. More long-lived branches are a good thing
2. Using PRs to manage changes into a long-lived branhc is ideal when >2
people are contributing
3. We should document the labeling and management rules for branch PRs
4. We should document the standard of achievement for merge into a branch
PR, even if that standard is "no minimum code quality test required"
5. We should place these rules into the Che wiki
We have the weekly Che planning call Tuesday morning Pacific - I would like
this to be the discussion topic for part of the session.
Tyler
Tyler Jewell // CEO // tyler@?codenvy.?com // 978.884.5355
On Mon, Apr 10, 2017 at 11:41 AM, Angel Misevski <amisevsk@xxxxxxxxxx>
wrote:
> 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 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.
>
> 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.
>
> 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.
>
> Cheers,
>
> Angel
>
> 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- 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
>> <(978)%20884-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
>>>>>> <(978)%20884-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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/che-dev/ >attachments/20170410/0d6503a1/ attachment.html
------------------------------
_______________________________________________
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
End of che-dev Digest, Vol 28, Issue 7
**************************************