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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
