Open Stack

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)