[release][tc][horizon] xstatic repositories marked as deprecated
Hi, I noticed some xstatic repositories [1] under the horizon team are marked as deprecated. They are marked as deprecated in [2] as they were never released, but the actual situation looks different. They are used in horizon requirements and the contents of these repositories are same as those in the corresponding PyPI modules. I guess they were released to PyPI based on the repositories but the horizon team just forgot to push the corresponding tags. I would like to drop 'deprecated' mark from the repositories and move them to the proper situation. Does it make sense? If so, what is the right solution to do this? In my understanding, we need to add tags corresponding to the deliverables and to add deliverable files in the releases repo. What I am not sure is whether we can push a tag to a repository without pushing deliverables to PyPI? Or do we need to create another release to tag them in their repositories? [1] Such xstatic repositories are: - xstatic-bootstrap-datepicker - xstatic-hogan - xstatic-jquery-migrate - xstatic-jquery.quicksearch - xstatic-jquery.tablesorter - xstatic-rickshaw - xstatic-spin [2] https://review.opendev.org/#/c/629889/ Thanks, Akihiro Motoki (irc: amotoki)
Hi Akihiro, If you only want to create tags in these repositories, and don't need tarball and PyPI releases, you could follow the approach used for kayobe-config repositories with the no-artifact-build-job flag: https://review.opendev.org/#/c/700174/2/deliverables/train/kayobe.yaml Best wishes, Pierre On Thu, 27 Feb 2020 at 00:06, Akihiro Motoki <amotoki@gmail.com> wrote:
Hi,
I noticed some xstatic repositories [1] under the horizon team are marked as deprecated.
They are marked as deprecated in [2] as they were never released, but the actual situation looks different. They are used in horizon requirements and the contents of these repositories are same as those in the corresponding PyPI modules. I guess they were released to PyPI based on the repositories but the horizon team just forgot to push the corresponding tags.
I would like to drop 'deprecated' mark from the repositories and move them to the proper situation. Does it make sense?
If so, what is the right solution to do this? In my understanding, we need to add tags corresponding to the deliverables and to add deliverable files in the releases repo. What I am not sure is whether we can push a tag to a repository without pushing deliverables to PyPI? Or do we need to create another release to tag them in their repositories?
[1] Such xstatic repositories are: - xstatic-bootstrap-datepicker - xstatic-hogan - xstatic-jquery-migrate - xstatic-jquery.quicksearch - xstatic-jquery.tablesorter - xstatic-rickshaw - xstatic-spin [2] https://review.opendev.org/#/c/629889/
Thanks, Akihiro Motoki (irc: amotoki)
If you only want to create tags in these repositories, and don't need tarball and PyPI releases, you could follow the approach used for kayobe-config repositories with the no-artifact-build-job flag: https://review.opendev.org/#/c/700174/2/deliverables/train/kayobe.yaml If I understand correctly, this flag only avoids failing tests if no release job is defined in Zuul for the repository (which is one of the
Pierre Riteau wrote: things the release test jobs check for). It would not prevent defined release jobs from running if you added a tag. The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order. In parallel, remove the "deprecated" flag from governance. -- Thierry Carrez (ttx)
On Thu, 27 Feb 2020 at 15:11, Thierry Carrez <thierry@openstack.org> wrote:
If you only want to create tags in these repositories, and don't need tarball and PyPI releases, you could follow the approach used for kayobe-config repositories with the no-artifact-build-job flag: https://review.opendev.org/#/c/700174/2/deliverables/train/kayobe.yaml If I understand correctly, this flag only avoids failing tests if no release job is defined in Zuul for the repository (which is one of the
Pierre Riteau wrote: things the release test jobs check for). It would not prevent defined release jobs from running if you added a tag.
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order.
In parallel, remove the "deprecated" flag from governance.
My bad, I misunderstood the problem. From now on I shall drink my morning coffee before replying to the list.
Thierry Carrez wrote:
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order.
Clarification with a practical example: xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the openstack/xstatic-hogan repo, and no deliverable file in openstack/releases. Solution is to resync everything by proposing a 2.0.0.3 release that will have tag, be in openstack/releases and have a matching upload on PyPI. This is done by: - bumping BUILD at https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/ho... - adding a deliverables/_independent/xstatic-hogan.yaml file in openstack/releases defining a tag for 2.0.0.3 - removing the "deprecated" line from https://opendev.org/openstack/governance/src/branch/master/reference/project... Repeat for every affected package :) -- Thierry Carrez (ttx)
Thanks Thierry for the detail explanation. The horizon team will update the corresponding repos for new minor releases and follow the usual release process. One question: we have passed the milestone-2. Is it better to wait till Victoria dev cycle is open? Thanks, Akihiro On Fri, Feb 28, 2020 at 1:47 AM Thierry Carrez <thierry@openstack.org> wrote:
Thierry Carrez wrote:
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order.
Clarification with a practical example:
xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the openstack/xstatic-hogan repo, and no deliverable file in openstack/releases.
Solution is to resync everything by proposing a 2.0.0.3 release that will have tag, be in openstack/releases and have a matching upload on PyPI.
This is done by:
- bumping BUILD at https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/ho...
- adding a deliverables/_independent/xstatic-hogan.yaml file in openstack/releases defining a tag for 2.0.0.3
- removing the "deprecated" line from https://opendev.org/openstack/governance/src/branch/master/reference/project...
Repeat for every affected package :)
-- Thierry Carrez (ttx)
On 3/3/20 4:11 AM, Akihiro Motoki wrote:
Thanks Thierry for the detail explanation. The horizon team will update the corresponding repos for new minor releases and follow the usual release process. One question: we have passed the milestone-2. Is it better to wait till Victoria dev cycle is open?
Thanks, Akihiro
We are past the deadline for inclusion in ussuri. But that said, these are things that are currently being used by the team, so I think it's a little misleading in its current state. I think we should get these new releases done in this cycle if possible. Part of this is also the assumption that these will be cycle based. I wonder if this are more appropriate as independent deliverables? That means they are not tied to a specific release cycle and can be released whenever there is something to be released. At least something to think about. https://releases.openstack.org/reference/release_models.html#cycle-with-inte...
On Fri, Feb 28, 2020 at 1:47 AM Thierry Carrez <thierry@openstack.org> wrote:
Thierry Carrez wrote:
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order. Clarification with a practical example:
xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the openstack/xstatic-hogan repo, and no deliverable file in openstack/releases.
Solution is to resync everything by proposing a 2.0.0.3 release that will have tag, be in openstack/releases and have a matching upload on PyPI.
This is done by:
- bumping BUILD at https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/ho...
- adding a deliverables/_independent/xstatic-hogan.yaml file in openstack/releases defining a tag for 2.0.0.3
- removing the "deprecated" line from https://opendev.org/openstack/governance/src/branch/master/reference/project...
Repeat for every affected package :)
-- Thierry Carrez (ttx)
I think it makes a lot of sense to make them independent, especially since the releases often contain security fixes, so that they should be included in any older supported releases of Horizon as well. On Tue, Mar 3, 2020 at 3:02 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
On 3/3/20 4:11 AM, Akihiro Motoki wrote:
Thanks Thierry for the detail explanation. The horizon team will update the corresponding repos for new minor releases and follow the usual release process. One question: we have passed the milestone-2. Is it better to wait till Victoria dev cycle is open?
Thanks, Akihiro
We are past the deadline for inclusion in ussuri. But that said, these are things that are currently being used by the team, so I think it's a little misleading in its current state. I think we should get these new releases done in this cycle if possible.
Part of this is also the assumption that these will be cycle based. I wonder if this are more appropriate as independent deliverables? That means they are not tied to a specific release cycle and can be released whenever there is something to be released. At least something to think about.
https://releases.openstack.org/reference/release_models.html#cycle-with-inte...
On Fri, Feb 28, 2020 at 1:47 AM Thierry Carrez <thierry@openstack.org> wrote:
Thierry Carrez wrote:
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order. Clarification with a practical example:
xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the openstack/xstatic-hogan repo, and no deliverable file in openstack/releases.
Solution is to resync everything by proposing a 2.0.0.3 release that will have tag, be in openstack/releases and have a matching upload on PyPI.
This is done by:
- bumping BUILD at
https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/ho...
- adding a deliverables/_independent/xstatic-hogan.yaml file in openstack/releases defining a tag for 2.0.0.3
- removing the "deprecated" line from
https://opendev.org/openstack/governance/src/branch/master/reference/project...
Repeat for every affected package :)
-- Thierry Carrez (ttx)
-- Radomir Dopieralski
I totally forgot xstatic deliverables adopts the "independent" release mode when I sent the mail. I know the policy is only applied to cycle-based deliverables, but I totally forgot it...... xstatic deliverables I am talking about fit into "independent deliverables". On Wed, Mar 4, 2020 at 10:42 PM Radomir Dopieralski <rdopiera@redhat.com> wrote:
I think it makes a lot of sense to make them independent, especially since the releases often contain security fixes, so that they should be included in any older supported releases of Horizon as well.
On Tue, Mar 3, 2020 at 3:02 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
On 3/3/20 4:11 AM, Akihiro Motoki wrote:
Thanks Thierry for the detail explanation. The horizon team will update the corresponding repos for new minor releases and follow the usual release process. One question: we have passed the milestone-2. Is it better to wait till Victoria dev cycle is open?
Thanks, Akihiro
We are past the deadline for inclusion in ussuri. But that said, these are things that are currently being used by the team, so I think it's a little misleading in its current state. I think we should get these new releases done in this cycle if possible.
Part of this is also the assumption that these will be cycle based. I wonder if this are more appropriate as independent deliverables? That means they are not tied to a specific release cycle and can be released whenever there is something to be released. At least something to think about.
https://releases.openstack.org/reference/release_models.html#cycle-with-inte...
On Fri, Feb 28, 2020 at 1:47 AM Thierry Carrez <thierry@openstack.org> wrote:
Thierry Carrez wrote:
The way we've been handling this in the past was to ignore past releases (since they are not signed by the release team), and push a new one through the releases repository. It should replace the unofficial one in PyPI and make sure all is in order. Clarification with a practical example:
xstatic-hogan 2.0.0.2 is on PyPI, but has no tag in the openstack/xstatic-hogan repo, and no deliverable file in openstack/releases.
Solution is to resync everything by proposing a 2.0.0.3 release that will have tag, be in openstack/releases and have a matching upload on PyPI.
This is done by:
- bumping BUILD at https://opendev.org/openstack/xstatic-hogan/src/branch/master/xstatic/pkg/ho...
- adding a deliverables/_independent/xstatic-hogan.yaml file in openstack/releases defining a tag for 2.0.0.3
- removing the "deprecated" line from https://opendev.org/openstack/governance/src/branch/master/reference/project...
Repeat for every affected package :)
-- Thierry Carrez (ttx)
-- Radomir Dopieralski
participants (5)
-
Akihiro Motoki
-
Pierre Riteau
-
Radomir Dopieralski
-
Sean McGinnis
-
Thierry Carrez