Re: [openstack-dev] [release] change in plan for releases repo data model updates
Excerpts from Doug Hellmann's message of 2016-11-08 12:28:28 -0500: > 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). > > 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. > > 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. > > 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. > > Thoughts? > Doug > Based on the mixed feedback, I went ahead and prepared a series of patches to import the tags into the releases repo [1] and another patch to remove the data from the governance repo [2]. Doug [1] https://review.openstack.org/#/q/topic:move-release-tags-out-of-gov [2] https://review.openstack.org/396360 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] change in plan for releases repo data model updates
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:thie...@openstack.org] Sent: Wednesday, November 09, 2016 5:13 AM To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] change in plan for releases repo data model updates
On Tue, Nov 08, 2016 at 12:28:28PM -0500, 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). > > 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. > > 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. > > 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. +1 I like this pass through model. I know it's a little strange having the TC "gate" on changes to the release type but I think this works through this nicely. The only wart is defining who is responsible for updating the governance repo when things change in the release repo. Is it the project team or the release team? Yours Tony. signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release] change in plan for releases repo data model updates
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). 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. 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. 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. Thoughts? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
