Re: New release cycle proposal (was Rolling release model philosophy (was ...))
On 11/06/2012 10:34 AM, Matthieu Gautier wrote:
Hello all,
I'm not a Fedora developer, nor package maintainer. I'm a French Fedora
Ambassador for a long time. (I should say "I was" cause I don't do to
many things last time, just wake up every 6 months for Fedora releases
and other events).
I'm also a developer but that's not about Fedora.
While reading this thread, an idea came to me about the Fedora release
cycle.
First, while discussing with fedora users, from events, friends, and
parents (real Adam's uncle Bob), the following points can be inferred:
- They like the blending edge part of Fedora.
- They want stable releases.
Not always in the same time, it's depending of user profile. It seems a
little antagonist, but that's what they want.
(By the way, they are mostly happy with Fedora)
What I propose is a new release cycle: One release every year and a
"preview" (not sure of the name) release between them.
- Small features can come in whatever release.
- Big features (libc, anaconda, systemd, gnome3, wayland...) can come in
preview release only.
- FedoraN releases have a lifetime of 2 years.
- FedoraNPreview releases have a lifetime of 6 months.
It's an interesting idea -- right now, at any one time, there are two
supported releases: the latest and the latest minus one, both with 13 mo
life spans.
If you want to move fast, you're always going to be on the latest
release (or the alpha of latest +1).
If you don't want to move fast, chances are that latest -1 isn't slow
enough to satisfy you.
For those who upgrade each release (or sooner), a 6mo life span for the
latest release wouldn't matter. Those who don't want to upgrade every
six months might well appreciate the two year life span.
For example, if we start from Fedora20 at beginning of 2014:
- Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
doing)
- Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
- Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
of doing)
- Fedora22Preview(jul 2015)
- Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
- Fedora23Preview(jul 2016)
- Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
- ...
Preview version doesn't mean unstable. It means version as we have now,
but more tolerant to bug ("Here the new version of Fedora with latest
features. We make our best, but maybe not enough. You're aware of it.")
Stable version is mainly preview version stabilized plus other (small)
features.
For users:
- Users wanting stable (long time support) version can install it every
2 year.
- Users wanting new versions but stable can install it every year
- User wanting blending edge can install a version every 6 months
For devs:
Still a version every 6 months, new features can still be added. Just
one out of two versions has to be more stable (no big feature)
For QA:
Still a version every 6 months. More QA for stable versions
For Ambassadors/Marketing:
Still a version every 6 months. Nothing change.
For maintainers/packagers:
For now there are 4 versions at the same time: Fn-1, Fn to maintain and
Fn+1, Rawhide in dev
With my proposition:
- Between Fn and Fn+1prev: 2 versions (Fn-1, Fn) to maintain and 2
versions (Fn+1prev, rawhide) in dev
- Between Fnprev and Fn: 3 versions (Fn-2, Fn-1, Fnprev) to maintain and
1(2) version (Fn, rawhide) in dev
During 6 months, there is one version more to maintain, but changes
between Fnprev and Fn are not breaking stuff.
We could also create some king of "half end of life" : stable releases
get all updates for 1 year, and security updates only for the second
year. This could reduce maintainers' work.
This way we reach the two worlds:
- Users can chose the version they want (long time support, stable,
blending edge)
- Usual dev work for preview versions, but less QA (We have to admit it)
- Usual QA for stable version, but less dev
- Number of versions to maintain doesn't explode.
- We can have versions more rough, simplifying dev and still allowing
"real" user feedback.
- External editors could base their products on stable versions and skip
preview ones.
What do you think about this ?
Regards,
Matthieu Gautier.
--
@jasonbrooks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New release cycle proposal (was Rolling release model philosophy (was ...))
On 11/06/2012 10:55 AM, Matthieu Gautier wrote: No, I never suggest that. Preview versions have a timelife of 6mo instead of 12. Stable version have a lifetime of 24mo (12mo for regular updates) instead of 12. The cycle would have to go: stable, preview, preview, stable, and so on to avoid maintaining more than two releases at a time. If it went back and forth between stable and preview, you'd have three supported releases at once in the second half of year two. Regards, Matthieu Gautier How about NO? https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1rpdotto1_1280.jpg -- @jasonbrooks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Missing kubernetes files in f25 atomic?
On Wed, Nov 23, 2016 at 6:12 AM, Mario Ceresa wrote: > Hi, > I've just rebased an existing f24 atom to f25 and now I'm unable to find > some kubernetes related files: > * /usr/bin/etcd > * /usr/lib/systemd/system/etcd.service > * /usr/bin/kubectl > * /usr/bin/hyperkube You can install most packages using package layering. For instance: rpm-ostree install kubernetes-node I've been working on mixed package layering / containerized kube docs here: https://gist.github.com/jasonbrooks/f1aa092e63edce5272451c5845f72750 This issue thread may also be of interest: https://pagure.io/atomic-wg/issue/176 > > Those files are installed by packages such as (etcd, kubernetes-client, > kubernetes-master) in f25 workstation. Is there a way to "install" them in > the atom? > > Thanks and regards, > > Mario > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Bootable Containers Initiative Updates
Last month, the Fedora Council approved a Community Initiative [1] aimed at enhancing collaboration among image-based Fedora variants (like CoreOS, IoT and Atomic Desktop) and empowering other projects and individual users to create their own Fedora-based derivatives by working together on bootable container technologies. We've been holding meetings and chatting on matrix, and have been compiling a list of issues [2] and a general roadmap [3] aligned around convergence among the different image-based Fedora workgroups, and a set of cross-cutting feature areas related to composefs. anaconda, CI, dnf and partial pulls with zstd:chunked. If you're interested in getting involved, join us for our meetings every Tuesday at 14:00 UTC (https://meet.google.com/poh-xmxm-qyc) or reach out on matrix in #bootc:fedoraproject.org. If you want to learn more about the technology, there were a few talks related to Bootable Containers at Devconf.cz earlier this month that are worth checking out: - Keynote: What if you could boot a container? - DevConf.CZ 2024 https://www.youtube.com/watch?v=ERVyBc_fElY - Customize your OS like a container - https://www.youtube.com/watch?v=fDvE3hbmLUo - Streamlining bootable container workflows with podman-bootc - https://www.youtube.com/watch?v=uLPyeXmIdyE [1] https://fedoramagazine.org/get-involved-with-fedora-bootable-containers/ [2] https://gitlab.com/fedora/bootc/tracker/-/issues [3] https://gitlab.com/fedora/bootc/tracker/-/issues/24 -- Jason Brooks He/Him Senior Manager, Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
packaging ruby dependencies
Hi all -- As part of a documentation project I'm working on with the Fedora Atomic WG, I started packaging asciibinder[1] with the intention of getting the package into Fedora. Along the way[2], I encountered a bunch of required, unpackaged dependencies, which would also have to be added to Fedora. [1] http://asciibinder.org/ [2] https://copr.fedorainfracloud.org/coprs/jasonbrooks/asciibinder/packages/ It has me wondering whether packaging these gems as rpms is worthwhile, especially since we'd end up running asciibinder in a container, anyway. What are people's thoughts on the value of packaging gems -- it's it worthwhile, is it somehow UnFedora to not bother to package them? Jason ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
bootc initiative meeting tomorrow: future of image building for bootc
For tomorrow's bootc initiative meeting, we're going to do a video edition of the call, where we'll be discussing the future of image building for bootable containers. We'll have a set of folks on hand from relevant dev teams, and I encourage anyone interested in the topic to attend. The meeting will be at the regular date/time of Tuesday 05/06 at 15:00 UTC and the video link is https://meet.google.com/poh-xmxm-qyc. -- Jason Brooks He/Him Senior Manager, Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
