Open Stack

Sorry for top posting, but exchange....

Automation is our friend.  Define the structure/naming of the release repo patches such that when they merge, they auto generate the governance patch and submit it.  It gives you time to run a cycle and see how things work and what a more elegant solution might be.

my $.02

--Rocky

-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org] 
Sent: Wednesday, November 09, 2016 5:13 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [release] change in plan for releases repo data model updates

Doug Hellmann wrote:
> At the summit we said we would move the data that tells us the type
> and release model for each deliverable out of the governance
> repository and into the releases repository where it is easier to
> change over time, but that we needed to think more about what might
> break by making that change. After giving it more consideration, I
> think we have to use the option 2 we discussed instead (allow local
> values to override the global values).

If we look back at the goals driving the change, this solves the
"temporarily bypass governance values" need. The main drawback (to me)
is that we continue to consider deliverable types and release model to
be a "governance" thing. Another drawback is the additional work needed
to sync changes back into the governance repo (see Tony's question).

> The list-repos command would not be able to filter on the type or
> model values early in a cycle because not enough deliverable files
> would even exist until the first milestone. That limitation would
> make the command essentially useless until close to the end of each
> cycle. Using option 2 means list-repos would continue to work all the
> time.

Devil's advocate, we could copy over the type/model values from the
previous cycle as part of the new cycle opening, and have list-repos
work all the time. That sounds like less work than tracking the
retrosyncing of each and every override back onto the governance repo...

> Using option 2 also means that instead of us having to do extra
> work to build and publish a single unified file for the project
> navigator team, they can continue to use the same input data without
> changes to their project at all.

That's a one-time work, so I don't think having to do that is unreasonable.

> I propose adding "type" and "model" fields, as we discussed, but
> making them optional. If they are not present, the values can be
> derived from the governance tags for the deliverable. Teams who
> want to change either value can then make the update in the releases
> repository with a separate patch to update the governance repo, and
> not have releases blocked by the governance change.

It feels like extra work overall. More work for teams (having to file
two separate patches) and more work for us to make sure that governance
patch is merged, doesn't slip through the cracks and doesn't introduce a
drift between the two repos.

So... not convinced :)

-- 
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev