cverna reported a new issue against the project: `atomic-wg` that you are following: `` The Fedora container release are quite difficult to get out, while the tooling might still need some work, I also feel that it is not really clear what we are expecting from the release.
Following a discussion on atomic-devel, I propose the following : * Release containers that are based on the current stable fedora ( would be f27 currently) * Release containers that are based on the next stable fedora release (beta) ( would be f28 currently) with the idea to have these available for testing.
This process would exclude rebuilding the f26 and rawhide based containers.
Any feedback on this proposition ? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
dustymabe added a new comment to an issue you are following: ``
- Release containers that are based on the current stable fedora ( would be f27 currently)
- Release containers that are based on the next stable fedora release (beta) ( would be f28 currently) with the idea to have these available for testing.
+1
This process would exclude rebuilding the f26
I think if we stop rebuilding those we should probably not leave them as available in the registry ORR we move them to some other name like `/eol/` or something.
and rawhide based containers.
+1, although I could see some people might want this.
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
smilner added a new comment to an issue you are following: `` I :thumbsup: @dustymabe's comments as well. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
cverna added a new comment to an issue you are following: ``
I think if we stop rebuilding those we should probably not leave them as available in the registry >ORR we move them to some other name like /eol/ or something.
So the idea would be to move the container based on old fedora release to another namespace something like `registry.fp.o/eol/f25/nginx` ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
smilner added a new comment to an issue you are following: `` That looks right to me. However, I think dropping images which are no longer being updated makes sense. I don't think many, if any, people would update registry locations to continue using an image which won't be updated or supported by the community. I think it would add more work to those owning the registry. However, it won't hurt anything from the consumers point of view. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
maxamillion added a new comment to an issue you are following: `` +1
I think this makes a lot of sense and follows along with the intent of the Atomic WG to "move forward more rapidly" just as is done with Atomic Host rpm-ostree releases. Historically this was different and the idea what to allow each "Fedora Generational Core" (FGC) to maintain their own version of each [env and stack](https://fedoraproject.org/wiki/Env_and_Stacks) which was to be shipped by the original concept of [modularity](https://docs.pagure.org/modularity/). The original Modularity Concept effectively said that we could have multiple FGCs available to support parallel installable versions of each Env/Stack and the container releases was going to be one of the release and distribution methods of these modules. That is why things are modeled the way they are today. However, effectively all of that has evolved over time and it makes a lot of sense to pivot to more forward looking approach and I think this is a solid plan. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
otaylor added a new comment to an issue you are following: `` My (unfinalized) plans for Flatpaks are:
* The application creator creates a stream corresponding to each different user-visible flatpak artifact that they want to expose - probably just a 'stable' and a 'unstable' (devel?) stream. * The module configuration defines what Fedora versioned runtime (F28, F29, whatever) that each stream will build from. A maintainer could, if they wanted, have both the stable and unstable artifact target the same Fedora release and differ only in the application code. * All the flatpaks for an application are in the same repository, and are tagged as 'latest-<streamname>'. latest-stable is also tagged as 'latest'.
If you have a server side container that is clearly an application - and not something that someone is going to be extensively building-on in a derived Dockerfile - I could see the same scheme making sense. This could even be done for non-modular containers - have stable/unstable branches in dist-git/containers and let the FROM line define the base image - but it makes much less sense, because if you are just pulling packages from the base Fedora package set, the F28 packages have to be stable, and anything unstable needs to be in rawhide, so keeping a Fedora-versioned branching scheme and automatically mapping to stable/unstable may make more sense.
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
The issue: `Container Release` of project: `atomic-wg` has been assigned to `cverna` by smilner.
The status of the issue: `Container Release` of project: `atomic-wg` has been updated to: Closed as Fixed by cverna.
cverna added a new comment to an issue you are following: `` Closing this ticket. I ll open new tickets for the actual changes to be implemented. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/439
The status of the issue: `Container Release` of project: `atomic-wg` has been updated to: Open by cverna.
The status of the issue: `Container Release` of project: `atomic-wg` has been updated to: Closed as Fixed by cverna.
atomic@lists.fedoraproject.org
-
Adam Miller -
Clement Verna
-
Dusty Mabe
-
Owen Taylor
-
Steve Milner