Skip to content
This repository has been archived by the owner on May 14, 2024. It is now read-only.

Central Location for Release Blockers #178

Closed
anweshadas opened this issue Jan 2, 2023 · 6 comments
Closed

Central Location for Release Blockers #178

anweshadas opened this issue Jan 2, 2023 · 6 comments
Assignees

Comments

@anweshadas
Copy link

Summary

To have a single point of truth for Release blocker information.

We do not have any specific space for to keep track of the Ansible community release blockers. General practice is we do keep our eyes open for the release blockers in ansible-core, ask around in different platforms and individual contributors. It would be good to have a central location for release blockers. Where we would be able to see if there is any blocker for a particular release or not.
It has been discussed in the Ansible community working group meeting. And everyone agreed with the general idea.

We have to decide on the following:

  • Where to have the place holder?
  • Fix the definition of a release blockers.

Additional Information

No response

@felixfontein
Copy link
Contributor

As for where, I think the best place would be issues (with a special label) in ansible-build-data.

As for a definition, that's more complicated. For me it's more a "I know it when I see it" thing, which isn't a useful definition :) Two things I can think of out of my head are:

  • "ansible-core release delayed";
  • "an unexpected thing came up (with the new major ansible-core release) that breaks some collections severely, or affects too many of the collections" (this is again kind of "I know it when I see it").

@Andersson007
Copy link
Contributor

  • I support the idea of labeling + they probably should be added to a milestone for a corresponding release
  • I'm not sure if we need a formal definition as we'll use the "I know it when I see it" approach anyway when seeing any blocker that doesn't fall under that definition. Or it should be very general like:
In the context of the Ansible Community package release workflow,
a release blocker is a situation which does not allow the package to be released.
It might come with a new ansible-core release and affect many of the included collections
or in any other way severe affect consistent work of the package.
Severity of the impact is determined by the Steering Committee in each particular case.

@Andersson007
Copy link
Contributor

Created a PR, please folks take a look

@Andersson007 Andersson007 self-assigned this Jan 12, 2023
@mariolenz
Copy link
Contributor

Created a PR, please folks take a look

@anweshadas What do you think about this PR? This would mean that the central location for (Ansible community package) release blockers would be ansible-build-data.

I like that the suggested workflow means we could see the blocker in a milestone.

The definition of a release blocker is a bit open. But I think that something like "in any way severely affects consistent work with the ansible package" gives us the flexibility we need. This follows the "I know it when I see it" approach mentioned by @felixfontein and @Andersson007, which I think is a good idea.

@felixfontein
Copy link
Contributor

ansible-community/ansible-build-data#194 is merged, so we have a location and a first definition: https://github.com/ansible-community/ansible-build-data/#blockers

We can improve in particular the definition, so if someone has a concrete proposal... :)

@anweshadas
Copy link
Author

Since ansible-community/ansible-build-data#194 is merged and solve the initial set of issues closing the PR.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants