-
Notifications
You must be signed in to change notification settings - Fork 288
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
SBAT.md recommends resetting vendor generation numbers after global generation number went up #634
Comments
Related explanation regarding such consensus in historical context, as well as the I'd highly recommend writing an introductory document akin to what @nicholasbishop provided here, but covering all the common scenarios, so people are immediately getting the knowledge of how the appropriate numbering system. I can write a draft and suggest it, but first I need to make sure that I know, what is actually happening and that I was consulted on this before writing things that may be incorrect. |
As per rhboot#634, the current consensus seems to be for generation numbers to only ever go up and not get reset. This has been clarified and an example related to this behavior has been described. Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
As per rhboot#634, the current consensus seems to be for generation numbers to only ever go up and not get reset. This has been clarified and an example related to this behavior has been described. Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
As per #634, the current consensus seems to be for generation numbers to only ever go up and not get reset. This has been clarified and an example related to this behavior has been described. Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
For example:
The current consensus seems to be for both generation numbers to only ever go up, so we should stop recommending people do this.
The text was updated successfully, but these errors were encountered: