Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs/EARLY-RELEASE.md: how to determine an early release #9820

Closed
wants to merge 4 commits into from

Conversation

bagder
Copy link
Member

@bagder bagder commented Oct 28, 2022

@rodwiddowson
Copy link
Contributor

rodwiddowson commented Oct 28, 2022

I missed the mail conversation until now but I think there may be another question - which I apply when weighing up these issues.
Is rolling back to the previous release an acceptable workaound for affected users?

Obviously there are many cases when it isn't. like "The affected release carried a fix for a Security Advisory" or "This bug is a security issue and may go unnoticed".

In the specific case I would have thought that waiting until Tuesday before cranking a release might be prudent....

docs/EARLY-RELEASE.md Outdated Show resolved Hide resolved
@danielgustafsson
Copy link
Member

danielgustafsson commented Oct 28, 2022

.. or "This bug is a security issue and may go unnoticed".

For bugs that are found to be security issues I think the security process already has wording around that. If we feel that's not giving enough direction I think we should address that there instead.

@rodwiddowson
Copy link
Contributor

rodwiddowson commented Oct 28, 2022

For bugs that are found to be security issues I think the security process already has wording ..

Agreed 110%

@bagder
Copy link
Member Author

bagder commented Oct 28, 2022

I missed the mail conversation until now but I think there may be another question - which I apply when weighing up these issues. Is rolling back to the previous release an acceptable workaound for affected users?

I phrased it like this in the current draft:

  • Can affected users safely rather revert to a former release until the next scheduled release?

Obviously there are many cases when it isn't. like "The affected release carried a fix for a Security Advisory" or "This bug is a security issue and may go unnoticed".

Right. Like our current situation: we shipped 7.86.0 with fixes for four security related problems. Asking users to stick to the former release due to the existence of a problem in the new release might then implicitly ask them to live with those four security problems for another release cycle ... Not necessarily the most responsible way.

In the specific case I would have thought that waiting until Tuesday before cranking a release might be prudent....

I went into scheduling a little bit in the bottom for the cases we actually deem an early release to be the right choice. It is also important to not rush out releases to make sure things are always done in an orderly way and that all procedures are followed.

docs/EARLY-RELEASE.md Outdated Show resolved Hide resolved
docs/EARLY-RELEASE.md Show resolved Hide resolved
docs/EARLY-RELEASE.md Show resolved Hide resolved
@henning-schild
Copy link

henning-schild commented Oct 28, 2022

Great to see how you guys deal with all of that and thanks so much!

The breakage can be seen as severe and security relevant on its own. Any machine in a network with proxies will potentially/partially loose network connectivity after installing that affected release. Which is clearly related to the A in CIA.

Maybe people could even get stuck on a broken release. Because their package manager is based on curl and their repo mirror based on no_proxy. Would require some package sideloading tricks to get back to live.

@henning-schild
Copy link

henning-schild commented Oct 28, 2022

Maybe someone could ping the maintainers of alpine and arch linux. They should know what is going on. And they might have their own opinion on how they would want to deal with it.

But others should also know to maybe avoid that release.

@bagder
Copy link
Member Author

bagder commented Oct 28, 2022

Maybe someone could ping the maintainers of alpine and arch linux.

There are bugs in every curl release. I presume distro maintainers have ways to deal with that.

@bagder bagder closed this in 2d45339 Nov 5, 2022
@bagder bagder deleted the bagder/early-release branch Nov 5, 2022
@bagder
Copy link
Member Author

bagder commented Nov 5, 2022

Surely this should not have the hacktoberfest-accepted tag set?

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

Successfully merging this pull request may close these issues.

None yet

6 participants