[PATCH 1/3] dim: Move special handling of drm-intel-next's repo to branch_to_repo

Vivi, Rodrigo rodrigo.vivi at intel.com
Mon Aug 27 13:14:37 UTC 2018



> On Aug 27, 2018, at 1:39 AM, Nikula, Jani <jani.nikula at intel.com> wrote:
> 
>> On Mon, 27 Aug 2018, Daniel Vetter <daniel at ffwll.ch> wrote:
>>> On Fri, Aug 24, 2018 at 02:43:34PM -0700, Rodrigo Vivi wrote:
>>> I don't understand exactly why we need this special handling only
>>> for drm-intel-next. But let's at least consolidate this into
>>> branch_to_repo instead of spreading it around.
>>> 
>>> Cc: Jani Nikula <jani.nikula at intel.com>
>>> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
>>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
>> 
>> drm-intel-next is not a dim-managed branch (i.e. it's not listed in
>> nightly.conf). I think that would be good to add in a comment.
>> 
>> With that added: Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>> 
>> Aside, I recommend you just remove drm-intel-next and all the special
>> casing. With the uncoupling of tagging from sending pull requests there's
>> really no need for this anymore.
>> 
>> The only other thing coupled with drm-intel-next is drm-intel-testing.
>> This was used by Gordon's QA team for the 1-week long manual test cycle.
>> Gordon's gfx QA team is no more (since years!), so there's really no point
>> in this. But there's also not much real harm (except the confusion
>> drm-intel-next/testing cause).
> 
> This is a process question. In general, I think it's a good idea to
> support a split workflow, tag first, tag multiple times, send pull
> request later. Did also Sean talk about this in the past? I forget.

+1 I like this flow of multiple tag and 1 pull request.

> 
> But do we need to *require* that drm-intel-next pull requests are done
> in this manner? Do we require a separate testing tag (which is a drm-tip
> snapshot) at this point? Who needs that? Who uses that?

All good questions. And I think we should kill -testing branch... probably kill -queued and unify with -misc approach, but all of this I think it is orthogonal to this series here and can be done later or in separate work.

> 
> BR,
> Jani.
> 
> 
> 
>> -Daniel
>> 
>>> ---
>>> dim | 13 +++++--------
>>> 1 file changed, 5 insertions(+), 8 deletions(-)
>>> 
>>> diff --git a/dim b/dim
>>> index 5040d6b046b2..fec51f766e55 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -290,6 +290,10 @@ function branch_to_repo # branch
>>>        fi
>>>    done
>>> 
>>> +    if [[ "$1" == "drm-intel-next" ]] ; then
>>> +        echo "drm-intel"
>>> +    fi
>>> +
>>>    echo ""
>>> }
>>> 
>>> @@ -1402,10 +1406,6 @@ function dim_checkout
>>>    if ! git_branch_exists $branch ; then
>>>        repo=$(branch_to_repo $branch)
>>> 
>>> -        if [[ $branch == "drm-intel-next" ]] ; then
>>> -            repo="drm-intel"
>>> -        fi
>>> -
>>>        if [[ $repo == "" ]] ; then
>>>            echoerr "$branch not found in $dim_integration_config"
>>>            exit 1
>>> @@ -1890,6 +1890,7 @@ function dim_pull_request
>>>    branch=${1:?$usage}
>>>    upstream=${2:?$usage}
>>>    remote=$(branch_to_remote $branch)
>>> +    repo=$(branch_to_repo $branch)
>>>    req_file=$(mktemp)
>>> 
>>>    if [ "$branch" != "drm-intel-next" ]; then
>>> @@ -1906,16 +1907,12 @@ function dim_pull_request
>>>        drm_intel_next_tags=$(git log "$branch@{upstream}" ^$upstream --decorate | grep "(.*tag: drm-intel-next-" | sed -e "s/^.*(.*tag: \(drm-intel-next-[^ ,]*\).*)$/\1/")
>>>        prep_pull_mail $req_file $drm_intel_next_tags
>>>        tag=$(git describe --all --exact "$branch@{upstream}")
>>> -
>>> -        repo="drm-intel"
>>>    else
>>>        tag=$(tag_name "$branch")
>>>        gitk --first-parent "$branch" ^$upstream &
>>>        tag_branch $tag $branch
>>>        $DRY git push $remote $tag
>>>        prep_pull_mail $req_file $tag
>>> -
>>> -        repo=$(branch_to_repo $branch)
>>>    fi
>>> 
>>>    url_list=${drm_tip_repos[$repo]}
>>> -- 
>>> 2.17.1
>>> 
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center


More information about the dim-tools mailing list