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:/streams: try to explain streams lifecycle #1736

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jbtrystram
Copy link
Contributor

I have been struggling a bit to understand how the content is promoted between the streams, so I tried to improve the documentation a little.

I thought of adding a mermaid chart as well but I am not sure if it's really helpful.

Also, delete bodhi-updates references, see #1734

I have been struggling a bit to understand how the content is promoted
between the streams, so I tried to improve the documentation a little.

I thought of adding a mermaid chart as well but I am not sure if it's
really helpful.

Also, delete bodhi-updates references, see coreos#1734
stream-tooling.md Show resolved Hide resolved
#### Regular State
Although all the streams are built from scratch (there is no tangible relations between streams) here is how the RPMs flow towards stable:

The **testing-devel** Stream is built daily with the content of the `fedora-update` repository. If the build successfully pass the tests,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which fedora-update repository are you referring to here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any new RPM receive the `coreos-pool` koji tag.

For a release (approximately every two weeks), someone manually triggers the `bump-lockfile` job to propagate the **testing** content to the **stable** branch.
The **testing-devel** content is propagated to the **testing** and **next** streams. Theses images are built from the `coreos-pool` yum repository.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it not testing-devel -> next -> testing -> stable? Reading this I feel you're saying that testing-devel goes directly to both ( testing <- testing-devel -> next).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when Fedora is not branched (right now), testing and next are the same .

Looking at testing commit history : it's at testing devel e13ff7d

Looking at next commit history : it's at testing devel e13ff7d


#### When Fedora Branched exist

Before every released, there is a stabilisation period. A branch is created from rawhide, the next release enters it's [branched](https://docs.fedoraproject.org/en-US/releases/branched/) state.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit-pick: Before every release, ...


#### Rawhide

The **rawhide** stream is daily built from the `fedora rawhide packages. When there is no `fedora-branched` release, the **branched** stream mirrors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit-pick: missing backtick.

#### Rawhide

The **rawhide** stream is daily built from the `fedora rawhide packages. When there is no `fedora-branched` release, the **branched** stream mirrors
**rawhide**. This stream allow us to monitor changes early and react accordingly. The results are not used in any lockfiles.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting... honestly, this is the first time I'm considering the lifecycle as a whole. I feel like a chart would help clarify things described above ;)

@jlebon
Copy link
Member

jlebon commented May 22, 2024

There are multiple things here in both the old and new texts that aren't quite right/outdated. Some things in the new text also duplicate other sections. WDYT about instead focusing this PR on scrubbing out bodhi-updates and bodhi-updates-testing for now and I can do a follow-up that updates this doc more generally to reflect reality?

@jbtrystram
Copy link
Contributor Author

jbtrystram commented May 22, 2024

WDYT about instead focusing this PR on scrubbing out bodhi-updates and bodhi-updates-testing for now

You are right let's split that out: #1738

@jbtrystram
Copy link
Contributor Author

jbtrystram commented May 22, 2024

@jlebon BTW, what do you think about merging Design.md and stream-tooling.md as they are redundant in some areas ?

There are multiple things here in both the old and new texts that aren't quite right/outdated. Some things in the new > text also duplicate other sections. ... I can do a follow-up that updates this doc more generally to reflect reality?

If you don't mind I'd like to do the follow-up on the doc update. I know it's going to be a slower process, but IMHO the process of figuring this out is valuable :)

@jlebon
Copy link
Member

jlebon commented May 22, 2024

@jlebon BTW, what do you think about merging Design.md and stream-tooling.md as they are redundant in some areas ?

The difference is that the text in Design.md is more about the high-level design, while stream-tooling.md is more about implementation details of how to achieve it. It seems like a useful distinction to maintain for people who want to get acquainted with the model without caring about implementation?

I do think though that stream-tooling.md should probably link to that section of Design.md as a "required reading".

If you don't mind I'd like to do the follow-up on the doc update. I know it's going to be a slower process, but IMHO the process of figuring this out is valuable :)

Works for me!

Copy link
Member

@travier travier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM. Some nits

@@ -2,7 +2,7 @@

## Introduction

FCOS will have multiple streams:
FCOS have multiple streams:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
FCOS have multiple streams:
FCOS has multiple streams:


#### When Fedora Branched exist

Before every released, there is a stabilisation period. A branch is created from rawhide, the next release enters it's [branched](https://docs.fedoraproject.org/en-US/releases/branched/) state.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Before every released, there is a stabilisation period. A branch is created from rawhide, the next release enters it's [branched](https://docs.fedoraproject.org/en-US/releases/branched/) state.
Before every release, there is a stabilisation period. A branch is created from rawhide, the next release enters its [branched](https://docs.fedoraproject.org/en-US/releases/branched/) state.

@travier
Copy link
Member

travier commented Jul 10, 2024

Ah, looks like Jonathan founds things I missed: #1736 (comment)

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

Successfully merging this pull request may close these issues.

4 participants