On Tue, 2017-11-28 at 13:58 -0500, David Eads wrote:
> As of https://github.com/openshift/origin/pull/17477, h
> ttps://github.com/openshift/api and https://github.com/openshift/client-go are
> the authoritative source of the OpenShift API types and the OpenShift
> external clients.  The external types and go client are no longer present
> in https://github.com/openshift/origin.  This makes it possible to interact
> with an OpenShift cluster without trying to vendor openshift/origin and it
> changes the way that API changes are merged.
> 
> To make an API change in 3.8+:
> 
>    1. open a pull with the external types to openshift/api and get it
>    reviewed, approved, and merged
>    2. bump the vendored dependencies in openshift/client-go, regenerate
>    (make generate build), and get it merged.
>    3. bump the vendored dependencies in openshift/origin
>    (hack/update-deps.sh), update your internal types, and start serving your
>    new API.
> 
> For forks, you will have to merge into the appropriate branches of the
> various repositories.

SoI have to deal with this now.

Looking at the api repository I see you opened commits with titles like
this:

UPSTREAM: openshift/origin: missed tags

I do not understand, if the api repository is authoritative, then this
repository is upstream, not openshift/origin

Is there a convention we need to follow for the vendoring of api into
client-go and origin as far as naming commits ? Care to provide an
example/template ?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to